Ingenier Informtica a a

Escuela Tcnica Superior de Ingenier Informtica e a a Curso acadmico 2007-2008 e

Proyecto Fin de Carrera

INSTALACION, CONFIGURACION Y ADMINISTRACION DE AULAS INFORMATICAS MEDIANTE SOFTWARE LIBRE

Autor: Tutor:

Antonio Gutirrez Mayoral e Jose Centeno Gonzlez a

Septiembre 2008

ii

A mis padres y mi hermano

iv

Gracias

La nalizacin de un proyecto n de carrera normalmente lleva asociado el n de una etapa o y el comienzo de otra. En particular, este proyecto resume prcticamente los ultimos dos aos a n trabajando en el GSyC en la administracin de sus laboratorios docentes. Un par de aos en los o n que he trabajado en un entorno de trabajo que creo que puede considerarse privilegiado y que cualquier persona podr envidiar. a A travs de este pequeo texto quiero agradecer al Grupo de Sistemas y Comunicaciones el e n facilitarme un entorno de trabajo envidiable, y del que me acordar siempre, sobre todo si algn e u d ya no estoy aqu A Jose Centeno y Pedro de las Heras por conar en m y creer en m como a . aqul que podr realizar el trabajo que intento hacer todos los d con la mxima ilusin posible. e a as a o Gracias tambin a Sergio Arvalo y Jess Gonzlez Barahona como directores del Departamento e e u a y estar ah siempre que lo he necesitado, ayudndome siempre que han podido. Gracias tambin a e 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 compaeros de Universidad sin los cuales el d a d ser mucho ms amargo n a a a a y aburrido. Gracias a Lorena, Juan Carlos, Carlos, Tamara, Fran, Javi, Marina, Beln y todos e los dems. a Gracias a mi familia, a mis padres y mi hermano, ya que sin su apoyo y conanza nada de esto hubiera sido posible. A todos, gracias.

vi

Resumen
Hoy en d la administracin de sistemas se ha convertido en un aspecto fundamental a o en cualquier entorno informtico. En la empresa esta responsabilidad es clara, donde la alta a disponibilidad de los sistemas es bsica para su operabilidad. De la misma manera, en cualquier a entorno docente es fundamental la puesta en marcha de todas aquellas tecnolog necesarias para as permitir a los alumnos realizar sus prcticas y a los profesores impartir sus asignaturas. A veces a esta tarea no es tan fcil como parece a simple vista: requiere de conocimientos avanzados de a redes, sistemas operativos y administracin de sistemas. o Por otro lado, el avance del Software Libre como modelo de desarrollo de software adems a 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 Informtica, ya que su exibilidad y a a los conceptos sobre los que se sustenta el Software Libre hacen que se pueda adaptar muy fcilmente a ellas. En particular, la puesta en marcha de una serie de tecnolog relacionadas a as con la administracin del sistema Linux resultan bsicas para que se pueda usar este Sistema o a Operativo en un entorno docente. En este proyecto se ha llevado a cabo un anlisis de las diferentes tecnolog que son a as 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 instalacin o de un nmero elevado de estaciones de usuario. Para ello, se implementar un mecanismo de u a instalaciones automticas completamente desatendidas que facilite esta labor. a Por otro lado, tambin se hace necesaria la implantacin de un servicio que facilite que los e o usuarios puedan iniciar una sesin en el entorno a partir de unas credenciales determinadas o (normalmente un par formado por el nombre de usuario y contrasea), as como proporcionar un n servicio de disco en red que facilite a los usuarios el poder almacenar sus cheros personales a lo largo de toda la red local. Estos dos objetivos principales son bsicos para el funcionamiento del entorno, pero no son los a unicos. La adicin de servicios adicionales al Laboratorio, como un servicio de correo electrnico o o (entrega y recogida) as como un sitio web bien documentado y funcional de cara a los alumnos van a hacer que ste sea ms agradable al uso diario. Servicios adicionales de cara a la gestin, como e a o construir y documentar pol ticas de seguridad ecientes e instaurar un sistema de monitorizacin o del estado de la red (que garantizarn la rpida deteccin de incidencias y por tanto su resolucin), a a o o culmina el proyecto. La realizacin de este proyecto supone la implantacin de un entorno totalmente funcional o o apto para la docencia de todas las prcticas de las asignaturas pertenecientes al Departamento de a Sistemas Telemticos y Computacin, al mismo tiempo que consolidan amplios conocimientos en a o Sistemas Operativos de la familia GNU/Linux, as como en un amplio abanico de aplicaciones de servidor, ampliamente usadas en entornos empresariales. La construccin adicional de aplicaciones o web de gestin de todos los servicios que hemos implementado en este proyecto, as como tcnicas o e avanzadas como la virtualizacin de servidores dejan la puerta abierta a trabajos futuros en la o misma l nea de investigacin que el presente proyecto. o

vii

viii

 Indice general

1. Introduccin o 1.1. Motivacin del proyecto . . . . . . . . . . . . o 1.2. Estructura de este documento . . . . . . . . . 1.3. Estado del arte . . . . . . . . . . . . . . . . . 1.3.1. Distribuciones de Linux . . . . . . . . 1.3.2. Sistemas de instalacin desatendidos . o 1.3.3. Sistemas de autenticacin de usuarios o 1.3.4. Sistemas de cheros en red . . . . . . 1.3.5. Servidores de correo electrnico . . . . o 1.3.6. Sistemas de monitorizacin . . . . . . o

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

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

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. Monitorizacin del sistema . . . . . . . . . . . . o 2.5. Pol ticas de seguridad . . . . . . . . . . . . . . 2.6. Documentacin . . . . . . . . . . . . . . . . . . o

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3. Especicacin y Dise o o n 3.1. Metodolog empleada . . . . . . . . . . . . . . . . . a 3.2. Anlisis de requisitos . . . . . . . . . . . . . . . . . . a 3.2.1. Proceso de instalacin desatendido . . . . . . o 3.2.2. Cuentas de usuario en red y disco en red . . . 3.2.3. Servicios de valor aadido . . . . . . . . . . . n 3.3. Dedicacin de las mquinas f o a sicas . . . . . . . . . . 3.3.1. Peloto . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Zipi . . . . . . . . . . . . . . . . . . . . . . . 3.3.3. Zape . . . . . . . . . . . . . . . . . . . . . . . 3.3.4. Lechuzo . . . . . . . . . . . . . . . . . . . . . 3.3.5. Sapientin . . . . . . . . . . . . . . . . . . . . 3.3.6. Pantuo . . . . . . . . . . . . . . . . . . . . . 3.3.7. Espatula . . . . . . . . . . . . . . . . . . . . . 3.4. Servidores disponibles en el Campus de Fuenlabrada 3.4.1. Bilo . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Nano . . . . . . . . . . . . . . . . . . . . . . ix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 INDICE GENERAL 4. Implantacin o 4.1. Herramienta de Instalacin Automtica . . . . . . . . . . . . o a 4.1.1. Servidor DHCP para conguracin automtica de Red o a 4.1.2. Arranque por PXE . . . . . . . . . . . . . . . . . . . . 4.1.3. Arranque por red de Linux . . . . . . . . . . . . . . . 4.1.4. Ficheros de preconguracin . . . . . . . . . . . . . . o 4.2. Protocolos situados en la capa de aplicacin . . . . . . . . . . o 4.2.1. Servidor LDAP de cuentas de usuario . . . . . . . . . 4.2.2. Servidor NFS de cheros en red . . . . . . . . . . . . . 4.2.3. Servidor Web de los Laboratorios . . . . . . . . . . . . 4.2.4. Servidor de correo electrnico . . . . . . . . . . . . . . o 4.3. Otros servicios disponibles . . . . . . . . . . . . . . . . . . . . 4.3.1. Listas de correo . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Mirror de Debian y Ubuntu . . . . . . . . . . . . . . . 4.4. Monitorizacin del Sistema . . . . . . . . . . . . . . . . . . . o 4.4.1. Monitorizacin de servidores . . . . . . . . . . . . . . o 4.4.2. Monitorizacin de estaciones . . . . . . . . . . . . . . o 4.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Limitar los accesos remotos . . . . . . . . . . . . . . . 4.5.2. Auditor de usuarios . . . . . . . . . . . . . . . . . . a 4.5.3. Deteccin de intrusos . . . . . . . . . . . . . . . . . . o 4.5.4. Ataques de fuerza bruta v SSH . . . . . . . . . . . . a 4.5.5. Seguridad en las contraseas de los usuarios . . . . . . n

INDICE GENERAL 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 Instalacin Automtica o a I A.1. Fichero de preconguracin genrico . . . . . . . . . . . . . . . . . . . . . . . . . . ii o e A.2. Conguracin Isolinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v o A.3. Fichero de conguracin del servidor dhcp . . . . . . . . . . . . . . . . . . . . . . vi o 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 de usuarios . . . . . . . . . . . a B.3.1. Creacin de la base de datos . . . o B.3.2. Insercin de los datos de auditor o 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 contraseas . . . . n x
IX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C. Ficheros de conguracin o C.1. Mquinas zipi y zape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.1.1. Servidor LDAP. Fichero slapd.conf . . . . . . . . . . . . . . . . C.1.2. Servidor DNS. Fichero named.conf y db.pantuo.es para zipi C.1.3. Servidor DNS. Fichero named.conf para zape . . . . . . . . . . C.2. Mquina pantuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.2.1. Fichero de conguracin de Apache . . . . . . . . . . . . . . . . o C.2.2. Fichero de conguracin de Postx . . . . . . . . . . . . . . . . o C.2.3. Fichero de conguracin de Dovecot . . . . . . . . . . . . . . . o C.3. Mquina lechuzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.4. Mquina peloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.5. Mquina sapientin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.6. Mquina minervo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.7. Mquina espatula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.8. Mquina bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a C.8.1. Servicio NFS en bilo . . . . . . . . . . . . . . . . . . . . . . . . . C.9. Mquina nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

XXI

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

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

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

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

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

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

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

xi

 INDICE GENERAL

INDICE GENERAL

xii

 Indice de guras

1.1. Interfaz web de Zabbix. Fuente: Wikipedia . . . . . . . . . . . . . . . . . . . . . . . 23 1.2. Representacin del uso de memoria en una mquina a travs de Munin. Fuente: o a e Wikipedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. El proceso de instalacin en Debian/Ubuntu y la preconguracin de paquetes. . o o 4.2. La raiz del arbol 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 Mstoles y alumnos de Fuenlabrada. . . . . . . . . . . . . . . . . . . . . . . . . . o 4.4. La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixAccount y posixGroup. . . . . . . . . . . . . . . . 4.5. La aplicacin wireshark muestra como se mandan los datos de autenticacin en o o claro entre cliente y servidor, con nuestro esquema actual. . . . . . . . . . . . . . 4.6. Una vez establecida la conexin segura entre cliente y servidor LDAP resulta ms o a dif capturar datos de autenticacin de usuarios. . . . . . . . . . . . . . . . . . cil o 4.7. Reparto de carga entre varios servidores LDAP. . . . . . . . . . . . . . . . . . . . 4.8. La aplicacin PHPLdapAdmin sobre nuestro esquema de servidores. . . . . . . . o 4.9. Pgina principal del Laboratorio de Mstoles . . . . . . . . . . . . . . . . . . . . a o 4.10. Autenticacin en la pgina del Laboratorio mediante el directorio LDAP. . . . . . o a 4.11. Webmail de pantuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Webmail de bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Gestin de listas de correo en pantuo con Mailman. . . . . . . . . . . . . . . . o 4.14. La pgina de resumen de estado de Nagios para el Laboratorio de Mstoles. . . . a o 4.15. La pgina de problemas de Nagios muestra los problemas en algunas mquinas. . a a 4.16. El parte de guerra de Mstoles muestra el estado de las estaciones. . . . . . . . . o . 50 . 55 . 55 . 56 . 60 . . . . . . . . . . . 62 63 68 78 80 86 87 87 93 93 94

xiii

 INDICE DE FIGURAS

INDICE DE FIGURAS

xiv

Indice de Listados

4.1. Generacin de un CD personalizado de Ubuntu para instalacin automtica . . o o a 4.2. Instalacin del paquete dhcp a travs de apt-get . . . . . . . . . . . . . . . . o e 4.3. Fichero de conguracin dpchd.conf. Conguracin de subred. . . . . . . . . . o o 4.4. Fichero de conguracin dpchd.conf. Conguracin de host. . . . . . . . . . . o o 4.5. Instalacin del servicio tfptd-hpa a travs de apt-get . . . . . . . . . . . . . . o e 4.6. Fichero de conguracin /etc/default/tfptd-hpa. . . . . . . . . . . . . . . . o 4.7. Reinicio del demonio tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8. Descarga del kernel de arranque por red de Ubuntu Hardy . . . . . . . . . . . . 4.9. Fichero de conguracin de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . o 4.10. Fichero de conguracin de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . o 4.11. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.12. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.13. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.14. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.15. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.16. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.17. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.18. El chero de preconguracin preseed.cfg. . . . . . . . . . . . . . . . . . . . . o 4.19. Instalacin del paquete slapd a travs de apt-get . . . . . . . . . . . . . . . . o e 4.20. El chero de plantilla de debconf para el paquete slapd. . . . . . . . . . . . . . 4.21. Precongurando el paquete slapd. . . . . . . . . . . . . . . . . . . . . . . . . . 4.22. Instalacin del paquete slapd a travs de apt-get . . . . . . . . . . . . . . . . o e 4.23. Instalacin de las bibliotecas necesarias para la autenticacin PAM v LDAP . o o a 4.24. Contenido del chero nsswitch.conf para autenticacin v LDAP . . . . . . . o a 4.25. Contenido del chero pam ldap.conf para autenticacin v LDAP . . . . . . o a 4.26. Contenido del chero libnss-ldap.conf para autenticacin v LDAP . . . . . o a 4.27. Instalacin del conjunto de herramientas migrationtools a travs de apt-get o e 4.28. Modicando registros en el rbol LDAP usando ldapadd . . . . . . . . . . . . a 4.29. Instalacin del paquete openssl a travs de apt-get . . . . . . . . . . . . . . . o e 4.30. Creacin de un certicado para nuestro servidor LDAP . . . . . . . . . . . . . o 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. Instalacin del demonio slurpd con apt-get . . . . . . . . . . . . . . . . . . . o 4.37. Aadiendo replicacin a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . n o 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 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

4.38. Aadiendo replicacin a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . . . n o 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. Modicando la contrasea de un usuario usando ldappasswd . . . . . . . . . . . . n 4.42. Instalacin del servidor NFS a travs de apt-get . . . . . . . . . . . . . . . . . . . o e 4.43. Instalacin del gestor de raid mdadm usando apt-get . . . . . . . . . . . . . . . . o 4.44. Automatizacin en la creacin del raid . . . . . . . . . . . . . . . . . . . . . . . . . o o 4.45. Automatizacin en la creacin del RAID . . . . . . . . . . . . . . . . . . . . . . . . o o 4.46. Instalacin de Apache y del mdulo PHP5 para el servidor . . . . . . . . . . . . o o 4.47. Instalacin del servidor Apache2 y del mdulo WebDav/Subversion para el o o servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.48. Creacin de un host virtual en Apache para el host pantuo.escet.urjc.es . . . . o 4.49. Descarga e Instalacin de la herramienta MediaWiki . . . . . . . . . . . . . . . . o 4.50. Conguracin de MediaWiki para autenticar usuarios usando LDAP . . . . . . . o 4.51. Conguracin de Apache para dar soporte a pginas personales de usuarios . . . . o a 4.52. Instalacin de la herramienta postx usando apt-get . . . . . . . . . . . . . . . . o 4.53. Instalacin de los demonios necesarios para dar soporte POP3 e IMAP a pantuo o 4.54. Reiniciando el demonio dovecot tras su reconguracin . . . . . . . . . . . . . . . o 4.55. Instalacin de mailman usando apt-get . . . . . . . . . . . . . . . . . . . . . . . o 4.56. Creacin de una nueva lista de mailman usando el comando newlist . . . . . . . o 4.57. Instalacin de la herramienta debmirror usando apt-get . . . . . . . . . . . . . . o 4.58. Descargando la rplica de Ubuntu usando el comando debmirror . . . . . . . . . e 4.59. Descargando la rplica de Debian usando el comando debmirror . . . . . . . . . . e 4.60. Contenido del chero /etc/apt/sources.list usando la rplica del Laboratorio . . e 4.61. Instalacin de la herramienta Nagios con apt-get . . . . . . . . . . . . . . . . . . . o 4.62. Instalacin de la herramienta Munin (servidor) con apt-get . . . . . . . . . . . . . o 4.63. Instalacin de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . o 4.64. Instalacin de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . o 4.65. Creacin de una tabla en MySQL para almacenar la informacin relativa a o o auditor de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 4.66. Script bsico para registrar informacin de auditor de usuarios . . . . . . . . . . a o a 4.67. L nea de cron para la automatizacin de la auditor de usuarios en el sistema . . . o a 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. Instalacin de la herramienta Denyhosts . . . . . . . . . . . . . . . . . . . . . . . o A.1. El chero de preconguracin necesario para la instalacin desatendida. . . . . . . o o A.2. Fichero de conguracin de Isolinux para el arranque por red. . . . . . . . . . . . . o A.3. Fichero de conguracin de Isolinux para el arranque por red. . . . . . . . . . . . . o 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. Creacin de la base de datos de Auditor . . . . . . . . . . . . . . . . . . . . . . . o 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

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 conguracin /etc/ldap/slapd.conf . . . . . . . . . . . . . . . . . . o C.2. Fichero de conguracin /etc/bind9/named.conf . . . . . . . . . . . . . . . . o C.3. Fichero de conguracin /etc/bind9/db.pantuo.es . . . . . . . . . . . . . . . o C.4. Fichero de conguracin /etc/bind9/named.conf . . . . . . . . . . . . . . . . o C.5. Fichero de conguracin /etc/apache2/sites-enabled/pantuo.es . . . . . . o C.6. Fichero de conguracin /etc/apache2/sites-enabled/pantuo.escet.urjc.es o C.7. Fichero de conguracin /etc/apache2/sites-enabled/webmail.pantuo.es . o C.8. Fichero de conguracin /etc/apache2/sites-enabled/mysql.pantuo.es . . o C.9. Fichero de conguracin /etc/postx/main.cf . . . . . . . . . . . . . . . . . . o C.10.Fichero de conguracin /etc/postx/master.cf . . . . . . . . . . . . . . . . . o C.11.Fichero de conguracin /etc/dovecot/dovecot.conf . . . . . . . . . . . . . . o C.12.Fichero de conguracin /etc/exports . . . . . . . . . . . . . . . . . . . . . . . o C.13.Fichero de conguracin /etc/postx/master.cf . . . . . . . . . . . . . . . . . o C.14.Fichero de conguracin /etc/exports . . . . . . . . . . . . . . . . . . . . . . . o

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

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

xvii

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 trminos e 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 crditos de la obra de la manera especicada por el e 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 nes comerciales. Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, slo puede distribuir la obra generada bajo una licencia idntica a sta. o e e

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

INDICE DE LISTADOS

Proyecto Fin de Carrera

Universidad Rey Juan Carlos

Captulo

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

 1.1. MOTIVACION DEL PROYECTO

1.1.

Motivacin del proyecto o

El presente documento resume casi toda la actividad realizada en un plazo de un ao n aproximadamente como administrador de sistemas de los Laboratorios de Linux de la ETSII1 y la ETSIT2 , en los Campus de Mstoles y Fuenlabrada, de la Universidad Rey Juan Carlos. o 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 realizacin de un Proyecto Fin de Carrera de una Ingenier Informtica, debido a que el o a a 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 diseo conveniente y escalable, y n por ultimo, implementar o implantar poco a poco cada uno de los objetivos propuestos. Por supuesto, un ao da para mucho, para bastante ms que para los hitos que se documentan n a en la presente memoria. Sin embargo, debido a limitaciones de espacio, nos vemos obligados a documentar lo estrictamente necesario y lo ms fundamental. a

1.2.

Estructura de este documento

En esta seccin se indica la divisin en cap o o tulos del presente documento, en los cuales se realizar un anlisis de cada una de las fases por las cuales ha avanzado el proyecto. Este a a documento se encuentra dividido en cinco cap tulos, a saber: El cap tulo de Introduccin, en el cual se presentan cul es la motivacin del proyecto y o a o el estado del arte de cada una de las tecnolog que se han usado en el proyecto. as El cap tulo de Objetivos, en el cual se presentarn los objetivos principales que se han de a desarrollar en el proyecto. El cap tulo de Dise o, n El cap tulo de Implantacin, en el cual se implementan cada uno de los requisitos de los o que consta el proyecto. El cap tulo de Conclusiones, en el que se realiza un anlisis de todos los hitos alcanzados, a los conocimientos adquiridos y todo el trabajo futuro que podr realizarse para mejorar o a terminar de perlar el trabajo realizado. Por ultimo, en los Apndices del presente documento, se incluye el cdigo fuente e o (entindase por cdigo fuente en este proyecto todos aquellos cheros de conguracin y e o o scripts de shell que se han desarrollado) desarrollado en el proyecto. Junto con el presente documento se adjunta un soporte electrnico en CD en el que puede o encontrarse la presente memoria as como todo el cdigo fuente desarrollado en el proyecto. o

1.3.

Estado del arte

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

Escuela Superior de Ingenier Informtica a a Escuela Tcnica Superior de Ingenier de Telecomunicaciones e a

Proyecto Fin de Carrera

Universidad Rey Juan Carlos

 CAP ITULO 1. INTRODUCCION imposible realizar un anlisis del estado del arte de cada una de ellas, nos vamos a centrar a solamente en realizar un breve anlisis de los sistemas de instalaciones desatendidos, por a un lado, ya que uno de nuestros objetivos primordiales (el que nos llevar ms tiempo) a a ser la implementacin de un sistema de instalaciones completamente desatendido que nos haga a o 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 en la cuenta que hoy en d existen multitud de distribuciones que ofrecen do a este grandioso sistema operativo listo para su instalacin. Aunque son pocas las distribuciones que o tienen ms fama hoy en d ser necesario enumerar las bondades y defectos de las ms conocidas a a, a a (principalmente, Debian GNU/Linux, Ubuntu, Red Hat Linux y SuSE). Por ultimo, y dado que nuestro sistema albergar un gran nmero de cuentas de usuario, ser tarea obligada decidir a u a acerca de qu sistema de cuentas de usuario en red es ms adecuado para nuestras necesidades, e a y por supuesto, dotar a este sistema de cuentas de un mecanismo de almacenamiento de cheros adecuado (obviamente, si tenemos un sistema de cuentas en red, el medio de almacenamiento de informacin deber estar en red tambin). o a e Por ultimo, y para no extendernos demasiado, realizaremos un breve anlisis de las a aplicaciones que dotan de funcionalidad de correo electrnico a nuestro sistema (tanto de o recogida como de entrega). De esta manera dotaremos a nuestro entorno con la funcionalidad de que los usuarios sean capaces de recibir correo electrnico en sus cuentas, y stos tambin o e e sean capaces de poder descargar este correo en sus ordenadores personales. Una vez que todos estos sistemas se encuentran perfectamente congurados y funcionando, nuestra labor se centrar en la monitorizacin de todos estos servicios. Para ello, instalaremos una herramienta a o de monitorizacin que de cuenta cuando se produce cualquier tipo de problema o ca de un o da servicio concreto, alertando a las personas oportunas. Estos herramientas sern discutidas en el a apartado Herramientas de monitorizacin. o

1.3.1.

Distribuciones de Linux

En primer lugar, vamos a realizar un breve repaso por las distribuciones de Linux ms usadas a hoy en d Cuando hablamos de Linux, en el sentido ms general de la palabra, nos referimos al a. a kernel o ncleo del Sistema Operativo. El kernel de Linux es el mismo para todas las distribuciones u (normalmente, m nimamente modicado por la distribucin) y puede ser descargado de forma o 3 e instalado en cualquier distribucin sin muchas dicultades. independiente desde Internet o Cuando hablamos de distribucin de Linux nos referimos al conjunto formado por el kernel, las o aplicaciones (que incluya de forma opcional el equipo desarrollador de la distribucin en concreto) o junto con un proceso de instalacin. En este sentido, hoy en d hay miles de distribuciones de o a Linux4 que son usadas por millones de usuarios alrededor del mundo. Sin embargo, hay algunas que merecen especial atencin, y que estn clasicadas como las ms usadas o ms populares hoy o a a a en d En esta clasicacin, se encuentran Red Hat Linux, SuSE o Debian GNU/Linux. a. o Segn podemos comprobar en el cuadro 1.1, la distribucin ms usada hoy en d es Debian u o a a (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 ms usadas (en el a
3 4

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

A. Gutirrez Mayoral e

ETSI Informtica a

1.3. ESTADO DEL ARTE Distribucin o 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 ms usadas en la actualidad. Fuente: LinuxCounter a Distribucin o Ubuntu openSUSE Mint PCLinuxOS Fedora Debian Sabayon Mandriva CentOS Gentoo N mero de visitas ultimo mes u 1944 1557 1351 1053 1036 923 853 776 629 611

Cuadro 1.2: Distribuciones ms usadas en la actualidad. Fuente: DistroWatch a ultimo mes), colocando tambin a Ubuntu y Debian entre los primeros puestos. En este caso se e 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 ultimos aos queda presente en la estad n stica. La distribucin o que hace aos ocupaba los primeros puestos de uso entre los usuarios ha visto comido su terreno a n favor de Ubuntu y SuSE. Quiz los cambios en la organizacin interna de Red Hat (que veremos a o a continuacin) y la aparicin de Ubuntu tuvo como precio la prdida de un gran nmero de o o e u usuarios. En denitiva, existen multitud de distribuciones hoy en d de las cuales slo unas cuantas a, o alcanzan los primeros puestos en nmero de usuarios y en popularidad. En concreto, en los u Laboratorios de Linux de la Universidad se ha usado Debian GNU/Linux desde que comenz su o andadura, hasta hace poco tiempo, que se tom la decisin de pasar a Ubuntu. o o A continuacin vamos a realizar un breve repaso por las distribuciones ms usadas o o a ms populares. En concreto, Debian GNU/Linux, como distribucin que usaremos en aquellas a o mquinas que presten su funcin de servidor. A continuacin, Ubuntu, distribucin que usaremos a o o o en las estaciones de trabajo de los laboratorios. Por ultimo, detallaremos las razones que nos llevan a descartar otras distribuciones como solucin adoptada tanto en los servidores de los o laboratorios como en las estaciones, haciendo hincapi principalmente en las desventajas, ya que e
5

http://www.distrowatch.com

Proyecto Fin de Carrera

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 ao 1993, de la mano de Ian Murdock como n l der del proyecto, y con un objetivo principal: crear una distribucin de Linux que separara o claramente el software libre del no libre. Adems, el modelo de desarrollo de la distribucin es a o completamente ajeno a objetivos empresariales o comerciales, dejando de la mano de los usuarios de la misma la liberacin de las versiones de la distribucin. o o En principio, la adaptacin de Debian ms conocida y ms desarrollada hasta la fecha es la o a a que se basa en el ncleo Linux, comnmente llamada Debian GNU/Linux, aunque existen u u otras ramas de desarrollo basadas en otros ncleos, como Hurd, NetBSD o FreeBSD. El proyecto u Debian se rige por unas directrices muy estrictas en cuanto a la organizacin del mismo: un o 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 software es adecuado o no para la e distribucin, as como la Constitucin de Debian establece cual es la jerarqu interna de la o o a organizacin y como se llevan a cabo y se toman las decisiones principales. Estas normas establecen o cuales son los poderes principales del l der del proyecto (el que est vigente en ese momento) y e las responsabilidades de los desarrolladores en general. Existe una gura visible dentro de la organizacin, el l o der de la misma. Esta gura es elegida por los propios integrantes de la comunidad Debian (principalmente, desarrolladores) y aunque tiene unas atribuciones principales ms all de las de cualquier desarrollador, est lejos de ser a a a una decisin absoluta que tengan que acatar el resto de desarrolladores. El l o der de la comunidad se elige una vez al ao, siendo el primero Ian Murdock (ao 1993-1996) y el ultimo (l n n der actual) Steve McIntyre (abril 2008-hoy). Respecto a los detalles tcnicos, cabe resear que Debian ha conseguido su fama en los ultimos e n aos, cuando el nmero de arquitecturas soportadas se ha elevado considerablemente en los n u ultimos aos, as como el nmero de paquetes incluido por defecto dentro de la distribucin. n u o Actualmente, son soportadas 11 arquitecturas diferentes de hardware en Debian GNU/Linux, y el nmero de paquetes se eleva por encima de 18.000. Actualmente, la distribucin se encuentra u o en la versin 4.0 de manera estable (ltima versin estable liberada), cuyo nombre en clave se o u o denomina Etch. Como curiosidad, los nombres de liberacin de las versiones de Debian hacen o alusin a personajes de la trilog de Disney/Pixar Toy Story, asignndose un nuevo nombre o a a cuando se crea una nueva versin de pruebas. o La organizacin de desarrollo de Debian se divide en tres ramas de desarrollo principales: la o rama estable, la cual es fruto de la congelacin de una rama en pruebas (llega un momento que o la estabilidad alcanzada en la rama en pruebas supone que no se aadan ni nuevos paquetes ni n nueva funcionalidad a la correspondiente rama, creando una nueva versin de la distribucin); la o o rama de pruebas o testing, la cual se compone de todos los paquetes que han ido reduciendo su nmero de fallos provenientes de la rama inestable. Por ultimo, la rama inestable, comprende el u desarrrollo activo y principal de la distribucin. En ella se encuentran los paquetes recin aadidos o e n a la distribucin donde se comprueba su estabilidad, el nmero de fallos y la integracin con el o u o resto de paquetes de la distribucin. En particular y respecto a las diferentes ramas de desarrollo o de la distribucin, siempre se recomienda el uso de la rama estable para uso en produccin (debido o o a la estabilidad y al nivel de depuracin que ha alcanzado esta versin) y al uso de la rama inestable o o si se quiere estar ms al d en cuanto a versiones de un paquete en concreto, incluido dentro a a de la distribucin. Sin embargo, usar la rama inestable puede convertirse en un juego peligroso, o ya que de un d para otro nuestro ordenador puede dejar de funcionar o puede producirse un a problema grave que puede acabar en una reinstalacin si no se tienen los conocimientos necesarios o para solucionar el problema y volver a la situacin original. Los usuarios avanzados de Debian o A. Gutirrez Mayoral e 7 ETSI Informtica a

1.3. ESTADO DEL ARTE conocen esta situacin y normalmente, siempre que su distribucin se encuentra situada en la o o rama inestable, suelen tener mucho cuidado con las actualizaciones o instalaciones de paquetes nuevos. Existe dos ventajas principales de la distribucin Debian GNU/Linux sobre la mayor de o a distribuciones ms usadas hoy en d La principal, es la estabilidad de la rama estable de la a a. distribucin. La independencia de Debian frente a intereses comerciales hacen que los tiempos o de liberacin de la distribucin sean lo sucientemente grandes como para que de tiempo a que o o la distribucin sea revisada todo lo necesario como para que tenga un nivel de calidad ms que o a aceptable. Estos tiempos, de un ao normalmente (como m n nimo) son excesivos para usuarios que desean tener su software al d ultima versin de escritorio, ultima versin del servidor a: o o web Apache, etctera. Sin embargo, estos usuarios deben saber que la rama de desarrollo de e Debian que estn usando no es la ms adecuada para ellos, ya que los tiempos de liberacin tan a a o grandes facilitan que la distribucin sea una de las ms estables y seguras frente a otras ms o a a conocidas, en detrimento de usar las versiones ms actuales y novedosas en lo que a software a se reere. 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 cuestin. La otra ventaja que nos ocupa es la herramienta de instalacin de software, la o o herramienta apt6 . Esta herramienta, muy conocida entre los usuarios de la distribucin y todas o aquellas que se apoyan en sta (Knoppix, Ubuntu y dems) facilita enormemente la instalacin, e a o conguracin y eliminacin de software en Debian (y en todas aquellas distribuciones Linux que o o lo hayan acogido como herramienta de instalacin de software). En principio, esta herramienta o funciona en l nea de comandos, aunque ha medida que ha pasado el tiempo se han diseado n 7. interfaces unicos 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 localizacin de software adicional. De forma ocial, existen repositorios o ociales para Debian que contienen los paquetes incluidos en la distribucin en cada una de las o 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 regin del planeta. Es comn que o u cada Universidad cuente con el suyo propio (como es el caso de la nuestra). Adems, es posible a 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 ms que indicar a la herramienta a apt cual es la localizacin del recurso del correspondiente repositorio (normalmente, a travs o e de una URL comn). El uso de apt es casi una herramienta fundamental en el uso diario del u sistema, facilitando la tarea de instalacin de software enormemente, tanto al administrador como o al usuario de a pi. Tanto, que hoy en d la instalacin de software en sistemas Linux a travs e a, o e de los fuentes (usando el cdigo fuente, compilndolo de forma manual) a quedado relegada a un o a plano muy lejano y casi ya no es usada por los usuarios, tanto por la incomodidad de este mtodo e como por el nmero de errores que normalmente se suelen producir. u Es por ello que realizamos la eleccin de Debian GNU/Linux como sistema base para nuestros o servidores: la estabilidad de la distribucin en su rama estable para sistemas en produccin hace o o que nos decantemos por esta opcin, dejando para el escritorio distribuciones que se apoyen en o Debian (principalmente, por la estabilidad y las herramientas de instalacin de software) pero o que incluyan software ms actual de cara al usuario. a Con el paso del tiempo han sido muchas las distribuciones que han surgido tomando Debian GNU/Linux como distribucin base. La estabilidad y la organizacin de la distribucin hace o o o que muchas distribuciones adopten o partan de ella para crear nuevas distribuciones. Las ms a
6 7

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

Proyecto Fin de Carrera

Universidad Rey Juan Carlos

 CAP ITULO 1. INTRODUCCION conocidas, Knoppix o Ubuntu, que comentaremos a continuacin. o

Ubuntu Ubuntu8 es una de las distribuciones cuyo cociente entre tiempo y popularidad ha sido ms a pronunciado. Basada en Debian GNU/Linux como distribucin base, ha ido desplazando a los o usuarios ms confesos y acrrimos a la distribucin base hasta Ubuntu como sistema principal de a e o escritorio basado en Linux. Los pilares ideolgicos principales en los que se basa Ubuntu son la o facilidad y usabilidad a la hora de usar el sistema operativo, as como la regularidad en la liberacin o de nuevas versiones (normalmente, cada seis meses, en Abril y en Octubre). Est desarrollada a por Canonical, apoyada por el empresario sudafricano Mark Shuttleworth. El proyecto surgi en el ao 2004 aproximadamente, con una nanciacin de unos diez o n o millones de dlares. En la distribucin participan muchos desarrolladores de Debian y de Gnome, o o estos primeros decepcionados con el modo de funcionamiento interno de la distribucin Debian, o por aquel entonces una de las ms usadas, tanto en el escritorio como en el servidor. Estos a desarrolladores buscaron apoyo en el empresario Mark Shuttleworth, que apreci la idea del o proyecto y lo apoy econmicamente. Tras varios meses de trabajo y un breve per o o odo de pruebas, la primera versin de Ubuntu (Warty Warthog) fue lanzada el 20 de octubre de 2004. o Como detalles tcnicos relevantes, podemos destacar que Ubuntu conserva la mayor de las e a ventajas de Debian GNU/Linux, manteniendo como principal la herramienta de instalacin de o software apt. Adems, los periodos de liberacin de Ubuntu son bastante ms cortos, lo que a o a hace que las versiones que se incluyen en la distribucin sean bastante actuales. Normalmente, o Ubuntu suele incluir la ultima versin de los escritorios Gnome y KDE (sino la ultima, una de o las ms actuales) as como las ultimas versiones de los paquetes de software ms importantes. a a Ubuntu no soporta tanto arquitecturas como Debian: se incluyen de manera ocial soporte para dos arquitecturas: Intel x86 y AMD64, sin embargo ha sido portada a ms plataformas de forma a extraocial, 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 distribucin sin necesidad de realizar una instalacin en el disco. Esta funcionalidad o o 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 distribucin basada en Debian o (incluyendo todas sus ventajas, como apt), se incluyen las versiones ms actuales de software a en cada liberacin, de forma que de cara a los usuarios disponemos de un sistema totalmente o actual, no como pasaba anteriormente cuando las estaciones del Laboratorio se basaban en Debian GNU/Linux: los periodos de liberacin tan largos hac que una vez liberada la versin estable, o an o las versiones de escritorio, aplicaciones y dems estuvieran totalmente desactualizadas. a 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 estn basadas en a Ubuntu como distribucin base (al igual que Ubuntu se apoya en Debian). Estas distribuciones o normalmente contienen pocas variaciones con respecto a la original, centrndose normalmente en a las aplicaciones incluidas o en el escritorio por defecto que se usa en cada una de ellas.
8

http://www.ubuntulinux.org

A. Gutirrez Mayoral e

ETSI Informtica a

1.3. ESTADO DEL ARTE SuSE La distribucin SuSE9 es una de las distribuciones Linux ms conocidas y ms usadas en la o a a actualidad. Est basada en la distribucin Slackware y entre las principales ventajas o virtudes a o de esta distribucin est la facilidad de instalacin de la misma (contaba con un instalador o a o grco hace bastante tiempo, cuando ninguna de las distribuciones Linux lo sol incluir) y un a an administrador grco del equipo llamado Yast, el cual facilita la labor de instalacin de nuevo a o software y la conguracin del equipo. En la actualidad, SuSE es propiedad de Novell, desde que o la absorbi en 2004. En el ao 2005, en la LinuxWorld, Novell, siguiendo los pasos de RedHat Inc., o n anunci la liberacin de la distribucin SuSE Linux para que la comunidad fuera la encargada o o o del desarrollo de esta distribucin, que ahora se denomina openSUSE. o Como detalles tcnicos, SuSE usa el escritorio KDE por omisin, aunque incluye tambin e o e 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 distribucin o Red Hat/Fedora. Sin embargo, los cambios que ha sufrido esta distribucin a lo largo del tiempo o as como el sistema de gestin de paquetes que usa (RPM) hace que descartemos esta distribucin o o para ser usada en nuestro entorno. Red Hat/Fedora Core Por ultimo, realizaremos un breve anlisis de otra de las distribuciones ms conocidas en la a a actualidad. La distribucin Red Hat10 , posteriormente Fedora, ha sido una de las distribuciones o que ms reconocimiento ha tenido en los ultimos tiempos. En principio, existen dos versiones a principales de esta distribucin: Red Hat Enterprise Linux, dirigida principalmente al mercado o profesional, y Fedora Core, que surgi en el ao 2003 cuando Red Hat Linux fue descontinuado. o n Digamos que esta divisin es similar a la sufrida por SuSE, que mantiene una versin comercial o o de su distribucin (Novell SuSE Enterprise) y su versin gratuita, openSuSE. De forma similar, o o Red Hat ofrece su versin comercial (Red Hat Enterprise Linux) y su versin gratuita o libre o o (Fedora). Red Hat Software Inc. fue fundada en el ao 1994, y es conocida por aportar numerosas n contribuciones y luchar en pro del software libre. En esos aos la distribucin contaba con gran n o nmero de usuarios y gran popularidad. Sin embargo, el paso de los aos y la aparicin de u n o nuevas distribuciones con mayor estabilidad, mayor nmero de usuarios y de desarrolladores la u ha relegado a un segundo plano, aunque sigue contando con un gran nmero de usuarios en la u actualidad. En cuanto al plano tcnico no hay muchos detalles que comentar. Red Hat Linux al igual que e SuSE usa el sistema de paquetes RPM, un sistema de paquetes un tanto antiguo en comparacin o con el sistema de paquetes apt. El sistema de paquetes es algo tan fundamental dentro de una distribucin que es motivo de descartar esta distribucin para su uso en el laboratorio al igual o o que SuSE.

1.3.2.

Sistemas de instalacin desatendidos o

Dado que uno de nuestros objetivos principales es disear un proceso de instalacin n o desatendida y completamente automatizado, vamos a analizar los sistemas de instalacin o desatendidos ms usados hoy en d por administradores de un nmero muy elevado de mquinas. a a u a En concreto y para el caso que nos ocupa, partimos de la base que necesitamos un mtodo que nos e permita instalar en 300 estaciones de usuario aproximadamente (160 en el Campus de Mstoles o
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 ms rpida y cmoda posible, de cara al administrador a a o de las estaciones y de las instalaciones masivas. Clonacin de disco duro o La clonacin de una particin del disco o del disco duro completo es hoy en d uno de o o a los sistemas ms usados a la hora de realizar instalaciones masivas, bien se trate de entornos a docentes o de entornos empresariales, en los que se debe instalar una mquina rplica de una a e mquina inicial. Este sistema copia bit a bit todos los datos de una particin en un chero para el a o posterior volcado a la inversa en otra particin o disco duro. Dependiendo de la aplicacin con la o o que estemos realizando la clonacin, este proceso ser ms o menos rpido, y nos permitir una o a a a a mayor exibilidad a la hora de realizar la clonacin. o Hoy en d las aplicaciones ms modernas que permiten realizar clonaciones de disco duro, a, a permiten: Lectura de sistemas de cheros ext2/ext3 (aspecto fundamental en nuestro caso) Compresin de los datos para que ocupen menos espacio. Los sistemas de clonacin ms o o a antiguos requer un espacio en disco igual o mayor al del disco duro que se iba a clonar. an Almacenamiento en red de los datos. La imagen del disco duro clonado pod almacenarse a en un servidor FTP, o en un directorio compartido de Windows. Posteriormente, cuando se realizaba el proceso inverso, los datos pod ser descargados de estos servicios en red. an Clonacin de todo el disco duro o de una particin en concreto. Los sistemas ms modernos o o a permiten elegir entre clonar el disco duro al completo, o solamente una particin del disco. o Rapidez de la clonacin del disco duro o particin. Los sistemas ms antiguos empleaban o o a una gran cantidad de tiempo para realizar una clonacin de un disco, con el consiguiente o perjuicio para el administrador. Hoy en d existe un gran abanico de aplicaciones con diferentes licencias pensadas para a, realizar clonaciones de discos duros o particiones para realizar copias de seguridad de datos, realizar instalaciones masivas, etctera. Las aplicaciones comerciales ms conocidas hoy en d e a a pueden ser Acronis True Image11 o Norton Ghost12 . Ambas aplicaciones estn disponibles a a travs de los servicios informticos de Campus, con una licencia totalmente funcional para nuestras e a necesidades. Sin embargo, el balance total entre las ventajas y desventajas entre este mtodo y el e posteriormente elegido como mtodo principal de instalacin, hace que nos decantemos nalmente e o por el mtodo basado en cheros de preconguracin. Existen otras aplicaciones con licencias e o libres que permiten realizar una clonacin de disco duro. En el caso ms bsico, el comando dd o a a permite leer una particin y guardarla en un chero. Sin embargo, este mtodo tan rudimentario o e adolece de ser muy lento, a parte de necesitar como m nimo el tamao en disco de la particin n o para almacenar el chero 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. Adems, la aplicacin Acronis True Image nos permite guardar a o las imgenes de los discos duros que deseemos en un servidor FTP, con las ventajas que ello supone: a cuando deseemos instalar un equipo a partir de una imagen, solamente debemos arrancarlo con el CD de la aplicacin, y seleccionar el servidor FTP donde se encuentran alojadas las imgenes del o a
11 12

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

A. Gutirrez Mayoral e

11

ETSI Informtica a

1.3. ESTADO DEL ARTE equipo en cuestin. Este mecanismo puede resultar muy cmodo cuando el nmero de equipos que o o u 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 nmero de equipos, el proceso de u instalacin, puede resultar tedioso. En nuestro caso, disponiendo de 160 estaciones en el Campus o de Mstoles y 140 en el Campus de Fuenlabrada, resulta prcticamente no asumible. Adems o a a de esta desventaja principal, hemos de aadir que las diferencias entre las estaciones principales n del laboratorio supone que se deba almacenar una imagen por cada modelo de estacin, ya que o la clonacin asume que sta se realiza entre equipos idnticos. En nuestro caso, disponemos en o e e Mstoles de 3 tipos principales de hardware en las estaciones de usuario y de tres tipos en el o Campus de Fuenlabrada. Es por ello que decidimos plantearnos otros mecanismos de instalacin o desatendida para realizar nuestro proceso de instalacin automtica. o a Sin embargo, el mtodo de la clonacin de disco nos vendr muy bien cuando tengamos que e o a arreglar un disco que ha sido reemplazado (por ejemplo, por un problema de hardware) o cuando tengamos que instalar pocas mquinas (una o dos) y el resto ya estn instaladas completamente. a e La razn de esta eleccin es que el mtodo de la clonacin es muy rpido, y no supone la puesta o o e o a en marcha de infraestructura adicional (como es el caso de los cheros de preconguracin, que o estudiaremos posteriormente). En resumen, podr amos decir que las ventajas y desventajas que aporta este mtodo son: e Como ventajas, el mtodo de la clonacin es rpido, sencillo y no requiere maquinaria e o a adicional para ponerlo en marcha. Como desventajas, podemos armar que este mtodo puede ser complejo en caso de que el e nmero de estaciones sea elevado, exige hardware idntico (al menos para una sola clonacin) u e o y que realiza una instalacin no limpia del sistema. o Ficheros de preconguracin o Por ultimo, vamos a realizar un anlisis del uso de cheros de preconguracin para a o realizar instalaciones masivas y completamente desatendidas. El mtodo de los cheros de e preconguracin (el trmino anglosajn es preseeds o cheros semilla). Este mtodo, que se o e o e encuentra disponible en Debian (y sus derivados) a partir de la versin de Sarge, consiste en o incluir en un chero de texto todas las indicaciones necesarias para la instalacin de o bien o un sistema Debian completo (chero de preconguracin para el proceso de instalacin) o bien o o un paquete en concreto. A travs de este mtodo, conseguimos que todas las indicaciones o e e preguntas que el proceso de instalacin realiza al usuario, sean introducidas automticamente sin o a necesidad de la interaccin del usuario en ningn momento en el proceso de instalacin (siempre o u o que todas las respuestas sean introducidas en el chero correspondiente). El chero de semilla o chero preconguracin es un chero de texto legible por humanos, en el que se incluyen la o preconguracin de cada pregunta en un formato concreto. Este formato, si bien no es a priori o puede resultar un tanto complejo, es bastante automtico en cuanto a la forma de construir a indicaciones para un proceso de instalacin. Cada indicacin se incluye en una l o o nea del chero de texto, y contiene una especicacin en la forma clave/valor para cada paquete a instalar, o incluido el proceso de instalacin (el proceso debian installer ). o Una de las ventajas principales de este mtodo radica en que se puede automatizar todo el e proceso de instalacin al completo, sin ms que responder o incluir todas las indicaciones en el o a chero de preconguracin correspondiente. Adems, estaremos realizando una instalacin limpia o a o de un sistema (a diferencia del procedimiento de la clonacin de una particin o del disco duro). o o Esta instalacin sin duda es ms conveniente para el sistema que replicar una instalacin ya o a o hecha. Por otra parte, los cheros de preconguracin son muy exibles en el sentido que pueden o 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 modicado el arranque) o bien se pueden incluir en una memoria USB o incluso en la red, localizadas por una URL. Este mtodo es especialmente potente y exible, ya que facilita que el sistema pueda ser e instalado completamente por la red, sin necesitar tan siquiera un CD de Debian para realizar la instalacin. Solamente necesitaremos la imagen correspondiente del arranque por red de la versin o o correspondiente que queramos instalar (disponible en cualquiera de los mirrors de Debian) y unas pequeas modicaciones en el arranque para que ste use un chero de preconguracin. Una n e o vez hecho esto, tendremos un proceso de instalacin que no necesita soporte de instalacin (un o o CD, como tradicionalmente se ha instalado el Sistema Operativo) ni ninguna interaccin con el o usuario: tan slo ser necesario reiniciar el equipo y seleccionar arranque por red en la placa o a base para que el proceso comience, se instale correctamente y cuando haya nalizado el proceso, el equipo se reinicie y muestre el nuevo sistema al usuario. Como vemos, la idea es bastante atractiva: tan slo requiere reiniciar el equipo para realizar una instalacin. o o En el cap tulo Implantacin veremos los detalles tcnicos de este proceso, que si bien no o e requiere tan slo de chero de preconguracin en cuestin (es necesario otras tecnolog o o o as paralelas, como arranque por red de Linux, puesta en marcha de un servidor que despache direcciones IP, etctera) no es complicado en exceso. Podemos resumir que el proceso de e instalacin tiene las siguientes ventajas y desventajas principales: o Como ventaja, principalmente es la escasa interaccin con el usuario que necesita (por o no decir nula). La unica accin que se requiere por parte del usuario es reiniciar el equipo o para que comience la instalacin (y esta accin no pertenece propiamente al proceso de o o instalacin). La instalacin del sistema es totalmente limpia (se formatea el disco duro, se o o crea la tabla de particiones, se instala el sistema completo partiendo de cero, se conguran todos los paquetes una vez ste se ha instalado, etctera), lo cual es una ventaja con respecto e e al mtodo de la clonacin. Por ultimo el poder realizar instalaciones por red es una ventaja e o bastante importante, en los tiempos en los que nos encontramos, en el que el uso de soportes de almacenamiento f sicos cada vez est menos extendido. a Como desventaja, podemos indicar que si bien este proceso es muy usado hoy en d por a parte de administradores de sistemas, la documentacin del mtodo de preconguracin o e o es bastante escasa, por no decir nula. Si bien ya empiezan a existir proyectos de Debian dedicados unicamente a esta labor13 , hace un ao aproximadamente resultaba n bastante complicado encontrar recetas de instalaciones desatendidas usando cheros de preconguracin. Tambin cabe resear que el mtodo de cheros de preconguracin suele o e n e o requerir la puesta en marcha y conguracin de tecnolog paralelas que no tienen que ver o as mucho con el proceso de instalacin, como veremos en el cap o tulo Implantacin. o

1.3.3.

Sistemas de autenticacin de usuarios o

Otro de los puntos que es necesario debatir es el diseo e implantacin de un sistema de n o autenticacin de usuarios, necesario para que los alumnos puedan iniciar su sesin en las estaciones o o del Laboratorio. En este sentido, ser necesario analizar las tecnolog actuales que brindan un a as sistema de usuarios en red que proporcione la infraestructura necesaria para que una persona, en posesin de su nombre de usuario y contrasea pueda iniciar una sesin, independientemente o n o 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 autenticacin principales. El primero o de ellos, es el ms rudimentario, basndose en el sistema tradicional de cheros /etc/passwd y a a /etc/shadow con replicacin ante cambios. o
13

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

A. Gutirrez Mayoral e

13

ETSI Informtica a

1.3. ESTADO DEL ARTE En segundo lugar, estudiaremos los sistemas ms avanzados para implementar un sistema de a usuarios en red, y ms usados hoy en d sobre todo la segunda alternativa que planteamos, a a, LDAP, un protocolo basado en directorio bastante ligero y que es una de las alternativas ms a usadas hoy en d ante este tipo de problemas. a Mapa de usuarios local con replicacin o La primera solucin que nos planteamos es la implantacin de un mecanismo de autenticacin o o o basado en un mapa de usuarios locales que se replique a lo largo de todas las mquinas que a componen el laboratorio. El funcionamiento de este mecanismo por tanto, ser el funcionamiento a clsico basado en los cheros /etc/shadow y /etc/passwd superponiendo por encima un a mecanismo que permita replicar estos cheros en todas las estaciones que componen nuestro entorno. Este mecanismo de replicacin se puede llevar a cabo de muy diferentes maneras. Por ejemplo, o implementando un monitor que sondee los cambios en ambos cheros en una mquina concreta a (en la que se producen los cambios, por ejemplo) y vaya propagando estos cambios entre aquellas mquinas interesadas. Esta replicacin se puede llevar a cabo mediante una transmisin simple a o o de cheros usando SSH (usando el comando SCP, por ejemplo). Otra decisin a tomar ser si los cambios lo solicitan los clientes, o es una unica mquina la que o a a propaga los cambios cuando estos se produzcan. En cualquier caso, estas decisiones pertenecen al mecanismo de propagacin de cambios que este mecanismo incorporar Lo fundamental de este o a. mecanismo es comprender que los mecanismos para aadir y borrar usuarios, as como cambiar n una contrasea, por ejemplo, son los mismos que en un sistema Linux/Unix tradicional (al basarse n en los cheros tradicionales de usuarios de cualquier sistema Unix). Sin embargo, este sistema adolece de muchos problemas para ser llevado a la prctica. Como a desventaja principal, la escalabilidad del sistema, que se puede convertir en insostenible. Si el nmero de mquinas es relativamente alto, la propagacin de cambios puede convertirse en un u a o verdadero problema, cuando aadamos muchas cuentas en muy poco tiempo, o simplemente n realicemos un cambio en los datos de los usuarios, a parte de convertirse en un cuello de botella. Adems, si elegimos un diseo en el que solo se pudieran modicar datos en una sola mquina, a n a nos deber amos preguntar qu pasar si un usuario decide cambiar su contrasea (una accin e a n o bastante frecuente). Deber iniciar una sesin en esa mquina y entonces cambiar la contrasea? a o a n Deber poder cambiar la contrasea en la mquina en la que se encuentra, y que esta informara a n a a la mquina maestra de que se ha producido un cambio? Como vemos, la accin ms simple que a o a puede darse en un esquema de cuentas en red, como cambiar una contrasea, puede convertirse en n algo bastante complicado usando este esquema. Sin embargo, aadir y borrar cuentas, as como n cambiar una contrasea en la mquina maestra es extremadamente simple, usando directamente n a comandos del sistema para realizarlo (eso s siempre que sea el administrador el que realice estos , cambios). Debido a que el nmero de pros es mayor a las ventajas que puede ofrecernos esta u tecnolog en principio decidimos estudiar otras alternativas para nuestro diseo de cuentas en a, n red. Sin embargo y como resea, cabe destacar las ventajas y desventajas de la citada tecnolog n a: Como ventaja, podemos decir que un sistema de usuarios locales con replicacin o o propagacin de cambios es bastante simple para aadir y borrar usuarios, as como para o n cambiar contraseas, ya que siempre se usan los comandos estndar del sistema para esta n a 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 diseo, adems de tener que disear un sistema completo de propagacin de cambios n a n o que sea lo sucientemente 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. Adems, este diseo tiene serios problemas de concurrencia, que pueden darse a n cuando dos administradores realicen modicaciones en la cuenta de un usuario. NIS Las pginas amarillas NIS14 , tambin llamadas Sun Yellow Pages es una tecnolog de a e a cuentas de usuario en red (aunque tambin puede ser usado para otros menesteres), desarrollada e principalmente por Sun Microsystems en los aos de los 90. n Esta tecnolog es la que inicialmente se usaba en los Laboratorios de Linux de la Universidad a antes de evaluar soluciones ms avanzadas de cara al aumento tanto de estaciones instaladas en a los Laboratorios como de usuarios en posesin de una cuenta. o La tecnolog NIS se basa en llamadas RPC entre cliente y servidor para el intercambio de a informacin sobre usuarios en sistemas distribuidos, tales como el que nos ocupa. El software que o implementa tal funcionalidad se compone de un servidor, una biblioteca para el lado del cliente y varias herramientas de administracin. En concreto NIS funciona de tal forma que la informacin o o contenida en los cheros /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 cheros fueran locales a la mquina en la que nos encontramos. En cierto modo, el funcionamiento es muy similar a tener a un chero /etc/passwd, /etc/shadow locales, ya que las herramientas para aadir y borrar n usuarios as como cambiar una contrasea son las estndares de Unix, con la unica excepcin n a o que ha de realizarse en el servidor que proporciona la informacin NIS. En el resto de hosts es o 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 aos en los Laboratorios sin muchos problemas. En n cuanto a requerimientos tcnicos, solamente se necesita un servidor que almacene la informacin e o de los usuarios, y conocimientos bsicos de administracin de usuarios en sistemas Unix. Con a o esto, es suciente para poder construir un sistema de cuentas en red basado en NIS. Sin embargo, hay dos problemas fundamentales para este esquema, que desarrollamos a continuacin: o La escalabilidad unicamente hay un servidor NIS de cuentas de usuario con todo lo que ello conlleva: proteccin ante fallos, cuellos de botella, etctera. Sin embargo, cabe destacar o e que en los aos que esta solucin estuvo implantada en los Laboratorios, no se produjeron en n o ningn momento cuellos de botella signicativos, ante un laboratorio de aproximadamente u 90 estaciones de trabajo, lo que deducimos que se debe a lo ligero del protocolo, entre otras cosas. Por tanto, lo ms preocupante es la proteccin ante fallos y ca a o das repentinas del servidor que puedan producirse en cualquier momento. La seguridad de los datos en la red. Usando esta solucin, los datos de los usuarios viajan en o claro por la red, con todo lo que ello conlleva. La informacin relativa al nombre de usuario, o directorio personal de los mismos viaja totalmente en claro, y las contraseas de las cuentas n viajan cifradas con un mecanismo de cifrado simtrico, con lo que el romper este cifrado e es bastante sencillo. Hoy en d no podemos asumir que esto ocurra. Cualquier usuario a malicioso que pueda ponerse entre medias de un cliente y del servidor NIS podr captar a datos de cualquier usuario del sistema. Se hace necesario por tanto aadir un mecanismo n que cifre los datos de los usuarios cuando estos viajan entre cliente y servidor, mecanismo que a d de hoy no posee la tecnolog NIS de Sun. a a
14

NIS son las iniciales de Network Information Service

A. Gutirrez Mayoral e

15

ETSI Informtica a

1.3. ESTADO DEL ARTE Por tanto, debido a estas principales desventajas y a ser un producto tecnolgicamente o desfasado, nos vemos obligados a estudiar otras tecnolog para llevar a cabo el sistema de as usuarios en red. LDAP Por ultimo, nos planteamos el estudio de una solucin basada en directorio, usando para ello o el estndar LDAP15 . LDAP es una tecnolog de reciente aparicin que gestiona un directorio en a a o una base de datos que puede servir en principio para dar servicio a muy dispares aplicaciones, aunque sin duda, una de las ms usadas hoy en d es la autenticacin de usuarios ya sea en a a o sistemas operativos tipo Unix (como el que nos ocupa) o mquinas Windows (a travs de la a e creacin de cuentas Samba). o En nuestro caso, solamente usaremos el directorio LDAP para la autenticacin de usuarios o en mquinas Unix. Aunque una vez puesto en marcha el servicio, se puede utilizar para muy a diversos nes (aparte del descrito) como por ejemplo, la informacin de hosts en la red, o como o servicio de libreta de direcciones. Como tal, LDAP es un estndar detallado como tal en la RFC16 a correspondiente17 . Habitualmente, un servidor LDAP almacena informacin de un usuario de la red, tal como su o nombre de usuario y su contrasea, aunque puede incluir informacin adicional como nombre de n o la persona, ubicacin f o sica, foto personal, etctera. En denitiva, podemos armar que LDAP es e un protocolo de acceso unicado a un conjunto de informacin sobre una red. o En nuestro caso vamos a utilizar este servicio para almacenar la informacin de las cuentas o de usuario del sistema, particularmente y como informacin fundamental, su nombre de usuario o y contrasea. Aunque por supuesto, tambin ser necesario almacenar otro tipo de informacin, n e a o como el nombre y apellidos del usuario en cuestin, correo electrnico, etctera. La tecnolog o o e a LDAP como tal y dado a que unicamente describe un protocolo, es implementada por numerosas aplicaciones con muy diferentes licencias. Los gigantes informticos han querido hacer suya esta a tecnolog y han liberado aplicaciones que implementa de forma muy diferente (y con unos a nombres muy diferentes) un servicio de directorio basado en LDAP. En concreto, Microsoft distribuye la aplicacin Active Directory, bajo la cual se almacena informacin de usuarios, o o recursos de la red, pol ticas de seguridad, conguracin, y asignacin de permisos, entre otras o o cosas, en entornos de redes Windows. Ni que decir tiene que se trata de una solucin comercial o y por tanto, de pago, por lo que para nosotros queda descartada automticamente, debido a la a naturaleza del entorno en el que nos encontramos. Otro producto muy similar es el liberado por Novell, Novell Directory Services. Esta aplicacin o es la implementacin de Novell utilizada para manejar el acceso a recursos en diferentes servidores o y computadoras de una red en la que se representan como objetos los servicios ms usuales en una a red, como una impresora, una estacin, un servidor, un servicio, una persona, etctera. Una vez o e denidos los objetos en la base de datos, se asignan los permisos para el control de acceso. Dado que esta solucin tambin es una solucin comercial, no nos planteamos abordarla en nuestros o e o objetivos. Por ultimo, la aplicacin OpenLDAP es una implementacin del protocolo LDAP basada o o en el concepto de software libre desarrollada por el proyecto OpenLDAP, que comienza aproximadamente en el ao 1998. Esta implementacin del estndar LDAP, esta incluida en la n o a mayor de distribuciones Linux ms usadas hoy en d (por supuesto se encuentra en las basadas a a a en Debian GNU/Linux, como Ubuntu). La implementacin incluye un servidor (llamado slapd ), o
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 tcnico que describe el comportamiento de un e protocolo de red. 17 http://www.faqs.org/rfcs/rfc2251.html es la RFC de LDAP en su versin 3. o
16 15

Proyecto Fin de Carrera

16

Universidad Rey Juan Carlos

 CAP ITULO 1. INTRODUCCION un demonio de replicacin de datos (llamado slurpd ) y una serie de bibliotecas que implementan o el estndar LDAP. Adems, esta implementacin soporta mltiples esquemas de datos, entre los a a o u que se encuentran los necesarios para representar una cuenta en un sistema Unix y un grupo, por lo que nos sirve para representar la informacin de cuentas de los usuarios del sistema. o Adems de todo lo descrito hasta ahora, OpenLDAP dispone de multitud de aspectos a avanzados que lo convierten en una solucin bastante factible a la hora de decantarse por un o sistema de cuentas en red, particularmente, La posibilidad de aadir replicacin de datos entre servidores OpenLDAP : Como veremos n o posteriormente en el cap tulo Implantacin, es posible disear un esquema de servidores o n maestros-esclavos de tal forma que exista tolerancia ante fallos de red o de suministro elctrico, adems del consiguiente reparto de carga. e a Reparto de carga entre diferentes servidores LDAP: Del lado del cliente, es posible repartir las peticiones de informacin sobre diferentes servidores LDAP. Esto es especialmente o interesante en un entorno en el que nos encontramos, en el que existe un gran nmero u de usuarios y de estaciones que van a realizar peticiones sobre el servidor LDAP. Veremos ms adelante como podemos llevar este diseo a cabo y cuales son las ventajas que nos a n 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 autenticacin o solicitud de informacin sobre el mismo. Para ello, se utilizarn o o a las bibliotecas SSL de cifrado de informacin entre ambos extremos, que asegurarn o a condencialidad 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 en un estndar de facto a la hora a a de implementar un sistema de autenticacin de usuarios en red y ser la opcin elegida para la o a o construccin de nuestro servicio de autenticacin de usuarios en red. o o

1.3.4.

Sistemas de cheros en red

Dado que estamos trabajando con un entorno de red basado en estaciones de trabajo en las que los usuarios pueden iniciar su sesin y trabajar con un conjunto de cheros (a los que o llamaremos directorio personal de usuario o cheros de usuario) es necesario implantar un sistema de cheros en red que sea capaz de dotar al entorno de un servicio de cheros en red que permita a los usuarios poder usar sus cheros independientemente de la estacin en la que se encuentren o trabajando. En este sentido, no existen muchas alternativas para poder implementar esta funcionalidad dentro de un sistema operativo Linux o Unix. Una de las ms conocidas y la ms usada por a a excelencia, es el sistema de cheros en red NFS18 . En los ultimos aos se ha extendido una n alternativa a esta opcin, el sistema de cheros usado en comparticiones con sistemas operativos o Windows. Esta solucin suele ser adoptada en entornos h o 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 anlisis resulta interesante por si en algn a u momento es necesario plantear la posibilidad de instalar sistemas Windows en el Laboratorio ante el requerimiento de software docente de alguna asignatura. Cabe resear que aunque son sistemas de cheros en principio muy diferentes, las dos opciones n pueden funcionar perfectamente en conjuncin: si un host arranca un sistema operativo Windows, o
18

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

A. Gutirrez Mayoral e

17

ETSI Informtica a

1.3. ESTADO DEL ARTE usar el sistema de cheros en red que facilite el servidor Samba, y si arranca el sistema operativo a Linux o cualquier otro basado en Unix, usar el anlogo basado en NFS. Por tanto, los directorios a a sern lo mismo, simplemente la manera de servirlos ser diferente: en un caso se usar el sistema a a a de cheros para comparticiones Windows (Samba) y en otro, para sistemas Linux (NFS). NFS El sistema de cheros NFS (Sistema de cheros en red) es un protocolo a nivel de aplicacin o segn el modelo OSI). Este sistema de cheros en red es muy usado en entornos de red en el que u 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 de las distribuciones a Linux actuales. El sistema NFS suele estar compuesto de un servidor, y uno o ms clientes. Los a 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 necesitarn a 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 sesin, sino que todos los directorios HOME se o encontrarn en el servidor de cheros NFS y los usuarios importarn o montarn (trmino muy a a a e usado en sistemas Linux que hace suele hacer alusin a empezar a usar un sistema de cheros) o este directorio en la estacin de trabajo en la que se encuentren. o No es objetivo de esta seccin enumerar los aspectos tcnicos del protocolo, ya que estos se o e 19 . Las pruebas que se han llevado a cabo en encuentran descritos en la RFCs correspondientes 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 mquina es la que lleva a cabo esta tarea, sin que sea necesario la divisin del servicio para su a o 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 rea local (y por tanto no es necesario servir a travs de un sistema de a e cheros de Windows los directorios personales de los usuarios) ser la solucin que adoptemos en a o el entorno que nos ocupa. Samba Samba es una implementacin de software libre del protocolo de archivos compartidos de o Windows para sistemas operativos tipo Unix/Linux. Antiguamente recib el nombre SMB, pero a fue renombrado recientemente a CIFS. Gracias a esta implementacin es posible que ordenadores o con Linux, MacOS o cualquier Unix en general sean capaces de servir o ser clientes de cheros en redes Windows. Samba tambin permite validar usuarios haciendo las labores de Controlador e 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 impresin, directorios compartidos y autenticar con su propio archivo de usuarios. o
19

http://tools.ietf.org/html/rfc3530 es la RFC del protocolo NFS en su ultima versin. o

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, estn las distribuciones a 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 opcin, aunque es interesante analizarla por si en un futuro no muy o lejano es necesario instalar Windows para la docencia de alguna asignatura del Departamento.

1.3.5.

Servidores de correo electrnico o

Dotar al entorno de un sistema de gestin del correo electrnico nos brinda una o o cantidad enorme de nuevas funcionalidades. Sin entrar an en cuales pueden ser estas nuevas u funcionalidades, es necesario indicar que bajo el punto de vista de organizacin independiente o 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 electrnico que se usa por defecto sobre cualquier mquina Unix. Es por esta razn que o a o 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. Adems, a este mecanismo tambin puede ser usado para otros menesteres, entre ellos, enviar al alumno e las notas de sus exmenes parciales, noticias acerca del funcionamiento interno del Laboratorio, a etctera. e Para ello, se decide la implantacin de un sistema de transporte de correo (MTA) que asuma o las funciones de recogida de correo electrnico bajo los dominios de cada uno de los campus en o los que disponemos de un Laboratorio de Linux (Mstoles y Fuenlabrada) y que facilite de un o buzn de correo electrnico a los usuarios. Adems, como posteriormente veremos en el cap o o a tulo de Implantacin, instalaremos un servidor de recogida de correo (para que los usuarios sean o capaces de recoger su correo electrnico usando un gestor como Outlook, Evolution, Eudora, o etctera) y un webmail, que facilitar que todos aquellos usuarios que no quieran o no puedan e a recoger su correo electrnico usando un gestor, lo puedan consultar en el web. En el cap o tulo Implantacin se detallar ms ampliamente este mecanismo. A continuacin vamos a enumerar o a a o las alternativas ms frecuentes y ms conocidas en lo que a servidores o agentes de correo se a a reere. Por un lado, es necesaria la instalacin de un agente de correo o Mail Transport Agente, o que se encargue de la recogida de todo el correo que llega a cada uno de los servidores: de este lado, analizaremos los servidores ms comnmente usados en este sentido: Postx y Sendmail. Una a u vez completada esta tarea, ser necesaria la instalacin del citado servidor de recogida de correo. a o 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 ms conocidos y a usados en la actualidad: Courier y Dovecot (aunque por supuesto, existen muchos ms). Cabe a resear que las pretensiones de estos servidores no van ms all que la simple entrega y recogida n a a 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 opcin u otra, nos centraremos bsicamente en o a la facilidad de instalacin de cada herramienta. o Sendmail Sendmail a d de hoy es uno de los proyectos ms conocidos dentro del Software Libre. a a Sendmail es un Agente de Transporte de correo, o MTA (Mail Transport Agent). Esta aplicacin o se encarga de encaminar los mensajes de correo electrnico en Internet para que lleguen a su o destino. Se arma que Sendmail es uno de los principales encaminadores de todo el trco a de correo electrnico en la Internet mundial, de ah la importancia de este agente de correo o electrnico. Comenzaba su andadura cuando la Internet moderna comenzaba sus pasos, de ah que o una de las principales dolencias de Sendmail sea uno de los aspectos que en principio no era un A. Gutirrez Mayoral e 19 ETSI Informtica a

1.3. ESTADO DEL ARTE problema cuando Internet comenzaba sus pasos: la seguridad. Segn los principales detractores de u esta herramienta adolece de numerosas fallas de seguridad (muchas descubiertas y documentadas, y quien sabe las que tiene por descubrir), aunque normalmente estn son arregladas a las pocas a horas de ser noticadas. Otro de los principales problemas de los que adolece Sendmail es de su conguracin. Mientras o la mayor de los servidores de recogida de correo tienen cheros de conguracin legibles por a o humanos (human-readables) los propios desarrolladores de Sendmail arman que los cheros de conguracin de la herramienta no cumplen esta condicin, y recomiendan al administrador de o o sistemas encargado de congurar esta tediosa herramienta el aprender un lenguaje basado en macros para la conguracin de la misma (M420 ). o Adems de soportar evidentemente el protocolo SMTP de correo electrnico, Sendmail da a o soporte a una gran variedad de protocolos de correo electrnico, como ESMTP, DECnets mail11, o HylaFax, QuickPage o UUCP. Como vemos, Sendmail es una aplicacin con una funcionalidad o bastante extensa para nuestros propsitos, que diculta su conguracin enormemente, por lo que o o en un principio ser descartada en favor de una aplicacin que aunque con menor funcionalidad, a o sea ms sencilla y rpida de congurar. a a Postx Al igual que Sendmail, Postx21 es un agente de transporte de correo (MTA) que encamina los mensajes de correo electrnico desde el origen hasta el destinatario. Actualmente, Postx o se encuentra en su versin estable 2.5, liberada aproximadamente en Enero de 2008. Postx o surgi como principal alternativa a Sendmail: se buscaba un gestor de correo electrnico seguro, o o fcil de administrar y cuya instalacin no supusiera un quebradero de cabeza para muchos a o administradores de sistemas a lo largo de toda Internet. Con este objetivo, Thomas J. Watson desarroll las primeras versiones de Postx, o antiguamente conocido como VMailer y IBM Secure Mailer. Postx es el sistema gestor de correo predenido en muchas distribuciones de Linux (por ejemplo Ubuntu), y en las ultimas versiones del sistema operativo de Apple (Mac OS Tiger y Leopard). Respecto a los detalles tcnicos, el cdigo fuente de Postx suele ser citado como ejemplo de e o buena prctica de programacin. Aparte de este detalle, Postx posee muchas funcionalidades a o que hoy en d son casi primordiales a la hora de congurar cualquier servidor de correo: soporte a para comunicaciones seguras (usando la capa de seguridad TLS), capacidad de ltrar el correo mediante listas grises, uso de diferentes bases de datos para obtener fuentes de usuarios, dominios etctera (entre ellas, MySQL, PostgreSQL, LDAP, bases de datos Berkeley, etctera), soporte de e e formato mbox y Maildir para almacenar los mensajes de correo, etctera. Como se puede observar, e la funcionalidad de este gestor de correo es bastante extensa, lo que puede incitar a pensar que su conguracin puede ser incluso ms complicada que la de su principal rival, Sendmail. Nada ms o a a lejos de la realidad. La instalacin y conguracin de Postx se realiza en apenas tres pasos, sin o o ms que indicar si se desea instalar un gestor de correo que reciba correo de Internet, el dominio a para el que se desea recoger correo y poco ms. Por supuesto, si la conguracin es ms extensa, a o a se debern personalizar los cheros de conguracin al gusto, para conseguir la conguracin a o o deseada segn las necesidades de cada administrador. No obstante, los cheros de conguracin u o de Postx son bastante sencillos de asimilar (principalmente la conguracin se realiza editando o un unico chero, el chero /etc/postx/main.cf ) y la conguracin avanzada no resulta muy o complicada, existiendo gran documentacin en Internet y conguraciones estndar ya escritas o a para la mayor de los supuestos casos que nos podemos encontrar. a
20 21

M4 es un procesador de macros de propsito general, desarrollado por Brian Kernighan y Dennis Ritchie. o http://www.postx.org/

Proyecto Fin de Carrera

20

Universidad Rey Juan Carlos

 CAP ITULO 1. INTRODUCCION Debido a la rapidez de la instalacin de esta herramienta y su posterior conguracin (para o o nuestros requerimientos, la conguracin estndar es ms que necesaria) ser el gestor de correo o a a a que elijamos como agente de transporte de correo para el Laboratorio, frente a su principal competidor (Sendmail). En el cap tulo Implantacin estudiaremos ms en detalle la conguracin o a o 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 eciente. En este sentido, ser necesario instalar y a congurar un servicio de recogida de correo. Estos servicios facilitan a los usuarios la descarga del correo electrnico usando un gestor de correo electrnico para el escritorio, como por ejemplo o o Outlook (para Windows), Eudora, Mozilla Thunderbird, Evolution, etctera. A travs de estos e e gestores los usuarios podrn descargar el correo del Laboratorio sin necesidad de tener que a conectarse al servidor para leerlo en el terminal, algo engorroso en algunos casos. Para ello, nos planteamos la instalacin de alguna herramienta que facilite este servicio. Hoy o en d los ms usados en la distribuciones Linux que vamos a usar como principales (Debian y a, a Ubuntu) son Courier y Dovecot, que repasaremos a continuacin. o Courier Mail Server, o comnmente llamado Courier, tambin es un agente de transporte u e de correo MTA que facilita la operacin de los protocolos POP e IMAP para la recogida de o correo. Estos protocolos son los que facilitan que los gestores de correo e informacin personales o puedan conectarse al servidor y descargar el correo electrnico a cada uno de los ordenadores de o los usuarios. Adems, Courier puede funcionar como gestor de correo electrnico (como Postx y a o 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 aadir soporte POP e IMAP n usando una conexin segura). o La instalacin de Courier se divide en aquellos elementos que se desea instalar, segn el o u protocolo ofrecido al usuario (POP, IMAP, POP bajo SSL, etctera) existiendo un paquete para e cada funcionalidad. La conguracin de Courier es algo compleja para nuestras necesidades, por o lo que en principio, nos decantaremos por una opcin ms sencilla de instalar y congurar, como o a es Dovecot, un servidor POP e IMAP muy sencillo de congurar. 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 tambin una conexin segura, es decir, POP3s e e o IMAPs). Esta aplicacin ha sido escrita principalmente por Timo Sirainen y fue liberada por o primera vez en 2002, por lo que despus de seis aos podemos armar que la herramienta se e n encuentra lo sucientemente madura como para ser usada en produccin (la ultima versin es la o o 1.1.2 que fue liberada en Julio de 2008). La instalacin y posterior conguracin de Postx es extremadamente sencilla, basndose o o a unicamente en un chero de conguracin (el chero /etc/dovecot/dovecot.conf ). En este o chero se indica los protocolos que se desea ofrecer (pop3, pop3, imap o imaps) y algunas otras indicaciones relativas a los certicados (en caso de que ofrezcamos conexiones seguras), los directorios de ejecucin, el formato de los mensajes de correo almacenados, etctera. En realidad o e es muy probable que con tan solo indicar los protocolos ofrecidos la herramienta funcione a la primera, de ah la sencillez de su conguracin. Para nuestro caso es ms que suciente (en un o a momento somos capaces de ofrecer un servicio POP/IMAP bajo conexiones seguras a los usuarios
22

http://www.dovecot.org/

A. Gutirrez Mayoral e

21

ETSI Informtica a

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 monitorizacin o

Los sistemas de monitorizacin nos permiten conocer en todo momento el estado de la red, o formado por un conjunto de mquinas que ofrecen una serie de servicios a disposicin de los a o usuarios. En este sentido, las herramientas de monitorizacin realizan un sondeo continuo de o todas las mquinas que conforman una red, comprobando que todos los servicios que dispone esa a mquina estn funcionando adecuadamente. En caso de que alguno de ellos no est funcionando a a e como debiera, el sistema enviar una alerta, normalmente en forma de correo electrnico al a o administrador de la aplicacin. Este correo electrnico pondr en aviso al responsable de la o o a mquina o mquinas en cuestin afectadas por el problema, que tomar las medidas oportunas. a a o a 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 mquinas a que se encuentren en problemas. Normalmente, la mayor de los sistemas de monitorizacin a o ofrecen un interfaz web amigable para el usuario donde se muestran los resultados de la monitorizacin de la red. Es el caso de las tres herramientas estudiadas en esta seccin: Zabbix, o o Munin y Nagios. Zabbix Zabbix23 es una solucin de monitorizacin de cdigo abierto de las ms avanzadas hoy en d o o o a a. Permite la monitorizacin y registro del estado de varios servicios de red, servidores, estaciones, o etctera. Almacena los datos que registra en un sistema gestor de base de datos del tipo MySQL, e PostgreSQL, SQLite o Oracle. Adems dispone de un frontend o interfaz unico escrito en PHP, a 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 mquinas y servicios (por ejemplo, una a pasarela SMTP o un servidor HTTP) Zabbix permite la monitorizacin avanzada de una mquina o a instalando un componente llamado agente zabbix (Zabbix Agent) en el host en cuestin. Este o agente permite la obtencin de datos del host como por ejemplo el uso de memoria, procesos, o espacio libre en disco, etctera. Los agentes env la informacin al servidor para almacenar los e an o datos y mostrarlos de una forma amigable para el usuario a travs de un interfaz web. e En la imagen 1.1 podemos observar una de las capturas de pantalla del interfaz web de gestin de Zabbix, en el que se muestra el estado particular de un host: uso de memoria, carga o de procesador, espacio en disco, carga de red, etctera. Como se puede ver en la imagen, las e estad sticas resultado de la monitorizacin realizada por Zabbix resultan ser bastante detalladas, o quiz ms de lo que en un principio necesitamos. Adems, la instalacin y posterior conguracin a a a o o de esta herramienta puede ser demasiado compleja, lo suciente para que no compense realmente con respecto a nuestras necesidades. Digamos que los reportes ofrecidos resultan ser bastante ms a detallados de lo que en un principio necesitamos: saber qu mquinas estn disponibles en cada e a a 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 ms simple para nuestros propsitos. a o No obstante, vamos a destacar las principales ventajas y desventajas de esta herramienta de monitorizacin. o Como ventajas, podemos decir que los reportes obtenidos por esta herramienta son muy detallados, obteniendo grcas en diferentes formatos de toda la informacin acerca del a o estado de la red y de los hosts que creamos oportuno. Esta informacin nos puede ayudar o
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 ms que a aceptable. Adems de esto, Zabbix, soporta un gran nmero de plataformas (incluidos a u Solaris, Linux, Mac OS, FreeBSD, HP-UX, etctera). En la actualidad el ncleo de Zabbix e u 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 conguracin de la herramienta es bastante compleja y podemos o armar que su manual de instrucciones tiene muchas pginas, lo que puede echar para atrs a a a alguien que en principio quiera usar esta herramienta para monitorizar una red de no muy grandes dimensiones. Nagios Nagios24 es una aplicacin bastante parecida a Zabbix, en muchos sentidos: permite o monitorizar el estado de un conjunto de mquinas en una red, comprobando disponibilidad tanto a de las mquinas como de los servicios asociados a ella. Cuando se produce un problema, Nagios a env una alerta a un contacto o grupo de contactos informando del problema producido y su a nivel de peligro. La diferencia ms importante de Nagios respecto a Zabbix es que Nagios en a principio no puede monitorizar el estado interno de una mquina (carga de memoria, procesador, a espacio en disco, etctera), aunque en principio estos datos no son de nuestro inters, ya que para e e
24

http://www.nagios.org

A. Gutirrez Mayoral e

23

ETSI Informtica a

1.3. ESTADO DEL ARTE nosotros es ms importante conocer el estado de la red en tanto a mquinas y servicios. a a Adems de la monitorizacin constante que realiza Nagios, ste ofrece un portal Web donde a o e monitorizar todos los resultados. Si en un momento dado queremos ver de una pasada rpida el a estado de un host o de un grupo de hosts podemos realizarlo usando para ello su interfaz web. Respecto a la conguracin de Nagios, podemos armar que no es demasiado complicada. Existen o diversos cheros de conguracin donde se indican por un lado, las mquinas de las que consta o a nuestra red, por otro lado y por otro los servicios que se desean comprobar sobre estas mquinas. a Digamos que la conguracin es ms tediosa que complicada, debido a la verbosidad de los cheros o a de conguracin. An as puede resolverse ecientemente si disponemos de un chero de texto o u , donde se indique la direccin IP de cada mquina y su nombre correspondiente. Usando un script o a de shell muy sencillo podemos generar el chero de conguracin de nagios de forma trivial. Una o vez que se han declarado todas las mquinas en el chero de conguracin, se indican los servicios a o que se desean comprobar para cada mquina. Como es muy frecuente agrupar las mquinas en a a grupos (en nuestro caso, las agruparemos por laboratorios y por grupos de servidores) Nagios nos permite declarar grupos de hosts. De esta forma, ser ms sencillo indicar que se desea comprobar a a un cierto servicio sobre un determinado grupo de hosts. Una vez que se han declarado mquinas, grupos de mquinas y servicios, solamente deberemos a a indicarle a Nagios los contactos a los que se desea enviar informacin en caso de problemas. De o la misma forma que antes, Nagios permite declarar contactos y grupo de contactos. Es usual que los responsables de un conjunto de mquinas sean ms de una persona, de ah esta funcionalidad a a muy acertada en la herramienta. Una vez se han congurado estos parmetros, se lanza Nagios y se pueden consultar a travs a e de su pgina web el estado de la red, y si se ha congurado para ello, nos llegar mediante correo a a electrnico los avisos de las alertas correspondientes. o Nagios est disponible como paquete Debian/Ubuntu en las versiones estables actuales de a ambas distribuciones, por lo que su instalacin es trivial. No obstante, tambin puede ser instalado o e mediante fuentes, si queremos tener disponible la ultima versin estable de la herramienta. Debido o a la sencillez de la conguracin (generada automticamente con scripts) nos decantaremos por o a Nagios como herramienta de monitorizacin de nuestro entorno. o Finalmente y para recapitular, podemos decir que, Nagios presenta las siguientes ventajas y desventajas:

Como ventajas, su conguracin es muy simple y se puede realizar en apenas minutos, o partiendo de un chero 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 conguracin, la herramienta o empieza a obtener todos los reportes sin ms. a 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 tambin puede convertirse en una ventaja. En el entorno en el que nos encontramos, e estos reportes son ms que sucientes. Otra de sus desventajas es que solamente existe a una versin para sistemas operativos de la familia Unix (y por tanto, Linux). No existe o actualmente una versin para Windows, aunque en principio esto no nos afecta ya que en o nuestro entorno no disponemos hasta la fecha de estaciones Windows. Esto ocurr tambin a e con su principal competidor, Zabbix, con la diferencia de que Zabbix puede obtener las estad sticas completas de monitorizacin de una mquina Windows, debido a que dispone o a de una versin de su agente para este sistema operativo. o Proyecto Fin de Carrera 24 Universidad Rey Juan Carlos

 CAP ITULO 1. INTRODUCCION Munin Por ultimo, analizamos la herramienta Munin25 . La aplicacin Munin es una herramienta de o monitorizacin de red y del sistema en general (ms bien, del sistema). La aplicacin se distribuye o a o 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 mquinas a que se desea monitorizar o de las que se desea obtener estad sticas. Adems, dispone de un gran a nmero de plugins o aadidos para recoger y procesar todo tipo de datos interesantes para el u n administrador: carga de procesador (procesos), carga de memoria, espacio en disco, carga de la red, nmero de operaciones de entrada/salida, etctera. Adems, dependiendo de si el servidor u e a dispone de una serie de servicios o no, Munin ser capaz de obtener datos de estos servicios. Por a ejemplo, para un servidor MySQL, Munin es capaz de obtener el nmero de consultas por unidad u 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 nmero de pginas servidas por unidad de tiempo. En general, Munin dispone de un amplio u a 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: Representacin del uso de memoria en una mquina a travs de Munin. Fuente: o a e Wikipedia La aplicacin est pensada para visualizar unicamente los datos que son recogidos a travs de o a e los diferentes nodos. Una vez que estos datos son recogidos, se muestran a travs de un interfaz e
25

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

A. Gutirrez Mayoral e

25

ETSI Informtica a

1.3. ESTADO DEL ARTE web las diferentes grcas que se corresponden con cada uno de los servicios. En la imagen 1.2 a podemos ver cmo se representa el uso de memoria en una mquina a travs de Munin. Munin o a e utiliza la herramienta RRDTool26 para la representacin de sus pginas. o a La conguracin de Munin es extremadamente simple, ya que unicamente hay que instalar o la aplicacin cliente en cada uno de los nodos que se desea monitorizar y el servidor en aquella o mquina que se desea usar para representar la informacin. En los clientes, se especica en un a o chero de conguracin qu mquina es el servidor (para permitirle recoger los datos que el cliente o e a recopila) especicando la direccin IP del mismo. En el servidor, se indica a qu clientes se debe o e acudir para recopilar toda la informacin que se desea monitorizar. Y nada ms. Una vez hecho o a esto, el servidor Munin se conectar a los clientes peridicamente para representar la informacin a o o que le facilitan los clientes. Como el uso de esta aplicacin no implica no usar el resto, hemos decidido instalarla en o una mquina para obtener grcas relativas al uso de los diferentes servicios en cada uno de a a los servidores. Ya que la conguracin es extremadamente simple, no nos llevar mucho tiempo o a debido a que el nmero de servidores en nuestra red no es muy elevado. Finalmente, indicamos u las ventajas y desventajas de esta herramienta: Como ventaja, podemos armar que la conguracin de Munin es extremadamente sencilla, o realizndose en apenas minutos para el entorno en el que nos encontramos. Adems, las a a estad sticas obtenidas por Munin son muy detalladas y nos brindan una informacin muy o concisa. Como desventaja, podemos decir que el sistema de noticacin es algo pobre y algo o extrao de congurar. Aunque, como Munin en s mismo no est pensado como sistema n a de noticacin, simplemente podemos usarlo para visualizar las grcas de los diferentes o a servidores y estaciones y usar Nagios como sistema de noticacin. o

26

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

Proyecto Fin de Carrera

26

Universidad Rey Juan Carlos

Captulo

Objetivos
Una vez realizada una introduccin tanto a la motivacin del proyecto como a los objetivos o o principales, vamos a detallar de forma concisa en qu consistir cada uno de ellos. Para ello, e a detallaremos cada uno de los objetivos y como lo afrontaremos. Nos proponemos dos objetivos principales, basados en el desarrollo de un sistema de instalacin automtico y desatendido y la o a implantacin de un sistema de cuentas de usuario en red. Una vez que ambos objetivos han sido o llevados a cabo, se ampliar la funcionalidad del entorno dotndolo de servicios de valor aadido a a n y ampliando la seguridad del mismo todo lo que podamos. Con esto conseguiremos un entorno bastante able 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 utilizadas, as en este cap tulo abordaremos los objetivos que se han perseguido durante la elaboracin del o 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 aadido (pgina web, correo electrnico, n a o etctera) e Instaurar un servicio de monitorizacin de la red y de los servicios o Aumentar al mximo la seguridad del entorno. a

2.1.

Sistema de instalaciones masivas y desatentidas

El primer objetivo que abordamos es la implementacin de un mecanismo que permita o automatizar la instalacin de estaciones de usuario basadas en Ubuntu Linux, de una forma o lo ms automtica y desatendida posible. Este mecanismo permitir la instalacin masiva de a a a o laboratorios de una forma cmoda para el administrador de las mismas, y en un corto espacio de o tiempo. Hay que tener en cuenta que cada Laboratorio se compone de al menos cuarenta equipos, por lo que el que exista un mtodo de instalacin que no sea el tradicional (basado en un e o medio extra ble que se instala en un equipo, siguiendo una serie de pasos) resulta prcticamente a indispensable. El mecanismo de instalacin que perseguimos construir debe instalar todo el o sistema, con todos los requisitos necesarios, sin que sea necesaria la intervencin del usuario o administrador que lo realiza (nicamente, la iniciacin del proceso). Nuestro objetivo ser siempre u o a que la interaccin entre el administrador y el proceso de instalacin sea m o o nimo, como veremos posteriormente. A veces, esto no ser posible, como veremos en el cap a tulo Implantacin, donde o se estudiar detenidamente la construccin de esta herramienta. Sin embargo, y en comparacin a o o con los mtodos estudiados y descartados, la interaccin del administrador con el proceso de e o instalacin casi siempre ser m o a nima. En el mtodo estudiado e implementado se ha dotado al e sistema de un sistema de instalacin desatendido que solamente requiere que el administrador o inicie el proceso. El sistema se instalar sin requerir ninguna accin por parte del usuario y cuando a o ste haya sido completado, la estacin se reiniciar automticamente, iniciando el nuevo sistema e o a a recin instalado. e Para la construccin de este sistema de instalacin automtica nos basaremos en diversas o o a tecnolog siendo la primordial los cheros de preconguracin de Debian GNU/Linux. Este as, o mecanismo ser estudiado con detalle en el cap a tulo de Implantacin del presente documento. o

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 sesin en el sistema usando o para ello una credencial basada en nombre de usuario y una palabra de paso o contrasea. El n sistema debe facilitar que un usuario pueda iniciar siempre una sesin en cualquier estacin del o o Laboratorio, independientemente de cual sea sta. De la misma forma, debe facilitar la creacin e o de nuevos usuarios, o el cambio de la palabra de paso de un usuario en concreto. Ser razonable a el marcar como objetivo que un cambio de una contrasea de un usuario, permita que el usuario n Proyecto Fin de Carrera 28 Universidad Rey Juan Carlos

CAP ITULO 2. OBJETIVOS inmediatamente vea reejado que el cambio afecta a todas las estaciones del Laboratorio: no ser a razonable que si el usuario ha efectuado un cambio en su contrasea, la nueva palabra de paso no n se viera reejada inmediatamente al iniciar una sesin en cualquier otra estacin del Laboratorio. o o Como objetivo primordial para esta fase tambin nos marcaremos el aadir privacidad a e n los datos que viajan por la red relativos a las credenciales del usuario que intenta iniciar una sesin en una estacin del Laboratorio, o que efecta un cambio en la palabra de paso o o o u contrasea de su cuenta. Esto es muy importante ya que al encontrarnos en un entorno basado n 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 contraseas pertenecientes a un usuario en concreto. Si no aadimos un mecanismo que permita n n ocultar estos datos de forma conveniente, nos podemos encontrar con alguna que otra sorpresa desagradable. Veremos posteriormente en el cap tulo Implantacin como este aspecto se soluciona o convenientemente aportando una solucin basada en bibliotecas de cifrado sobre el protocolo que o se ocupa de las cuentas de usuario. En principio no aportamos ms detalles tcnicos sobre este a e objetivo, ya que se estudiarn en detalle en el cap a tulo oportuno. Adems, junto con el sistema de cuentas de usuario en red, ser conveniente proporcionar a a un servicio de disco en red. No ser lgico que cada vez que un usuario iniciara una sesin a o o en un equipo, tuviera unos cheros diferentes a una sesin iniciada previamente en otro equipo o (es decir, cada mquina con sus cheros independientes). Como es lgico, el inicio de una sesin a o o en una estacin debe llevar asociado un espacio en disco personal, independiente de la estacin o o en la que se inicia la sesin y que est siempre disponible. Estudiaremos posteriormente como o e implementar este servicio.

2.3.

Servicios adicionales

Construir un sistema de instalacin completamente automtico y desatendido y dotar al o a entorno con un sistema de cuentas de usuario en red y lo sucientemente seguro y conable sern nuestros objetivos principales. Una vez completados estos hitos, nos marcamos ampliar la a funcionalidad del entorno con otros aspectos secundarios. En general, estos objetivos sern en a su mayor servicios de valor aadido, que harn del sistema un entorno ms funcional y ms a n a a a agradable de cara al usuario nal: los alumnos. En esta seccin, nos planteamos la persecucin de los siguientes hitos: o o Dotar al entorno de una pgina web: dotar a los Laboratorios de un sitio web facilita a el aprendizaje por parte de los usuarios al funcionamiento del mismo, as como facilita una plataforma para la documentacin de preguntas frecuentes de usuarios, anunciar noticias o 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 relacionado con las cuentas de dominio unico que se facilitan a los usuarios y a profesores de la Universidad por ser miembros de ella, implementaremos un sistema de correo unido a las cuentas que entregarn correo en la direccin compuesta por el nombre a o 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, podrn a 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 comunicacin con los usuarios del sistema que no sea el correo electrnico. o o Sistema de resolucin de nombres local: de cara a aadir funcionalidad y tolerancia o n de fallos, es interesante el aadir un sistema de resolucin de nombres local interno a los n o A. Gutirrez Mayoral e 29 ETSI Informtica a

 2.4. MONITORIZACION DEL SISTEMA Laboratorios. Esto permitir la resolucin de nombres de dominio ms rpidamente que a o a a si se usara un servidor de resolucin de nombres ajeno al mismo, adems de aumentar la o a 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 Organizacin. o Listas de correo: la utilizacin de listas de correo tiene dos objetivos principales. Por o un lado, la comunicacin entre los administradores del Laboratorio y los usuarios, por o medio de una unica lista de correo. A travs de esta lista de correo se mandan avisos, e noticias, recomendaciones de uso sobre el Laboratorio y en general cualquier nota que sea de inters para los usuarios del sistema. Los avisos que se mandan a esta lista son e recibidos automticamente por los usuarios del mismo solamente por el mero hecho de a disponer de una cuenta en los Laboratorios. Por otro lado, la creacin de un sistema de o listas de correo nos va a permitir el gestionar determinados avisos y alertas que lleguen a determinados grupos de personas encargadas de la gestin de los Laboratorios (profesores, o administradores, etctera). Por ejemplo, alertas sobre ca e das en los servicios (fallos elctricos, e de red, etctera) o incidencias que se producen en el entorno (enviadas por los propios e usuarios). La creacin de listas permite que los mensajes sean enviados a varias personas o con facilidad adems de ser almacenados para su posterior consulta. a Rplicas locales de Debian y Ubuntu: Dado que la instalacin de software (paquetes, e o 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 rplica local o espejo de un servidor de software de Debian GNU/Linux e o de Ubuntu resulta realmente interesante. Si esto no fuera as cada paquete de software , que se deseara instalar en una estacin o servidor deber ser descargado desde la rplica o a e correspondiente. Esta rplica, an no estando muy lejos (podemos disponer de una rplica e u e 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 razn, la instalacin de una rplica local siempre ser un punto muy a favor para disminuir o o e a el trco externo y aumentar la velocidad a la hora de instalar software en los Laboratorios. a Copias de seguridad de directorios de usuario: con el n 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 cheros personales de los usuarios. Posteriormente en el cap tulo Implantacin estudiaremos como se han llevado a cabo cada o uno de estos requisitos que acabamos de denir.

2.4.

Monitorizacin del sistema o

En este tipo de entornos, parece que el trabajo queda nalizado cuando todos los hitos que nos plantebamos se han completado y todos los sistemas se encuentran funcionando en fase de a produccin. Nada ms lejos: una vez que el sistema est en marcha, la monitorizacin del sistema o a a o se convierte en el aspecto fundamental para el correcto funcionamiento del mismo. En nuestro caso, y dado el elevado nmero de estaciones existentes y servidores que hacen que el entorno u funcione correctamente, la evaluacin de un sistema de monitorizacin de servicios ser algo o o a fundamental y completamente necesario si no queremos encontrarnos una maana con que un n 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 en marcha un sistema de monitorizacin de todos a o los servicios existentes en el Laboratorio: por un lado, se vigilar que no haya ca masiva de a da estaciones (las cuales son producidas normalmente por interrupciones del uido elctrico). En e este sentido, es importante saber en todo momento cuando se ha producido una ca masiva da de estaciones: es signicado de que algo no va bien. Sin embargo, no ser necesario conocer a cuando un ordenador ha dejado de estar disponible (se encuentra apagado), ya que puede ser por muy diversos motivos y en principio, que una estacin deje de funcionar (una o un nmero muy o u pequeo) no debe ser motivo de distraccin. Por otro lado, ser muy importante vigilar que todas n o a aquellas mquinas que proporcionen servicios bsicos para el funcionamiento del Laboratorio a a (esto es, servidores) se encuentren disponibles siempre, en todo momento. Al contrario que en las estaciones, la ca de una sola de estas mquinas debe requerir nuestra atencin inmediatamente da a o y debe ser resuelta lo ms rpido posible. Normalmente, estos avisos son enviados por correo a a electrnico, o son noticados mediante avisos sonoros. En cualquier caso, la noticacin inmediata o o de problemas en el entorno debe ser fundamental. Estos mensajes son interesantes para los administradores del Laboratorio, si bien para los alumnos siempre resulta util conocer cuantas estaciones estn disponibles en un momento dado, a para poder iniciar una sesin en una de ellas. Si bien esta informacin no es fundamental, es o o bastante interesante de cara a encontrar una estacin disponible en un momento dado para o poder iniciar una sesin remota. En este sentido, llamaremos partes de guerra a los informes de o estaciones disponibles existentes en el Laboratorio, y podrn ser consultados desde la pgina web a a del Laboratorio. En resumen, ser condicin indispensable para este proyecto la implantacin de un sistema a o o que permita monitorizar en todo momento el estado de todos los servicios del Laboratorio: estaciones (si estn funcionando, cuantas en cada momento, etctera) y servidores (que estn a e e 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 ms seguro posible. Cabe destacar que nos encontramos en un entorno con las a siguientes caracter sticas: Aproximadamente 3000 cuentas de usuario 160 estaciones de trabajo en el Campus de Mstoles y 100 en el Campus de Fuenlabrada o Todas las estaciones de trabajo y servidores disponen de IPs pblicas. u 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 adems con IPs pblicas a u (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), ste sea e interceptado inmediatamente. Es comnmente sabido que no hay mayor defensa que un buen ataque. Pues bien, en este u 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. Gutirrez Mayoral e 31 ETSI Informtica a

 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 travs de SSH. e Desarrollar un sistema de auditor que nos permita almacenar un histrico de aquellos a o usuarios que han iniciado una sesin en alguna estacin del laboratorio. o o Utilizar herramientas que nos ayuden en la deteccin de intrusos (o desarrollarlas o nosotros mismos). Vigilar constantemente la fortaleza de las contrase as de los usuarios del sistema. n Siguiendo estrictamente y regularmente esta serie de medidas, seguramente no eliminemos la probabilidad de que alguien ajeno al sistema pueda penetrar en l utilizando o bien una cuenta e de usuario o bien un agujero de seguridad en alguna aplicacin; pero con toda seguridad, esta o probabilidad ser bastante ms baja a no realizar estos chequeos. a a

2.6.

Documentacin o

Por ultimo, un aspecto deseable de nuestro proyecto ser generar la mxima documentacin a a o posible de todos aquellos hitos realizados. Implementaciones, cheros de conguracin, decisiones o tomadas, etctera. Todo aquello que podamos dejar por escrito siempre ser bienvenido para e a poder ser consultado en un futuro bien por nosotros mismos o por la persona que se tenga que encargar de la administracin de los Laboratorios en un momento dado. o Dado que vamos a disponer de una pgina web para los Laboratorios, no ser mala idea a a utilizar esa misma pgina web para poder almacenar toda la documentacin que se ha ido a o generando a medida que los hitos se han ido completando. Una buena idea para almacenar esta informacin podr ser la utilizacin de un sitio web tipo wiki 1 que se pudiera editar usando el o a o propio navegador, incluso por otros usuarios. As diversos usuarios encargados de la gestin del , o Laboratorio podr visualizar y editar los contenidos en caso que lo creyeran oportuno. an

1 Un wiki, o una wiki, es un sitio web cuyas pginas web pueden ser editadas por mltiples voluntarios a travs a u e del navegador web.

Proyecto Fin de Carrera

32

Universidad Rey Juan Carlos

Captulo

Especicacin y Diseo o n
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 ms formal. Debido a que este proyecto no se centra en el desarrollo de ningn producto a u software en particular, no se seguir ninguna metodolog de desarrollo en concreto, basndonos a a a unicamente en la implementacin y puesta en marcha de todos los servicios requeridos. En este o cap tulo enumeraremos los requisitos de cada una de las tres partes diferenciadas desarrolladas anteriormente.

33

3.1. METODOLOG EMPLEADA IA

3.1.

Metodolog empleada a

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 ningn producto software en concreto u (est centrado bsicamente en la administracin de sistemas) en este cap a a o tulo nos vamos a centrar en enumerar todos los requisitos funcionales y no funcionales de los que constaba nuestro desarrollo.

3.2.

Anlisis de requisitos a

El anlisis de los servicios necesarios que deben estar funcionando en cada uno de los servidores a (necesarios para el correcto funcionamiento del Laboratorio) se llevar a cabo mediante una a lista de requisitos funcionales. Debido a que el proyecto se subdivide bsicamente en tres partes a claramente diferenciadas (construccin del proceso de instalacin desatendido, implementacin o o o de un sistema de cuentas de usuario en red y creacin de servicios de valor aadido para los o n 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 interaccin del usuario y el sistema. En nuestro caso, vamos a establecer que el usuario es el o usuario administrador (que puede considerarse como un nivel ms elevado de usuario) y que el a sistema es en cada caso cada una de las partes que nos proponemos desarrollar. Debido a que la interaccin en cada caso es m o nima, no vamos a describir los casos de uso (ni los diagramas ni la descripcin del ujo de eventos en cada caso) cindonos unicamente a la o ne captura de requisitos.

3.2.1.

Proceso de instalacin desatendido o

A continuacin vamos a enumerar la lista de requisitos que debe cumplir el proceso de o instalacin desatendido. En cuanto a los requisitos funcionales, cabr destacar: o a 1. RF1: El proceso debe facilitar la instalacin de un sistema completo Ubuntu Linux, o preferiblemente, en la versin Hardy (numerada como 8.04). o 2. RF2: La interaccin con el usuario en este proceso debe ser nula. El proceso de instalacin o o 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 instalacin automtica debe funcionar en plataformas Linux (tanto o a el sistema instalado, el cliente, como el sistema que provee la instalacin, el servidor). o 2. RNF2: Ser necesario que el cliente posea la capacidad de realizar arranque por red en la a placa base (comnmente llamado PXE). u 3. RNF3: El sistema debe cumplir unas condiciones m nimas de velocidad. Dado que el nmero u de estaciones a instalar ser elevado, es conveniente que se provea de algn espejo local de a u instalacin, para que las latencias sean lo ms pequeas posibles y por tanto, el proceso de o a n instalacin no lleve mucho tiempo. o Proyecto Fin de Carrera 34 Universidad Rey Juan Carlos

 CAP ITULO 3. ESPECIFICACION Y DISENO

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 autenticacin de usuarios del o sistema, en todas aquellas mquinas que conformen nuestro sistema, a travs de un nombre a e de usuario y una contrasea, o palabra de paso. n 2. RF2: El sistema debe autenticar a los usuarios independientemente de la mquina en la a que se encuentren y de forma independiente, es decir, un usuario puede iniciar su sesin al o mismo tiempo en tantas mquinas como desee. a 3. RF3: El sistema debe permitir la creacin de nuevas cuentas de usuario (por parte de un o administrador o una cuenta privilegiada). 4. RF4: El sistema debe permitir que un usuario pueda cambiar su palabra de paso (no ser posible cambiar su nombre de usuario). a 5. RF5: El sistema debe proveer un directorio personal para el usuario donde poder almacenar sus cheros personales, una vez que haya iniciado su sesin. Este espacio permitir que los o a alumnos puedan almacenar sus prcticas en el servidor, y que puedan ver estos cheros y a directorios independientemente de la mquina en la que hayan iniciado su sesin. a o 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 autenticacin, ste debe ser un Sistema Operativo Debian GNU/Linux, a ser posible, en la o e ultima versin estable. o 2. RNF2: En cuanto al sistema de cuentas de usuario en red, ste debe estar basado en un e directorio LDAP, que estar implementado por el software OpenLDAP, en su ultima versin a o estable tambin a ser posible. e 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, stos deben encontrarse cifrados e utilizando tcnicas avanzadas de criptograf que haga muy dif que un usuario no e a, cil 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, replicacin, divisin de carga o o y dems, se debe procurar en la medida de lo posible que el sistema sea tolerante a fallos a (deben duplicarse aquellos recursos que sean necesarios), el sistema sea escalable (se debe realizar un reparto de carga adecuado) y se pueda realizar una recuperacin rpida ante o a cualquier tipo de desastre (se deben realizar copias de seguridad diarias de los datos de autenticacin de los usuarios). o

3.2.3.

Servicios de valor a adido n

Por ultimo vamos a poner en marcha una serie de servicios de valor aadido que van a n ayudar a que el entorno sea ms agradable y funcional de cara a los usuarios. Dado que estos a servicios son opcionales, de cara a que el uso del entorno por parte de los usuarios sea ms a agradable y sencillo, plantearemos en su mayor requisitos funcionales, que sern normalmente a a requisitos recomendados y que no estn del todo denidos, dejando al administrador la eleccin e o de la plataforma, sistema en concreto, etctera. e A. Gutirrez Mayoral e 35 ETSI Informtica a

 3.3. DEDICACION DE LAS MAQUINAS 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 buzn de correo o en el servidor donde recibir mensajes). Este sistema permitir que podamos comunicarnos a con los usuarios del sistema para indicarles cualquier asunto relacionado con su cuenta. 2. RF2: El entorno debe contar con una pgina web, donde se indique el nombre de a los Laboratorios, y a ser posible se documente la mayor informacin posible acerca o 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 algn problema, etctera). Tambin debe facilitar que los alumnos puedan colgar sus propias u e e pginas web, mediante la inclusin de algn directorio en su espacio de disco personal. Esto a o u permitir que puedan generar documentacin sobre las asignaturas y puedan compartirla a o en Internet. 3. RF3: Es recomendable que se implemente algn mecanismo de listas de correo que u permita la gestin de anuncios a los usuarios del sistema, as como la comunicacin interna o o de los responsables del Laboratorio. Adems, las listas de correo pueden ser usadas para a enviar noticaciones relativas al funcionamiento interno del sistema (alertas sobre ca das en servicio, por ejemplo). 4. RF4: Debe implantarse un sistema de monitorizacin y noticacin de todos aquellos o o servicios que sean vitales para el correcto funcionamiento del Laboratorio. Este servicio debe alertar inmediatamente de cualquier ca en cualquiera de los servicios que impida da 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, unicamente vamos a resear lo siguiente: n 1. RNF1: se debe intentar en la medida de lo posible garantizar la seguridad en el entorno. Esto incluye la instalacin de todas aquellas herramientas de deteccin de intrusos, seguridad o o y toma de decisiones relativas a la instauracin de pol o ticas de seguridad que impidan al mximo que un usuario pueda obtener una cuenta de usuario de forma ileg a tima o penetrar en alguno de los servidores cr ticos para el funcionamiento del Laboratorio.

3.3.

Dedicacin de las mquinas f o a sicas

Una vez establecidos los requisitos de manera semiformal, vamos a establecer la divisin de o cada uno de los subsistemas principales entre las mquinas que tenemos disponibles. En principio a en el Campus de Mstoles contamos con aproximadamente siete mquinas que pueden actuar o a como servidores en los cuales se instalarn los servicios ms importantes que darn servicio al a a a Laboratorio. En el Campus de Fuenlabrada contamos solamente con dos servidores. La razn de o esta diferencia en cuanto a nmero de servidores se debe a que inicialmente los Laboratorios de u Linux comenzaron su andada en el Campus de Mstoles, mientras que el Campus de Fuenlabrada o (que presta servicio principalmente a asignaturas que se imparten en la titulacin de Ingenier o a de Telecomunicaciones) ha comenzado hace poco, y continua amplindose actualmente. a En el Campus de Mstoles contamos con las mquinas peloto, zipi, zape, lechuzo, sapientin, o a pantuo y espatula. Como se puede observar, los nombres de los servidores de este campus pertenecen a personajes del cmic Zipi y Zape, de Escobar. Como vimos en el cap o tulo Introduccin, el Sistema Operativo elegido para los servidores ser el Sistema Operativo Debian o a GNU/Linux, en su versin 4.0 (la ultima versin estable, cdigo Etch). o o o Proyecto Fin de Carrera 36 Universidad Rey Juan Carlos

 CAP ITULO 3. ESPECIFICACION Y DISENO

3.3.1.

Peloto

La mquina peloto poseer la direccin IP 212.128.4.7, y albergar el servidor LDAP de a a o a cuentas de usuario de forma primaria (esto es, el servidor LDAP alojado en esta mquina a ser el encargado de realizar escrituras en el directorio LDAP (en caso de que se produjeran). a Adems, albergar un mirror o espejo de los repositorios de Debian y de Ubuntu, para que las a a instalaciones de software en el Laboratorio sean ms rpidas. a a

3.3.2.

Zipi

La mquina zipi poseer la direccin IP 212.128.4.2 y albergar el servidor LDAP en forma a a o a secundaria. Es uno de los servidores secundarios del directorio LDAP en el Laboratorio, adems a de otros servicios. En concreto la mquina zipi albergar el servidor DNS del laboratorio de forma a a primaria, aunque en este documento no ha quedado detallado este servicio.

3.3.3.

Zape

La mquina zape posee la direccin IP 212.128.4.3 y es el segundo de los servidores a o secundarios de LDAP en el Campus de Mstoles. Junto con los otros dos servidores LDAP o existentes en el Campus de Mstoles conforman el conjunto de los servidores de autenticacin o o para este Campus. Como veremos posteriormente en el cap tulo Implantacin, la divisin del o o servicio de autenticacin en diferentes mquinas nos va a garantizar la abilidad, escalabilidad o a y tolerancia a fallos del servicio. En concreto esta mquina, tambin alberga otro servicio no detallado en este documento, que a e es el de resolucin de nombres DNS (la mquina zape alberga de forma secundaria el servicio o a DNS para el Laboratorio).

3.3.4.

Lechuzo

La mquina lechuzo posee la direccin IP 212.128.4.8 y es una mquina cr a o a tica para el correcto funcionamiento del Laboratorio, ya que alberga el servicio de almacenamiento de cheros en red para los usuarios. A travs de este servicio los usuarios al iniciar la sesin disponen de un e o espacio personal en el que almacenar sus cheros personales (prcticas, documentos, etctera). a e Por supuesto, se trata de un servicio distribuido y en el que independientemente de la estacin o en la que inicien la sesin, dispondrn de los mismos cheros. o a Como vimos en el cap tulo Introduccin, la solucin adoptada para implementar este servicio o o se basa en el sistema de cheros NFS de Linux. Aunque este servicio se encuentra duplicado (en la mquina sapientin) el cese en el funcionamiento de esta mquina provocar que los usuarios, a a a an pudiendo iniciar su sesin en cualquier estacin del Laboratorio, no pudieran acceder a sus u o o cheros personales (la autenticacin y el disco en red son servicios en principio independientes el o uno del otro). Es por ello que el funcionamiento de esta mquina es cr a 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 mquina sapientin posee la direccin IP 212.128.4.6 y en cuanto a servicios, podemos a o decir que es una rplica exacta a la mquina lechuzo. Esta mquina dispone de un servicio de e a a disco en red (usando para ello el sistema de cheros NFS de Linux) y posee una copia exacta de A. Gutirrez Mayoral e 37 ETSI Informtica a

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

3.3.6.

Pantuo

La mquina pantuo posee la direccin IP 212.128.4.4 y tradicionalmente ha sido la mquina a o a visible de los Laboratorios de Linux de la Escuela. Antiguamente (en los primeros aos de n existencia de la Escuela, all por el ao 1999) era el unico servidor que exist prestaba servicio de a n a: autenticacin, disco en red, pgina web, correo, serv para que los usuarios (alumnos y profesores) o a a se conectaran e hicieran las prcticas, etctera. Afortunadamente, los tiempos han cambiado y con a e la adquisicin de nuevos servidores dedicados en exclusiva a servicios cr o ticos para el Laboratorio (autenticacin, disco en red, etctera) la mquina pantuo ha sido relegada a ser unicamente la o e a mquina visible o buque insignia de los Laboratorios de Linux. a Esta mquina, solamente prestar servicio de pgina web para los Laboratorios, web personales a a a de los alumnos, y albergar el sistema de correo para los usuarios. La razn de albergar el sistema a o de correo y pgina web en esta mquina, es que los alumnos ya asocian la mquina pantuo con a a a los Laboratorios de Linux, de forma que para ellos es muy fcil recordar (o averiguar) que la a pgina web se encuentra en la direccin http://pantuo.escet.urjc.es o que las cuentas de a o correo del servidor terminan por @pantuo.escet.urjc.es. Adems, vamos a aprovechar esta a mquina para albergar las listas de correo del servidor, lo que nos va a permitir crear un canal a directo de comunicacin entre todos los usuarios de los Laboratorios (para enviar noticaciones, o noticias y notas de rgimen interno sobre el funcionamiento de los Laboratorios). e

3.3.7.

Espatula

Por ultimo, la mquina espatula, con direccin IP 212.128.4.12 servir para albergar los a o a diferentes cheros de preconguracin de las instalaciones desatendidas que desarrollaremos o posteriormente en el cap tulo Implantacin. Adems, en esta mquina instalaremos el servicio o a a de monitorizacin que nos servir para comprobar el estado de la red en todo momento, y que o a enviar alertas en forma de correo electrnico cuando se produzca algn problema en cualquiera a o u de los servidores o de los servicios cr ticos para el funcionamiento del Laboratorio. En principio en esta mquina no alojaremos ningn servicio ms. a u a

3.4.

Servidores disponibles en el Campus de Fuenlabrada

A diferencia del Campus de Mstoles, en el Campus de Fuenlabrada unicamente se dispone de o dos servidores principales, que asumen las labores de autenticacin de usuarios y de disco en red. o Bien es cierto que el nmero de estaciones en este campus es bastante menor que el de Mstoles u o (160 estaciones en el Campus de Mstoles frente a unas 100 aproximadamente en el Campus de o Fuenlabrada), aunque debido a que este nmero est aumentando considerablemente, se prevee u a Proyecto Fin de Carrera 38 Universidad Rey Juan Carlos

 CAP ITULO 3. ESPECIFICACION Y DISENO que el nmero de servidores en el Campus de Fuenlabrada tambin aumente. De momento, los u e dos servidores de los que se dispone son bilo y nano. Estos nombres estn inspirados en la tira a de cmic del mismo nombre, Bilo y Nano, personajes creados por Javier Malonda. Debido a que o el nmero de servidores en este campus es menor, ser inevitable reunir servicios en una misma u a mquina. a

3.4.1.

Bilo

La mquina bilo, posee la direccin IP 193.147.73.54. Es la mquina anloga a pantuo a o a a para el Campus de Fuenlabrada, es decir, albergar el servicio de pgina web para ese laboratorio, a a as como las pginas personales de los usuarios, el servicio de correo y la lista de correo de usuarios a para este Campus. Adems, albergar el servicio de disco en red para los laboratorios de este a a 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 catstrofes). a

3.4.2.

Nano

La mquina nano posee la direccin IP 193.147.73.55 y tiene asociados dos servicios cr a o 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 mquina de repuesto ante cualquier ca en el servicio a da de disco en red que provee la mquina bilo (al igual que la mquina sapientin en el Campus de a a Mstoles). o Como se puede apreciar, disponemos de un unico servicio de directorio LDAP que da servicio a ambos campus, el de Mstoles y el de Fuenlabrada. Por motivos de operacin, el servidor o o primario para este servicio se encuentra alojado en el Campus de Mstoles (debido a que o nuestra localizacin f o sica en la Universidad se encuentra en el Campus de Mstoles, resulta ms o a cmodo tenerlo en este campus). Por el contrario, el servicio de disco en red se ofrece de forma o independiente entre ambos campus, cada uno dispone de su disco particular y de sus cheros. 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 diseados y divididos por servidores todos los servicios n que nos proponemos construir e implementar, en el siguiente cap tulo detallaremos todos los detalles tcnicos que son necesarios para la puesta en marcha de todos los servicios. e

A. Gutirrez Mayoral e

39

ETSI Informtica a

3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA

Proyecto Fin de Carrera

40

Universidad Rey Juan Carlos

Captulo

Implantacin o
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 Diseo. En n primer lugar, arrancaremos formalizando e implementando un proceso completo de instalacin o desatendida. Este proceso, nos facilitar la tarea de realizar instalaciones masivas en poco tiempo a 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 autenticacin que permita a los usuarios poder usar tanto los terminales como o los servidores oportunos. De forma paralela, un servicio de disco en red que permita tener disponible almacenar sus cheros en el entorno distribuido. A continuacin, iremos completando la o implementacin con ms servicios, que sin ser del todo indispensables, son necesarios para que el o a entorno funcione adecuadamente. Estos servicios (Web, correo electrnico, resolucin de nombres, o o listas de correo, etctera) quedarn totalmente implantados y funcionando correctamente a la e a nalizacin del presente cap o tulo.

41

 4.1. HERRAMIENTA DE INSTALACION AUTOMATICA

4.1.

Herramienta de Instalacin Automtica o a

Cuando se dispone de un nmero muy elevado de estaciones o terminales se hace necesario u el disponer de un mtodo de instalacin desatendida para que tanto la instalacin del Sistema e o o Operativo como de todo el software se haga de la forma ms automtica posible. a a Para llevar a cabo esta tarea, se va a utilizar el mtodo de los cheros de preconguracin de e o Debian, como se estudi en el cap o tulo Introduccin. Esta tcnica no es nueva, y viene introducida o e desde la versin 3.0 de Debian GNU/Linux. Como vimos en la seccin Estado del arte, esta tcnica o o e se basa en la inclusin de las respuestas a todas las preguntas del proceso de instalacin de Debian o o GNU/Linux o de Ubuntu, en nuestro caso. Si dejamos alguna cuestin sin especicar, el instalador nos preguntar de forma interactiva o a sobre ella. Como es obvio, cuantas ms preguntas queden respondidas en este chero, ms a a automatizado y por tanto desatendido ser el proceso. Las preguntas respondidas en este chero, a pueden o deben ser las siguientes, por ejemplo: Conguracin de la red (direccin IP, puerta de enlace predeterminada, servidores de o o nombres DNS. Conguracin de la versin de Ubuntu a ser instalada (por ejemplo, la actual 8.04, Ubuntu o o Hardy). Sitio rplica que debe usarse para instalar la distribucin a travs de la red (nuestro mirror e o e local). Disco duro donde ser instalado el Sistema Operativo. a Particionado espec co (novato, experto, usual). Conguracin de la zona horaria. o Conguracin de la herramienta de gestin de software (apt-get). o o Contrasea del superusuario (root) y creacin de un usuario sin privilegios. n o Por ultimo, ejecucin de un script de postinstalacin para personalizar la estacin a nuestro o o o gusto. Como es frecuente en las instalaciones de las ultimas versiones de Ubuntu, la mayor de las a preguntas de la lista anterior son las correspondientes a las del proceso de instalacin, y que o dejndolas todas resueltas, el proceso de instalacin se realizar completamente en silencio, sin a o a realizar ninguna cuestin al usuario y de forma totalmente desatendida. o Este chero de preconguracin debe ser incluido en el CDROM de Ubuntu con el que se o pretenda instalar el sistema1 . Bastar con colocar el chero de texto en el ra del sistema de a z cheros del CDROM y modicar algunas l neas del chero isolinux para poder en marcha nuestra solucin. Para ello, podemos descargar la versin actual de Ubuntu, montar la imagen ISO como o o un sistema de cheros de loopback, copiar y modicar los cheros 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 instalacin de Ubuntu. o
1 Recomendamos la consulta del apndice o los cheros incluidos en el CDROM adjunto para leer un chero de e preconguracin de ejemplo bsico. o a

Proyecto Fin de Carrera

42

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Listado 4.1: Generacin de un CD personalizado de Ubuntu para instalacin automtica o o a
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 algn proceso ms corto? Efectivamente, lo hay. Si nuestro hardware es relativamente moderno, u a y nos permite realizar arranque por red, podemos realizar una instalacin completa a travs o e de la red, sin tan siquiera tener que insertar nuestro CD en el equipo correspondiente. De esta forma, incluso podemos indicar que nuestro chero de preconguracin, se encuentra en una URL o concreta. Esto nos abre la puerta a un mundo de posibilidades: podemos tener un repositorio de preconguraciones 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 travs de red e (usualmente llamado PXE2 . Hablaremos de ello en adelante. De forma impl cita, necesitamos un despachador de direcciones IP automticas, esto es, un servidor DHCP3 . a

4.1.1.

Servidor DHCP para conguracin automtica de Red o a

Como hemos visto anteriormente, si queremos que nuestras instalaciones automticas se a realicen a travs de la red, sin tan siquiera introducir un CDROM de instalacin, necesitamos e o la puesta a punto de un servidor DHCP. Este servidor congurar automticamente la red de a a la estacin que lo solicite, habilitndola para poder descargar tanto el Sistema Operativo como o a todas aquellas herramientas o cheros de conguracin que consideremos oportunos. o 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 rplica e de la distribucin de Linux a instalar ni tampoco en el servidor donde se encuentre el chero PXE o que se descargar para comenzar la instalacin del Sistema Operativo. a o Un servidor DHCP: dhcpd Si estamos usando Ubuntu o en su defecto Debian, una llamada al instalador de software apt-get ser suciente para instalar rpidamente un servidor DHCP. a a Listado 4.2: Instalacin del paquete dhcp a travs de apt-get o e
$ apt - get install dhcp

PXE son las siglas de Preboot Execution Environment, o Entorno de preejecucin. o DHCP son las siglas de Dynamic Host Conguration Protocol, o Protocolo de Conguracin dinmica de o a husped. e
3

A. Gutirrez Mayoral e

43

ETSI Informtica a

 4.1. HERRAMIENTA DE INSTALACION AUTOMATICA Es probable que la herramienta de conguracin e instalacin de paquetes dpkg solicite o o conguracin para el citado paquete (por ejemplo el rango de direcciones IP que se va a despachar o automticamente). En nuestro caso, procedemos a congurar manualmente editando el chero de a conguracin que encontramos en /etc/dhcpd.conf. o Es necesario especicar algunos parmetros correspondientes a la conguracin de la subred a o que estemos usando en ese momento. Listado 4.3: Fichero de conguracin dpchd.conf. Conguracin de subred. o o
1 2 3 4 5

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; }

Adems, vamos a incluir una entrada para que el host beta01.pantuo.es arranque a automticamente a travs de la red: a e Listado 4.4: Fichero de conguracin dpchd.conf. Conguracin de host. o o
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 travs de la direccin MAC4 , asignamos automticamente la direccin IP del e o a o equipo especicando adems que busque el chero de arranque PXE en el servidor 212.128.4.4. a El chero, se llama adems pxelinux.0. a Se recomienda que si el nmero de estaciones a instalar es muy elevado, se programe un u pequeo script de shell (por ejemplo, en bash o sh) para automatizar la tarea de crear el chero n de conguracin de DHCP. Bastar solamente aadir la salida de este pequeo script al chero o a n n de conguracin de DHCP y reiniciar su demonio correspondiente. o

4.1.2.

Arranque por PXE

El protocolo PXE (Entorno de preejecucin) es un protocolo que permite el arranque de o 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 descrito en su especicacin correspondiente5 publicado a o 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 aplicacin (como hemos visto, o hace necesario el uso de DHCP para el arranque). A continuacin veremos como es necesario o que se use otro protocolo de la capa de aplicacin, TFTP para poder descargar la imagen linux o correspondiente que ser arrancada para la instalacin del Sistema Operativo. a o Como dijimos anteriormente, es necesario que nuestro hardware (tarjeta de red y placa base) incluya el uso de esta tecnolog para poder hacer uso de ella. Normalmente a travs de la a e herramienta de conguracin de nuestra placa base podremos ver si se dispone de ella. o
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 versin 2.1 o
4

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 estacin correspondiente, se pulse una combinacin de teclas (normalmente F12 o alguna otra o o tecla funcin) que llame a la ejecucin del protocolo. Una vez arrancado, la tarjeta solicitar una o o a peticin DHCP a la subred para que sta se autocongure. o e Conguracin del servicio TFTP o Por ultimo, y para poder comenzar con la instalacin del Sistema Operativo en cuestin, o o necesitamos una imagen del mismo y que de alguna forma, se pueda descargar de la red desde un servidor hacia la estacin que se est instalando en ese momento. Para ello, se hace uso de otro o e protocolo de la capa de aplicacin, TFTP6 . o TFTP es un protocolo de transferencia de cheros muy similar a su familiar ms cercano a FTP7 . Este protocolo es muy usado cuando se quiere transferir archivos de peque o tama o n n entre estaciones de una misma subred. Ntese que el que este protocolo use el protocolo de o transporte UDP no es una simple eleccin trivial: se asume que no se va a usar TFTP para o transferir cheros 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 autenticacin o cifrado. o 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 travs del siguiente e comando: Listado 4.5: Instalacin del servicio tfptd-hpa a travs de apt-get o e
$ apt - get install tftpd - hpa

Al igual que antes, el paquete solicitar conguracin. Lo vamos a congurar como demonio, a o ejecutndose de forma independiente de inetd. Para ello, el chero de conguracin situado en a o /etc/default/tftpd-hpa contendr las siguientes l a neas: Listado 4.6: Fichero de conguracin /etc/default/tfptd-hpa. o
1 2

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

Vemos como en el chero de conguracin se indica que se servirn los cheros situados por o a debajo del directorio /var/lib/tftboot. Esto nos servir para incluir en este directorio la imagen a de la distribucin de Linux que vamos a instalar posteriormente. o Para aplicar los nuevos cambios, basta con reiniciar el demonio correspondiente, tal y como muestra el listado de rdenes 4.7. o 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 cheros).

A. Gutirrez Mayoral e

45

ETSI Informtica a

 4.1. HERRAMIENTA DE INSTALACION AUTOMATICA

4.1.3.

Arranque por red de Linux

Una vez que todas las herramientas anteriores se encuentran perfectamente conguradas y se encuentran funcionando, necesitamos una imagen concreta de la distribucin de Linux que o queremos instalar. En nuestro caso, necesitaremos una versin de Ubuntu de arranque por o red. Esta imagen contendr una imagen m a nima del kernel de Linux que permitir iniciar los a dispositivos necesarios y comenzar el proceso de instalacin. a o Podemos descargar una imagen m nima de arranque por red desde la pgina de Ubuntu a 8 . En concreto, usaremos la versin de arranque por red de Ubuntu Hardy (8.04) que es la Linux o versin que instalaremos en el Laboratorio. o Una vez que hemos descargado el chero correspondiente, procedemos a descomprimirlo en el directorio ra que sirve nuestro servidor TFTP, tal y como queda indicado en el listado 4.8. z 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 funcionando correctamente y el servidor TFTP a est sirviendo cheros) al solicitar arranque por red en la pantalla de arranque de nuestra estacin, a o deber auto congurarse la tarjeta segn su IP correspondiente, y justo a continuacin, ver la a u o pantalla principal de Ubuntu.

4.1.4.

Ficheros de preconguracin o

A continuacin, vamos a ver de qu manera podemos automatizar todo el proceso de o e instalacin. A partir de un chero de preconguracin, que contiene todas las respuestas al o o proceso de instalacin, podemos evitar que el programa de instalacin de Ubuntu nos realice o o ninguna pregunta sobre la conguracin del Sistema Operativo. o Isolinux Isolinux9 es un cargador de de arranque para Linux (arquitectura i386). Necesitamos editar el chero de conguracin de Isolinux para poder indicar que queremos cargar un chero de o preconguracin. Esto lo podemos hacer de la siguiente forma: o Listado 4.9: Fichero de conguracin de Isolinux o
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 --

Ntese el uso de la directiva preseed/url indicando que el chero de preconguracin es o o un recurso HTTP situado en la direccin indicada por la URL. Si quisiramos haber incluido o e el chero de preconguracin directamente en la imagen m o nima del kernel que se arranca con el proceso de instalacin, deber o amos hacer uso de la directiva preseed/le, indicando la ruta absoluta hacia el chero de semilla. El chero de conguracin de isolinux puede contener numerosas opciones de arranque (cada o 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 co, o de unas opciones de instalaciones concretas. Si queremos que en cada momento se arranque siempre una instalacin en concreto (una o etiqueta LABEL) lo podemos hacer incluyendo las siguientes l neas: Listado 4.10: Fichero de conguracin de Isolinux o
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 preconguracin o Por ultimo, unicamente nos queda empezar a denir el chero de preconguracin que o utilizar el sistema de instalacin automtica para realizar el proceso de instalacin en un modo a o a o no interactivo. Este chero es un chero de texto, visible y modicable por cualquier editor de textos. Podemos usar nuestro editor de textos favorito para poder editar nuestro chero de preconguracin personalizado. o El chero de preconguracin contiene todas las respuestas a cada una de las secciones del o proceso de instalacin. As en vez de solicitar al usuario la entrada por teclado, la leer de o , a este chero. Las opciones ms importantes son las relacionadas con la red, el particionado a del disco duro, la conguracin de la herramienta de gestin de software, y la creacin de o o o usuarios. Mencionaremos las opciones ms importantes, dejando la posibilidad de leer el chero a de preconguracin completo en el apndice de este documento. o e En primer lugar, debemos indicar las opciones necesarias para precongurar la red. En nuestro caso, nos es particularmente interesante que la preconguracin se realice a travs del protocolo o e DHCP. Esto nos facilitar que cada estacin asuma la direccin de red que le pertenece. Una a o o vez nalizado el proceso, podemos cambiar esta conguracin de dinmica a esttica, si as nos o a a sentimos ms seguros ante la ca del servidor DHCP y por ende el cese del funcionamiento de a da todas las estaciones. Esto lo podemos conseguir con las siguientes l neas: Listado 4.11: El chero de preconguracin preseed.cfg. o
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 congurado la red, procedemos a indicar el sitio rplica de donde se e descargar la imagen del sistema base a ser instalada. Es preciso indicar tambin que sistema a e deseamos instalar (versin concreta). Lo podemos indicar con el codename o nombre en clave de o cada una de las versiones. En nuestro caso, vamos a instalar la vesin Hardy (numerada 8.04) de o la distribucin Ubuntu: o Listado 4.12: El chero de preconguracin preseed.cfg. o
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

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

A. Gutirrez Mayoral e

47

ETSI Informtica a

 4.1. HERRAMIENTA DE INSTALACION AUTOMATICA Tenga en cuenta que es interesante tener un mirror o espejo local en la Intranet para acelerar notablemente el proceso de instalacin. Si por motivos de espacio no le es posible instalar un mirror o completo de toda la distribucin, puede usar la herramienta apt-proxy para evitar descargar un o mismo paquete repetidas veces (una por estacin). Notar una mejor notable en el proceso de o a a instalacin. o Una parte importante del proceso de instalacin reside en la conguracin del particionado o o del disco donde se ha de instalar el Sistema Operativo. Esto requiere de numerosas l neas de preconguracin que indican entre otras cosas, que disco ha de usarse en la instalacin (usando la o o nomeclatura clsica de sistemas Unix), que esquema de particionado se va a usar (para novatos, a 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 instalacin). Para ello, indicamos las siguientes l o neas: Listado 4.13: El chero de preconguracin preseed.cfg. o
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

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

d-i 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 crearn a tres particiones, todas ellas debern ser formateadas, y el sistema de cheros de todas ellas ser (el a a sistema de cheros ms usado en particiones Linux). Se indican adems los puntos de montaje a a de cada una de ellas, adems como el tamao (indicando el cilindro de comienzo y el de nal). Se a n recomienda la lectura de las reglas de sintaxis para la formacin de recetas para el particionador o partman. Es necesario congurar el lenguaje predenido del Sistema. Adems, tenemos que congurar a apt-get, la herramienta de gestin de paquetes de Ubuntu. Tambin nos interesar que se use o e a nuestro mirror local (situado en el servidor peloto.escet.urjc.es) y que adems, se usen todas las a secciones de las distribuciones11 . Esto lo conseguimos con las siguientes l neas: Listado 4.14: El chero de preconguracin preseed.cfg. o
34 35

d-i d-i
10 11

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

Receta viene del trmino anglosajn recipe, muy usado en la comunidad Open source. e o 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.

Proyecto Fin de Carrera

48

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION

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

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

Tambin nos interesa congurar la zona horaria del Sistema y su localizacin. Lo conseguimos e o con las l neas siguientes: Listado 4.15: El chero de preconguracin preseed.cfg. o
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 dependern evidentemente de la localizacin de la estacin que se instale en ese a o o momento. A continuacin, vamos a congurar el usuario genrico del sistema, que dispondr de o e a privilegios especiales por medio de la herramienta sudo para convertirse en superusuario: Listado 4.16: El chero de preconguracin preseed.cfg. o
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 contrasea, como se puede observar, se introduce en claro (cifrada con un pequeo hash. n n Recomendamos la inclusin de una contrasea genrica y que una vez terminado el proceso, se o n e sustituyan lo ms rpido posible los cheros /etc/passwd y /etc/shadow. a a En las l neas nales, indicaremos que, como ultima tarea, deseamos ejecutar un script descargado de Internet. A travs de este script, realizaremos todas aquellas tareas que no no e es posible congurar a travs de esta herramienta de preconguracin. En este script podremos e o instalar paquetes, retocar cheros de conguracin, tener en cuenta algunas particularidades o espec cas de hardware, etctera. Esta aplicacin es muy interesante, ya que nos permite dejar el e o sistema al gusto del administrador. Lo conseguimos con las l neas: Listado 4.17: El chero de preconguracin preseed.cfg. o
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 ultimo, indicamos donde se instalar el gestor de arranque. El gestor de arranque es a necesario para poder iniciar el sistema una vez instalado. El gestor de arranque que se usa hoy en d es Grub, en detrimento de Lilo (LinuxLoader) que se usaba hasta hace muy poco en la a mayor de las distribuciones. Lo conseguimos con las siguientes l a neas: A. Gutirrez Mayoral e 49 ETSI Informtica a

 4.1. HERRAMIENTA DE INSTALACION AUTOMATICA Listado 4.18: El chero de preconguracin preseed.cfg. o

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

Preconguracin genrica de paquetes o e El chero de conguracin mostrado anteriormente es vlido para todas aquellas instalaciones o a basadas en la versin Hardy (8.04) de Ubuntu. Sin embargo, si se quiere usar este mtodo en o e futuras versiones, es muy probable que la notacin de la preconguracin haya cambiado. El o o objetivo de este apartado es la de entender como funciona internamente la preconguracin de o un paquete, y poder usar este mtodo para precongurar cualquier paquete en la instalacin, sin e o necesidad de guiarnos por un mtodo genrico (el chero mostrado anteriormente). e e Es muy probable que si usamos este mtodo en versiones posteriores a la usada en el e presente documento, se introduzcan en la instalacin nuevos paquetes (con su correspondiente o conguracin) que hagan que si ste no se encuentra precongurado (entindase por o e e precongurado el que se indique en el chero de preconguracin todas las preguntas a su o conguracin) se muestre el dilogo del proceso de instalacin instando a la persona que realiza o a o el proceso de instalacin a responder a las preguntas que sean necesarias. Comentbamos en el o a cap tulo Introduccin que sin duda una de las ventajas principales del mtodo de instalacin o e o desatentida basada en cheros de preconguracin es que el proceso se realiza automticamente, o a sin necesidad de realizar ninguna accin entre el administrador que instala el sistema y el proceso o de instalacin. Si bien responder a una pregunta o dos en el proceso de instalacin no representa o o mayor molestia, si el nmero de instalaciones es elevado, el proceso puede llegar a convertirse en u tedioso.

Figura 4.1: El proceso de instalacin en Debian/Ubuntu y la preconguracin de paquetes. o o Si nos vemos en el papel de realizar una instalacin desatendida basada en cheros de o preconguracin y tenemos la mala suerte de que el chero incluido en el apndice de este o e documento no resulta completo frente a la preconguracin de todos los paquetes que se instalan o en el proceso de instalacin del sistema, no tenemos que asustarnos, puesto que el mtodo es o e muy simple. En primer lugar, debemos jarnos en qu paquete est solicitando conguracin e a o 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 cuestin. Por ejemplo, en la imagen 4.1 se muestra como el paquete slapd est solicitando o a conguracin adicional. o Una vez que hemos identicado el paquete molesto, debemos obtener sus fuentes para inspeccionar la plantilla de conguracin. Para realizar este paso, podemos optar por diversas o soluciones. Si se tiene congurada una l nea de fuentes en el chero /etc/apt/sources.list, simplemente una llamada a apt-src puede ser ms que suciente. En el listado 4.19 se muestra la a llamada a este comando. Ntese que la llamada a apt-src no requiere privilegios especiales, y que o la instalacin resolver todos aquellos paquetes necesarios, de los que depende el que se quiere o a instalar. Nuestro objetivo solamente ser el paquete indicado en la llamada a apt-src, pudiendo a obviar el resto. Listado 4.19: Instalacin del paquete slapd a travs de apt-get o e
$ apt - src install slapd

Una vez que las fuentes han sido descargadas, es necesario descomprimir el cdigo o fuente del paquete en busca del chero templates. Este chero en la mayor de las a ocasiones suele encontrarse en el directorio debian/ de las fuentes del paquete. En el caso del paquete slapd, el chero mencionado se encontrar en el directorio openldap2.3a 2.4.7/debian/slapd.templates12 . Una vez que hemos localizado el chero, podemos abrirlo con nuestro editor de texto favorito. Un prrafo del chero puede ser el siguiente: a Listado 4.20: El chero 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 chero es muy sencilla: en l se incluyen todas las preguntas que deben e ser respondidas cuando se instala el paquete por primera vez, a travs de la herramienta e debconf. En el caso del fragmento del chero 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 que No y que tiene la descripcin indicada en las l a o neas siguientes. Si estuviramos e interesados en precongurar este paquete, deber amos incluir una l nea por cada pregunta que fuera incluida en la conguracin del mismo. Para el caso de la pregunta anterior, ser suciente o a que incluyramos la siguiente l e nea: Listado 4.21: Precongurando 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 precongurada. Si realizamos este mecanismo para todas aquellas preguntas que intereren en el proceso de instalacin no dejando que sea un proceso desatendido al cien por cien, habremos o conseguido que no sea necesario realizar ninguna accin para instalar el paquete en cuestin. o o Como vemos, la preconguracin de paquetes es un mtodo muy potente y exible, que nos o e brinda la posibilidad de realizar procesos de instalacin completamente desatendidos sin ms o a
12

Fuentes del paquete slapd en la distribucin Ubuntu Hardy. o

A. Gutirrez Mayoral e

51

ETSI Informtica a

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

4.2.

Protocolos situados en la capa de aplicacin o

En esta seccin se detallar cmo se ha llevado a cabo la implementacin todos los protocolos o a o o que son necesarios para el correcto funcionamiento del entorno. Sin duda, los dos ms importantes a son el servicio de cuentas de usuario, y el servicio de disco en red. A travs de estos dos protocolos e los usuarios podrn iniciar su sesin en cada una de las estaciones y poder acceder a sus cheros, a o independientemente de la estacin en la que se encuentren. o

4.2.1.

Servidor LDAP de cuentas de usuario

Un punto muy importante en cualquier sistema que se precie, es la gestin de los usuarios en o red. Teniendo en cuenta que se trata de un sistema que va a soportar un nmero muy elevado de u usuarios en l nea, son muchos los factores a tener en cuenta. La implementacin del servicio de cuentas de usuario se llevar a cabo mediante la gestin de o a o un directorio de tipo LDAP, tal y como estudiamos en el cap tulo Introduccin, donde realizamos o una comparativa de las diferentes tecnolog para llevar a cabo una implementacin de cuentas as o de usuario en red. Instalacin del servicio LDAP o 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 autenticacin segura basado en el protocolo o LDAP. En primer lugar, necesitamos por supuesto uno o ms servidores LDAP. Cabe resear a n en cuanto a la nomenclatura usada, que el trmino LDAP hace referencia al protocolo, descrito e por la RFC13 correspondiente14 ; mientras que existen aplicaciones con diferentes licencias que implementan el citado protocolo. Una de las ms usadas hoy en d en la mayor de servidores a a a Unix y Linux (adems de otros Sistemas Operativos de la familia Unix) es OpenLDAP, un a software que proporciona un servidor basado en el protocolo LDAP. En nuestro caso, ser el que a usemos. Como comentamos en el cap tulo de diseo, en los servidores del entorno se usar la n a distribucin Debian GNU/Linux, en versin estable (actualmente, la 4.0 con cdigo Etch). La o o o instalacin de la aplicacin OpenLDAP en una distribucin Debian es realmente sencilla, y se o o o basa en una llamada muy simple a su herramienta de instalacin de Software, como queda reejado o en el listado 4.22. Listado 4.22: Instalacin del paquete slapd a travs de apt-get o e
$ apt - get install slapd

En Debian, y en la mayor de distribuciones Linux, la aplicacin OpenLDAP se provee a o a travs del paquete slapd. La instalacin del paquete resolver aquellas dependencias que se e o a consideren oportunas para que el servidor pueda funcionar adecuadamente. En el proceso de instalacin del paquete, es necesario responder a algunas preguntas relativas o a la conguracin del paquete en el entorno en el que va a ser instalado. Algunas de ellas son cul o a
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
13

Proyecto Fin de Carrera

52

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION ser la ra del directorio LDAP, la contrasea del administrador, la eleccin del sistema gestor a z n o de base de datos que almacenar los datos del directorio y poco ms. En nuestro caso, hemos a a decidido que: La ra z del a rbol LDAP se identique mediante la cadena siguiente: dc=zipi,dc=escet,dc=urjc,dc=es. Este nombre se debe a la notacin o de los nombres de las mquinas usado en la Universidad. a El tipo de base de datos que almacenarn los datos del directorio ser DBD. a a La contrasea de administrador de LDAP es un dato que queda privado de cara al n administrador del sistema. Una vez que hemos decidido estos parmetros, el servidor queda instalado, y se inicia en a el puerto estndar de LDAP: el puerto 389. Este puerto recibir las peticiones de los clientes a a sobre consultas al directorio LDAP: en texto claro. Cualquier usuario que tenga acceso a la red podr escuchar estas peticiones y averiguar datos sensibles (muy sensibles, como la contrasea a n de su cuenta, por ejemplo) de los usuarios. Es por tanto, que nuestra primera tarea avanzada ser securizar el servidor de cara a crear conexiones seguras entre los clientes y el servidor LDAP. a El protocolo LDAP: conceptos bsicos a Hasta el momento hemos detallado como se lleva a cabo la instalacin bsica de un servidor o a LDAP. Sin embargo, no sabemos hasta el momento como funciona realmente este protocolo. Vamos a realizar una descripcin tcnica muy breve de cmo se organizan los datos en un o e o servidor LDAP y cmo funciona ste realmente (a grandes rasgos). Sin duda, estas explicaciones o e son fundamentales de cara a mejorar la funcionalidad del servidor, poder agrupar los datos en organizaciones o subrboles, y dotar al servidor de aspectos avanzados como son la replicacin y a o el reparto de carga. Como hemos dicho, LDAP proporciona servicios de directorio: una base de datos centralizada de informacin esencial sobre personas, usuarios, grupos de usuarios, etctera. Puesto que cada o e organizacin se estructura de una forma y su denicin de informacin esencial puede ser muy o o o distinta, un servicio de directorio debe ser muy exible y personalizable. El eje fundamental de un servicio de directorio es proporcionar un mapa de distribucin de o una compa en este caso, de una organizacin de los usuarios de una Universidad. Una de las na, o caracter sticas ms visibles de una estructura de base de datos LDAP es la convencin en los a o nombres que se usa: es fundamental llevar a cabo una convencin de nombres que identique la o estructura organizativa de la empresa u organizacin que se quiere representar antes de congurar o el servidor. Este sistema, puede resultar muy parecido y similar al Sistema de Resolucin de o nombres DNS, en el que cada compa debe encajar en un unico nombre de dominio de primer na nivel, pudiendo crear por debajo multitud de nombres dependiendo de la estructura de servicios de la empresa. En este sentido la organizacin de los nombres en una base de datos LDAP es o muy similar. En una base de datos LDAP, la organizacin se estructura en forma de rbol, en el que existe o a una ra o elemento superior que se crea en el momento de la instalacin (este parmetro se z o a corresponde cuando la conguracin del servidor nos preguntaba acerca de la ra del rbol). Por o z a debajo, se encuentran los elementos de informacin llamados nodos, los cuales deben pertenecer o a un tipo concreto. Este tipo, es llamado el elemento estructural del nodo, que en principio, no tiene porqu ser uno solamente, sino que pueden ser varios. Existen varios tipos predenidos que e pueden ser usados para representar elementos de informacin comnmente usados hoy en d o u a: para almacenar la informacin de una persona, podemos usar el tipo person, para almacenar la o A. Gutirrez Mayoral e 53 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION informacin de una cuenta de usuario en un sistema Unix, podemos usar el tipo posixAccount, o mientras que para poder representar la informacin de un grupo en un sistema Unix, se facilita o 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 ms. Sin embargo, si un objeto posee la a estructura posixGroup, seguramente nos baste con saber el nombre del grupo y su identicador numrico. e Podemos decir que cada objeto que exista en el directorio LDAP va a constar de una serie de tipos estructurales a los que pertenece, adems de un nombre o identicador que va a posicionar a 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 rbol, a este tendr un dn diferente a otro. Normalmente, el dn se construye concatenando la sucesin de a o nodos por los que es necesario pasar para poder llegar al objeto, de forma muy similar al servicio de nombres DNS. Existen tipos predenidos que se facilitan para poder agrupar elementos, y poder as crear organizaciones dentro del rbol. Normalmente, estos tipos reciben el nombre de unidad a organizativa o organizational unit. A travs de estos elementos estructurales, podremos agrupar e elementos nales (como cuentas de usuario, por ejemplo) en diferentes subrboles, como veremos a a continuacin. o La jerarqu de nuestro directorio LDAP a Una vez llegados a este punto, es necesario decidir cmo estar estructurado el directorio o a LDAP donde se encontrarn las cuentas de los usuarios de nuestro sistema. Para empezar, a debemos decidir cuales son las diferencias entre los tipos de usuario que vamos a almacenar en nuestro directorio, que se detallan a continuacin: o 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 Mstoles (Escuelas de Ciencias o Tecnolgicas e Informtica) o al Campus de Fuenlabrada (Escuelas de Telecomunicacin o a o y Facultad de Comunicacin Audiovisual). o Sin embargo, los profesores que imparten las asignaturas, suelen pertenecer al Campus de Mstoles (al menos, su localizacin geogrca se encuentra en Mstoles) y pueden impartir o o a o asignaturas en un campus, o en ambos. Adems, es preciso saber de cada alumno, el ao en el que obtuvo la cuenta, sin importar en a n 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 distincin entre los profesores de Fuenlabrada y los profesores de Mstoles) o o y que las cuentas de los alumnos de cada campus deben estar organizadas o separadas por el campus al que pertenecen. Adems, es muy probable que un profesor pueda acceder a recursos o a a mquinas a las que no pueden acceder los alumnos estudiantes. Es por ello que una vez ms, a a deberemos separar muy bien esta organizacin en el esquema del rbol LDAP. Podemos ver una o a primera versin de esta jerarqu en la imagen 4.2. En ella vemos como la ra del rbol LDAP o a z a 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 arbol LDAP contiene dos unidades organizativas principales: alumnos y profesores. Si nos centramos en la unidad organizativa de alumnos, debemos tener en cuenta que stos e pueden pertenecer a dos campus: al campus de Mstoles, o al campus de Fuenlabrada. Es por o ello, que decidimos de la misma forma representar esta divisin en el rbol LDAP en forma de o a 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 Mstoles y alumnos de Fuenlabrada. o Por el contrario, en el grupo de profesores, no es necesario realizar ninguna distincin adicional: o podemos decir que todos los profesores se deben encontrar en el mismo nivel del rbol LDAP. Es a 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. Gutirrez Mayoral e 55 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Esta representacin se puede observar en la imagen 4.4. o

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.

Conguracin de los clientes o Una vez que se ha congurado los servidores, es necesario pasar a congurar los clientes para que stos puedan autenticar a sus usarios mediante un directorio LDAP. Usando Ubuntu, e 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 travs de un directorio LDAP. La instalacin de estos paquetes e o en Ubuntu es inmediata y bastante simple, realizando una llamada al instalador de paquetes apt, como queda reejado en el listado 4.23. Listado 4.23: Instalacin de las bibliotecas necesarias para la autenticacin PAM v LDAP o o a
$ apt - get install -- assume - yes libnss - ldap libpam - ldap

Es posible que los paquetes instalados anteriormente requieran conguracin adicional, como o por ejemplo, la ra del rbol LDAP a partir del cual se buscarn los usuarios a autenticar. En z a a nuestro caso, vamos a responder a todas las preguntas por omisin y a congurar estos datos de o forma manual. En principio, para poder autenticar a los usuarios de un sistema Ubuntu mediante LDAP, es necesario congurar al menos los siguientes cheros: El chero /etc/nsswitch.conf en el que se indicar que los datos de los usuarios y los a grupos proceden de una base de datos LDAP. El chero /etc/ldap/ldap.conf en el que se deben introducir los datos de conexin a los o servidores LDAP (URIs de los servidores) y algn otro parmetro, como por ejemplo si es u a necesario establecer una conexin segura al servidor. o Los cheros /etc/pam ldap.conf y /etc/libnss-ldap.conf, en los que es necesario congurar entre otras cosas, los datos de conexin a los servidores LDAP, la ra del rbol o z a LDAP a partir de la cual se deben buscar a los usuarios, y muchos otros parmetros que a para nosotros sern transparentes. a Proyecto Fin de Carrera 56 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Los cheros de los mdulos de autenticacin PAM, situados bajo el directorio /etc/pam.d/. o o En este directorio se situan los cheros de conguracin de los mdulos de autenticacin de o o o usuario, en los que ser necesario indicar que la autenticacin se llevar a cabo mediante a o a LDAP. Vamos a ver de forma ms detallada los cheros de conguracin ms importantes. a o a Fichero /etc/nsswitch.conf En este chero se indica de donde provienen las bases de datos de los servicios ms importantes a del sistema, como los usuarios y los grupos. En nuestro caso, ser necesario anteponer la palabra a LDAP para indicar que los datos de los usuarios y los grupos provienen de una base de datos LDAP, tal y como muestra el chero 4.24. Listado 4.24: Contenido del chero nsswitch.conf para autenticacin v LDAP o a
passwd : group : shadow : files ldap files ldap files ldap

Fichero /etc/pam ldap.conf Este chero contiene la conguracin de PAM que accede a servicios de directorio LDAP. En o este chero, los datos de conguracin ms importantes son las cadenas de conexin al servidor o a o LDAP y la raiz del rbol a partir de la cual se empiezan a buscar usuarios. Podemos ver esta a conguracin en el siguiente fragmento del chero de conguracin mostrado en el listado del o o chero 4.25. Listado 4.25: Contenido del chero pam ldap.conf para autenticacin v LDAP o a
uri ldaps :// peloto . escet . urjc . es base dc = zipi , dc = escet , dc = urjc , dc = es ldap_version 3 bind_policy soft

chero /etc/libnss-ldap.conf Este chero es bastante parecido al anterior, y contiene la informacin para poder acceder o 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 ms signicativas de este chero son a bastante parecidas al anterior, y se muestran en el listado del chero 4.26. Listado 4.26: Contenido del chero libnss-ldap.conf para autenticacin v LDAP o a
uri ldaps :// peloto . escet . urjc . es base dc = zipi , dc = escet , dc = urjc , dc = es ldap_version 3 bind_policy soft

Mdulos de PAM bajo /etc/pam.d/ o Por ultimo, es necesario congurar todos los cheros de autenticacin de PAM para que usen o la autenticacin bajo un directorio LDAP. Este directorio, contiene los cheros necesarios para la o autenticacin, adems de un chero por cada servicio que requiere autenticacin en el sistema (ssh, o a o screensaver, gdm, etctera). Debemos ser cuidadosos en el sentido de que si tenemos un servicio e que requiere autenticacin pero no aadimos su chero correspondiente en este directorio, ese o n servicio no podr autenticar v LDAP con nuestro servicio de autenticacin. Por ejemplo, si no a a o se crea el servicio de autenticacin screensaver, cuando un usuario lance el salvapantallas en una o sesin X y deje la pantalla bloqueada (es necesario introducir el nombre de usuario y la contrasea o n A. Gutirrez Mayoral e 57 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION para volver a retomar su sesin) no podr desbloquearla, puesto que el servicio salvapantallas o a no podr autenticar contra el servicio de autenticacin LDAP. a o Migracin de cuentas NIS a LDAP o Un aspecto importante de la decisin de implantacin de un servidor LDAP para la o o administracin de cuentas de usuario es la seguridad de poder migrar la base de datos actual o de usuarios (ahora mismo en NIS) a la base de datos LDAP. En el momento en el que se realiza la migracin, el nmero de usuarios en el sistema es aproximadamente de dos mil usuarios (solamente o u en el Campus de Mstoles, que es el primero en el que se propone la migracin). Sin duda, no o o nos podemos plantear la migracin a la tecnolog LDAP si no tenemos una herramienta que o a automatice todo el proceso de migracin de cuentas (es impensable migrar dos mil cuentas de o usuario a mano). Por eso, lo primero que debemos hacer es localizar una herramienta que pueda traducir el chero actual de usuarios (recordamos que la una base de datos NIS es equivalente a los cheros de usuarios /etc/passwd y /etc/shadow tradicionales) a una base de datos o chero de importacin de datos de LDAP, un chero LDIF15 que contendr todos los usuarios o a actuales y que unicamente tendremos que volcar en la base de datos LDAP. Para esta tarea, se provee de unas herramientas muy utiles que nos ayudarn en la tarea de a la migracin de un formato a otro. Una vez ms, este paquete se encuentra en la mayor de las o a a distribuciones usadas hoy en d y como no, en Debian GNU/Linux: a, Listado 4.27: Instalacin del conjunto de herramientas migrationtools a travs de apt-get o e
$ 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 cheros /etc/passwd y /etc/shadow de la mquina donde ejecuta el script en el formato adecuado de una base de a datos LDAP: la salida, mostrada por pantalla, es un chero LDIF que contiene los usuarios de estos cheros transformados al formato correspondiente. Con un poco de mano, podemos transformar este pequeo script escrito en Perl para que n tome como argumentos cheros pasados al invocar al programa, aumentando as la versatibilidad del mismo. Adems, como vimos en el apartado anterior (Jerarqu de nuestro servidor LDAP), a a 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 estndar de Unix, como sed, awk, grep y cut. a Una vez que tenemos los datos de los usuarios almacenados en un chero de intercambio de informacin LDAP (simplemente, redirigiendo la salida de la herramienta de migracin a un o o chero) procedemos a la carga de este chero en el servidor LDAP. Esta operacin, se realiza a o travs de la herramienta ldapadd 16 , de la siguiente forma: e Listado 4.28: Modicando registros en el rbol LDAP usando ldapadd a

$ 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 aadir informacin a un servidor LDAP, se especican los n o siguientes parmetros: a 1. El modicador -x asume que la autenticacin es simple, en vez de usar el protocolo SASL. o
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 localizacin del servidor LDAP, especicado mediante una URI (identicador de recurso o universal). 3. Se pasa como parmetro (-D) el nombre distinguido del usuario administrador, que es en a ese momento el que permite realizar escrituras en el rbol LDAP. En general el modicador a -D sirve para atarse al servidor con un nombre de usuario concreto. 4. El modicador -W para que el comando pregunte de forma interactiva al usuario por su contrasea o palabra de paso. n 5. Y por ultimo, se pasa con el modicador -f, el nombre de chero con los datos en formato LDIF que se pretenden aadir al servidor. n La llamada al comando provocar que se muestre por la salida estndar un pequeo mensaje a a n por cada nodo o entrada que se va aadiendo al rbol LDAP. En caso de error, ste tambin se n a e e mostrar, y depender de cmo se haya invocado al comando la interrupcin inmediata o asumir a a o o la continua carga del chero en el servidor para continuar o no la ejecucin. o 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 sern capaces de autenticar con los usuarios actuales del sistema, a travs de a e un servidor de autenticacin LDAP. A partir de este momento, vamos a centrar nuestra tarea en o dotar al servidor de aspectos avanzados muy interesantes (y muchos de ellos indispensables) como implementar una conexin segura entre el servidor y los clientes (recordamos que ahora mismo o el intercambio de informacin se realiza en texto claro), adems de implementar la funcionalidad o a de reparto de carga y replicacin para aumentar la abilidad y seguridad del servicio. o Aspectos avanzados: Aumentando la seguridad Ahora mismo, tenemos un entorno de autenticacin de usuarios bajo un directorio LDAP o totalmente funcional. Los usuarios podr autenticarse sin problemas en las estaciones clientes, an con la misma contrasea que tuvieran antes (ya que hemos migrado la base de datos de usuarios n y para el usuario nal, la autenticacin es completamente transparente). Sin embargo, sino o realizamos ningn ajuste adicional, podr u amos tener problemas con usuarios maliciosos que tuvieran acceso a herramientas de escaneo de trco en una interfaz de red determinada. Sin a duda, esto en un entorno real empresarial, ser dif que ocurriera. Sin embargo, en un entorno a cil universitario, en el que muchas de las prcticas que se realizan tienen que ver con el anlisis a a del trco de red de determinados protocolos, esto es completamente normal. En la gura 4.5 a se muestran los paquetes capturados en el momento en el que un usuario inicia una sesin en o una mquina. Vemos como bajo el protocolo LDAP, en el campo de datos del paquete TCP a se muestran claramente el nombre de usuario y la contrasea del usuario en cuestin, lo que n o 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 sin antes establecer a una conexin segura entre los clientes y el servidor de autenticacin. Para poder completar esta o o tarea, nos vemos obligados a la realizacin de los siguientes pasos: o Del lado del servidor, ser necesario la creacin de un certicado para poder establecer la a o comunicacin usando los protocolos de seguridad SSL/TLS. Podemos crear el certicado o de dos formas: la ms sencilla (en principio ser la que se usar en nuestro entorno, por a a a simplicidad) contempla la creacin de un certicado auto rmado. La forma ms compleja o a contempla el caso de que nuestro certicado sea rmado por una entidad certicadora (una CA). Podemos usar este mtodo tambin, siguiendo los siguientes pasos: e e A. Gutirrez Mayoral e 59 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

Figura 4.5: La aplicacin wireshark muestra como se mandan los datos de autenticacin en claro o o entre cliente y servidor, con nuestro esquema actual. 1. Creamos la entidad certicadora 2. Creamos el certicado 3. Firmamos el certicado mediante la entidad certicadora. Sin embargo, por simplicidad (en principio, no dependemos de ninguna entidad certicadora) usaremos un certicado auto rmado. De cara a los clientes, deberemos modicar los parmetros de conexin para que sta se a o e realice a travs de otro puerto (el protocolo LDAP sobre SSL usa el puerto 636). En principio e estas modicaciones en los clientes ser ms que sucientes. an a Creacin de un certicado auto rmado o Para llevar a cabo la creacin de un certicado auto rmado hemos de seguir los siguientes o pasos. En primer lugar, hemos de tener instaladas en nuestro sistema las herramientas relacionadas con la creacin de certicados SSL, provistas en su mayor por el paquete openssl. Lo instalamos o a de la forma habitual: Listado 4.29: Instalacin del paquete openssl a travs de apt-get o e
$ 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 certicado, es el siguiente: Listado 4.30: Creacin de un certicado para nuestro servidor LDAP o
$ openssl req - newkey rsa :1024 - x509 - nodes - out server . pem - keyout server . pem - days 365

Entre los modicadores ms importantes de este comando, se encuentran donde se guardar el a a certicado de salida (chero server.pem), la duracin antes de que el certicado expire (365 d o as), Proyecto Fin de Carrera 60 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION y el tamao de la clave (1024 bits). Una vez que invocamos el comando, ste nos preguntar acerca n e a de la informacin que contendr el certicado. Es muy importante que cuando nos pregunte acerca o a del nombre comn o Common Name del certicado, escribamos exactamente el elemento raiz u del rbol LDAP: en nuestro caso, recordamos que era dc=zipi,dc=escet,dc=urjc,dc=es. Si no a escribimos literalmente esto, la conexin desde los clientes fallar. El resto de preguntas tienen o a que ver con la organizacin donde se usar, el correo de la persona responsable, etctera. o a e Conguracin de OpenLDAP para el uso del certicado o Una vez que hemos creado el certicado (ste se encuentra en el chero server.pem) e debemos modicar la conguracin del servidor OpenLDAP para el uso del certicado, y que o ste atienda peticiones a travs de un canal de comunicacin seguro (basado en SSL/TLS). Para e e o ello, editamos el chero /etc/ldap/slapd.conf, que es el chero de conguracin del servidor o LDAP, y aadimos al nal del chero las siguientes l n 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 certicado del servidor a la localizacin /etc/ldap/ssl/. Por ultimo, es o necesario modicar las opciones de arranque del demonio LDAP para que cambie el puerto en el que atender peticiones a partir de ahora. Este paso es muy simple, y se consigue editando el a chero /etc/default/slapd y aadiendo la l n 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 comunicacin usado se basar a partir o a de ahora en SSL/TLS. Si quisiramos tener ambos mtodos de conexin disponibles (tanto seguro e e o como no seguro) hubiera bastado con dejar ambas cadenas disponibles (ldaps:// y ldap://). En principio, como nos interesa que los clientes unicamente puedan conectar al servidor usando un canal seguro, dejaremos la opcin indicada como predeterminada. Una vez efectuados todos o estos cambios, bastar reiniciar el servidor LDAP para que fueran aplicados: a 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

Conguracin de los clientes o Los cambios que se deben efectuar en los clientes para que efecten una conexin al servidor u o LDAP son realmente simples, y se basarn en la sustitucin de la cadena de conexin que especica a o o la localizacin del servidor LDAP. As debemos editar los siguientes cheros: o , En el chero /etc/ldap/ldap.conf, sustituimos la cadena ldap:// por ldaps:// En los cheros /etc/libpam ldap.conf y /etc/libnss-ldap.conf se realiza la misma modicacin. o A. Gutirrez Mayoral e 61 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Adems, en el chero /etc/ldap/ldap.conf se aade la linea tls reqcert never para que a n no se compruebe el certicado del lado de los clientes. Si no aadimos esto, la conexin n o probablemente fallar del lado del servidor, puesto que el cliente no le va a ofrecer ningn a u certicado.

Figura 4.6: Una vez establecida la conexin segura entre cliente y servidor LDAP resulta ms o a dif capturar datos de autenticacin de usuarios. cil o Una vez realizadas todas las modicaciones, procedemos a realizar la misma prueba que realizamos antes. Apoyndonos en la herramienta wireshark, procedemos a autenticarnos en a el sistema. Vemos como ahora el protocolo que se identica es SSL/TLS, y que resulta prcticamente imposible identicar cualquier campo del mensaje puesto que ahora se encuentran a cifrados. Se puede observar en la imagen 4.6 como ahora resulta imposible identicar datos de usuarios analizando el trco que pasa por el interfaz de red. a Aspectos avanzados: Reparto de carga Vimos como en el cap tulo de diseo n bamos a dedicar tres mquinas en el Campus de Mstoles a o para que dispusieran de servidor de directorio LDAP. Evidentemente, en esta conguracin, una o de las mquinas servir la base de datos LDAP de forma primaria (lectura y escritura de datos) y a a el resto de las mquinas lo servirn de forma secundaria (solamente lectura). Esta conguracin a a o nos permitir separar la carga de todos los laboratorios por mquinas (160 mquinas en un campus a a a y 140 en otro es mucha carga para un unico servidor LDAP por campus), adems de poder realizar a replicacin del servidor primario a los secundarios y disponer de la misma base de datos LDAP o en diferentes localizaciones (de cara a que pudiera ocurrir una tragedia y necesitramos acceder a a los datos de las cuentas). La mquina principal en este esquema, tal y como vimos en el capitulo de Diseo, ser la a n a mquina peloto (con direccin IP 212.128.4.7) la cual se va a encargar de servir el directorio a o LDAP de forma primaria. Esto signica que siempre que se necesite realizar una escritura en el directorio (creacin de una cuenta o cambio de una contrasea) se deber realizar en el servidor o n a LDAP de peloto. Por el contrario, las lecturas de datos (autenticacin de un usuario frente al o directorio) se podrn realizar en cualquiera de los servidores secundarios. a Proyecto Fin de Carrera 62 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Las operaciones ms frecuentes en un directorio LDAP suelen ser de lectura, frente a las a operaciones de escritura. Las creaciones de cuenta se suelen llevar a cabo una unica vez en todo el ao (comienzo de curso) y los cambios de contrasea, an siendo ms usuales que las operaciones n n u a de creacin de cuenta, representan un porcentaje totalmente despreciable frente al nmero de o u lecturas para autenticacin que se realizan. o
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 mquinas que se disponen para servir el directorio LDAP de forma secundaria a son zipi (con direccin IP 212.128.4.2) y zape (con direccin IP 212.128.4.3), situadas estas dos o o mquinas en el campus de Mstoles. En el campus de Fuenlabrada, disponemos de una sola a o mquina para la autenticacin, la mquina nano (con direccin IP 193.147.73.57). El nmero de a o a o u estaciones en cada campus (160 en Mstoles frente a 140 en Fuenlabrada) nos hace en principio o disponer de ms servidores de autenticacin en Mstoles que en Fuenlabrada, aunque se prevee a o o que se instalen ms en el futuro en el campus de Fuenlabrada dado que el nmero de estaciones en a u ese campus est aumentando considerablemente. La gura 4.7 muestra una imagen representativa a de la divisin en mquinas de los servidores que dispondrn de servicio de autenticacin LDAP. o a a o Cabe recordar en este punto, que las cuentas de usuario son las mismas para ambos campus (Mstoles y Fuenlabrada), por lo que si en principio el servidor de LDAP de Fuenlabrada deja de o estar disponible por cualquier razn, las estaciones de este campus intentarn autenticar contra o a cualquiera de los servidores de autenticacin instalados en el campus de Mstoles, sin ningn tipo o o u de problema. Conguracin de los clientes para el reparto de carga o La conguracin de los clientes para que puedan conectarse a diferentes servidores LDAP en o caso de que encuentren un fallo en alguno es realmente simple, y basta con aadir en los cheros n /etc/ldap/ldap.conf, /etc/libpam ldap.conf, y /etc/libnss-ldap.conf tantas cadenas de conexin como servidores tengamos disponibles. En nuestro caso, vamos a tener disponibles cuatro o servidores que ofrezcan servicio de autenticacin v LDAP, que se identican por su nombre de o a host. Por tanto, las cadenas de conexin ser las siguientes: o an

A. Gutirrez Mayoral e

63

ETSI Informtica a

 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 con aadir a estos cheros la cadena a n 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 peticin de autenticacin, acudir al primer o o an servidor en la lista de servidores disponibles, en este caso, a la mquina peloto. Si esta no se a encontrara disponible, acudir al segundo recurso disponible, en este caso, la mquina zipi. an a As consecutivamente, hasta que lograran encontrar un servidor que no produjera fallo. Evidentemente, esta conguracin no produce ningn reparto de carga (tal y como se han o u escrito las direcciones de los servidores LDAP) puesto que todos los clientes, intentar siempre an conectarse al servidor LDAP de peloto, posteriormente al de zipi, etctera. Para que el reparto e de carga sea real, es necesario escribir los identicadores 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, etctera. Para ello, podemos realizar la siguiente conguracin. En Mstoles, decidimos que: e o o Las estaciones del laboratorio 108 intenten autenticarse siempre contra la mquina peloto, a luego contra zipi, posteriormente contra zape y por ultimo contra nano. Las estaciones del laboratorio 106 intentarn autenticarse en primer lugar contra zipi, luego a contra zape, a continuacin contra peloto y por ultimo contra nano. o Las estaciones del laboratorio 109 intentarn autenticarse en primer lugar contra zape, luego a contra zipi, posteriormente contra peloto, y por ultimo contra nano. Por ultimo, las estaciones del laboratorio 111 intentarn autenticarse en primer lugar contra a zipi, luego contra peloto, posteriormente contra zape y por ultimo contra nano. Est claro que nos interesa que el ultimo recurso a explorar en caso de que fallen los anteriores, a es el servidor LDAP situado en el Campus de Fuenlabrada, debido a que geogrcamente se a encuentra ms lejos y provoca ms latencia en las conexiones y por tanto en el servicio de a a autenticacin. La conguracin para las estaciones del campus de Fuenlabrada podr ser muy o o a similar, y en este sentido: Las estaciones del Laboratorio 004 intentarn autenticarse primero contra nano, luego a contra peloto, a continuacin contra zipi y por ultimo contra zape. o Las estaciones del Laboratorio 005 intentarn autenticarse primero contra nano, luego a contra zipi, posteriormente contra zape y por ultimo contra peloto. Las estaciones del Laboratorio del Seminario 5 intentarn autenticarse primero contra nano, a luego contra zape, posteriormente contra zipi y por ultimo contra peloto. Est claro que en este Campus primero se intente la conexin contra el servidor ms cercano, a o a en este caso, la mquina nano. A continuacin, se plantean diversos rdenes de conexin a los a o o o 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: Replicacin o No sirve de nada tener varios servidores disponibles para realizar reparto de carga en la autenticacin si no existe coherencia entre ellos. La decisin de dividir la carga en varios o o servidores, supone adems, que debemos establecer un mecanismo que permita que cuando se a realice un cambio en el servidor primario (el de la mquina peloto) este cambio se vea reejado a automticamente en todos los servidores secundarios. No tendr ningn sentido que existieran a a u varios servidores para la autenticacin pero que los datos no estuvieran exactamente replicados o desde el servidor primario hasta los secundarios. Afortunadamente, la aplicacin OpenLDAP provee de un mecanismo para que esto sea posible. o La utilidad slurpd establece un mecanismo para replicar todos los cambios que se efecten en un u servidor LDAP primario. Para ello, y en primer lugar, debemos instalar esta aplicacin en todos o los servidores LDAP de los que disponemos actualmente. Para ello, hacemos uso de la herramienta de instalacin de software en Debian: o Listado 4.36: Instalacin del demonio slurpd con apt-get o
$ apt - get install slurpd

Debemos instalar esta utilidad en las mquinas peloto, zipi y zape. Una vez realizado este a paso, debemos aplicar algunos cambios a la conguracin inicial que tenemos en este momento, o que contemple las siguientes acciones: Solamente se podrn realizar cambios en la mquina peloto, que es la que alberga el servidor a a LDAP primario. Cuando se intente realizar algn cambio en el directorio LDAP de las mquinas zipi, zape u a o nano, esta modicacin se redireccionar a la mquina peloto, que es la que atender esa o a a a peticin. o Un cambio en el directorio LDAP de la mquina peloto produce una reaccin en cadena a o de cambios sobre las mquinas zipi, zape y nano, de forma que su directorio LDAP quede a automticamente sincronizado con el de la mquina peloto. a a Esta conguracin se lleva a cabo siguiendo los siguientes pasos. o Cambios necesarios en el servidor LDAP primario En primer lugar, en la mquina peloto es necesario indicar donde est el chero de log de a a replicacin, para a continuacin indicar cada una de las rplicas en las que vamos a propagar los o o e cambios que se efectuen en nuestro directorio LDAP. Para ello, es necesario incluir las siguientes l neas: Listado 4.37: Aadiendo replicacin a nuestro servidor LDAP n o
1 2 3 4 5 6 7 8 9 10 11 12 13

replogfile

/ var / lib / ldap / replog

replica uri = ldaps :// zipi . escet . urjc . es binddn =" cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " bindmethod = simple credentials = replicator 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

A. Gutirrez Mayoral e

65

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Como vemos, por cada servidor LDAP secundario es necesario indicar una directiva replica con los parmetros de conexin necesarios. Como se puede apreciar, se especica la localizacin a o o 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 mquinas que albergan un servidor LDAP secundario (esto es, las mquinas a a zipi, zape y nano, debemos aplicar estos cambios. Estos cambios quedan descritos aplicando estas l neas en cada uno de los cheros de conguracin del servidor LDAP de la mquina (chero o a /etc/ldap/slapd.conf : Listado 4.38: Aadiendo replicacin a nuestro servidor LDAP n o
13 14 15 16 17

access to * by dn = cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es write by * read updatedn " cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es " updateref ldaps :// peloto . escet . urjc . es

Como vemos, se especica que el usuario propietario del nombre distinguido dn=cn=replicator,dc=zipi,dc=escet,dc=urjc,dc=es tendr acceso para escribir. El resto a de usuarios, solamente tendrn acceso de lectura. Adems, las dos ultimas l a a neas indican que solamente se pueden realizar actualizaciones de datos mediante el nombre distinguido anterior, y que cualquier otra modicacin por cualquier otro usuario debe devolver un error (indicando que o no se puede escribir en el directorio) remitiendo a la direccin del servidor LDAP primario que o s admite modicaciones 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 especicaban las cadenas de conexin a los diferentes servidores en diferente orden para poder as repartir la o carga entre todos los servidores disponibles. Bien, qu ocurrir si un cliente tiene como primer e a servidor disponible un servidor LDAP secundario, que no admite modicaciones y recibe una peticin para un cambio de contrasea? Podr pensarse que se remitir a un error, debido a o n a a que ese servidor LDAP no admite ninguna operacin de escritura en su directorio (a no ser que o provengan de un servidor LDAP primario). Pues bien, realmente cuando ocurre esta situacin, o el servidor LDAP secundario devueve la cadena de conexin al servidor LDAP primario, y es o ah entonces donde se realiza la modicacin. Evidentemente, si ste no estuviera disponible, o e s que se producir un error y la operacin de cambio de contrasea no podr llevarse a cabo. a o n a Llegados a este punto, hemos conseguido completar una compleja conguracin de servidores o de autenticacin bastante able, con reparto de carga (no saturaremos a un servidor con todas o las peticiones de todas las estaciones) y en las que el fallo de una mquina no supone la caida del a servicio de autenticacin. o Copias de seguridad Un aspecto muy importante de cara a la recuperacin del servicio en caso de error, es la o continua gestin de copias de seguridad de los datos del directorio. En en el diseo que nos o n 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 nalmente en otro servidor diferente. Para ello, podemos hacer uso de la utilidad slapcat, la cual ejecutada en cada uno de los servidores LDAP provocar que se vuelque en a formato texto el directorio LDAP por la salida estndar. Simplemente redirigindolo a un chero, a e tendr amos suciente. 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 2 3 4 5

#!/ bin / bash DATE = date + %F / 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 unicamente invoca al comando slapd para guardar su resultado en un chero comprimido, con la fecha (ao, mes y d de la copia de seguridad. n a) Este script, al que denominaremos backup ldap.py, se ejecutar en todas aquellas mquinas a a que dispongan de un servidor LDAP, de forma diaria. Para ello, podemos incluir la siguiente l nea de cron en las mquinas peloto, zipi, zape y nano: a Listado 4.40: L nea de cron para automatizar las copias de seguridad de LDAP
00 00 * * * / root / bin / backup - ldap . sh

A travs de la cual ejecutar todos los d a las 00:00h la utilidad de copia de seguridad e a as del directorio LDAP. Podemos combinar este script con otras tcnicas, como por ejemplo, cada e 15 d guardar los datos en un soporte magntico, como cinta, o CD, etctera. Sin duda se as e e 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 Gestin del directorio LDAP o Una vez puesto en marcha todo el sistema, es necesario disponer de herramientas adecuadas para poder administrar fcilmente el directorio LDAP. En nuestro caso, como solamente va a a ser usado para autenticacin de usuarios, hemos de disponer de las herramientas necesarias que o nos permitan aadir, eliminar y modicar usuarios existentes en la base de datos. Normalmente, n cuando se instala un servidor de directorio LDAP, resulta casi fundamental instalar junto a l las e herramientas ldap-utils, que proveen de utilidades para gestionar adecuadamente el directorio. En concreto, son herramientas que permiten aadir (ldapadd), modicar datos del directorio n (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 aplicacin propia para la o gestin de los usuarios del sistema, hemos instalado una aplicacin web para poder administrar o o el directorio fcilmente. No obstante, usaremos utilidades en l a nea de comandos si nuestro n es poder realizar un pequeo cambio (por ejemplo, cambiar una contrasea) en el sistema de forma n n rpida y simple. Vamos a ver cada una de ellas de forma breve. a PHPLdapAdmin La aplicacin PHPLdapAdmin17 es una aplicacin libre y gratuita que permite gestionar a o o travs de un interfaz web un conjunto de servidores LDAP. Adems de eso, obviamente, permite e a aadir, borrar y modicar datos del directorio LDAP. Esta herramienta es muy cmoda desde n o el punto de vista que permite ver de una pasada rpida cual es el estado de los servidores a LDAP en un momento determinado, adems de poder ver en forma de rbol la estructura del a a mismo. Adems, permite aadir usuarios con estructura posixAccount (muy util para cambiar a n contraseas) y permite localizar a un usuario rpidamente. En la imagen 4.8 se puede ver esta n a
17

http://phpldapadmin.sourceforge.net/

A. Gutirrez Mayoral e

67

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

Figura 4.8: La aplicacin PHPLdapAdmin sobre nuestro esquema de servidores. o aplicacin funcionando en nuestro entorno de servidores LDAP18 . Esta aplicacin la usaremos o o para localizar rpidamente un objeto en el LDAP y poder realizar una modicacin sobre l, no a o e obstante, est pensada para ser usada solamente sobre los usuarios administradores del entorno, a ya que desde el punto de vista de su gestin puede resultar un poco tcnica. En principio, se o e recomienda que los profesores, que muy a menudo se ven obligados a cambiar contraseas y crear n cuentas para sus alumnos, usen la herramienta propia de gestin de usuarios del Laboratorio19 o La instalacin de conguracin de PHPLdapAdmin es bastante simple, estando disponible o o como paquete en la mayor de las distribuciones ms usadas hoy en d Posteriormente, despus a a a. e de instalar la herramienta, se debe congurar con los parmetros de los servidores a los cuales se a desea poder acceder desde la administracin web. En este documento no se describir la instalacin o a o y posterior conguracin de la herramienta por existir multitud de documentos que se encargan o de ello20 . Aplicaciones en l nea de comandos Aparte de las herramientas grcas de gestin del directorio y de los servidores LDAP, siempre a o viene bien tener disponibles herramientas en l nea de comandos para la gestin del directorio de o forma eciente y simple. Estas herramientas, estn provistas por el paquete ldap-utils, como a se ha comentado antes. Normalmente, las herramientas ldapadd y ldapdelete se suelen usar a travs de herramientas de nivel superior, ya que tanto los parmetros que requieren como los e a formatos de cheros 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 contrasea de un usuario en l n nea de comandos rpidamente. La sintaxis de este comando es a bien sencilla, mostrndose un ejemplo a continuacin. Supongamos que queremos cambiar la a o contrasea a un usuario cuyo nombre de usuario es agutierr, sabiendo que su cuenta se encuentra n
Se puede acceder a la gestin del LDAP desde la URL https://minervo.escet.urjc.es/ldapadmin desde la Intranet o de la Universidad. 19 Esta aplicacin se encuentra en la URL https://pantuo.escet.urjc.es/admin o 20 En la pgina web del proyecto (http://phpldapadmin.wiki.sourceforge.net/Documentation) se puede encontrar a abundante informacin sobre la instalacin y personalizacin de la herramienta. o o o
18

Proyecto Fin de Carrera

68

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION situada en el subrbol de profesores del directorio LDAP. Sencillamente, escribir a amos lo siguiente: Listado 4.41: Modicando la contrasea de un usuario usando ldappasswd n
$ 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 cdigo, la sintaxis de los comandos de o 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 cheros 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 punta como es hoy en d a a LDAP, aumentar la seguridad de la autenticacin de los usuarios en el sistema, como ha quedado o demostrado, adems de dotar al entorno de una abilidad y rendimiento ptimos. A continuacin, a o o se nos presenta como reto dotar al sistema de un servicio de cheros en red capaz de soportar toda la carga del entorno, adems de disponga de espacio suciente para poder almacenar de a forma amplia un nmero aproximado de tres mil cuentas de usuario, con sus correspondientes u carpetas personales. La opcin unica clara que se presenta es el uso del sistema de cheros NFS21 , un sistema o de cheros en entornos Unix que permite acceder a cheros y diretorios remotos como si fueran cheros locales. En Unix/Linux esto es posible gracias a una mezcla de funcionalidad en el mismo kernel de Linux en la mquina cliente y un demonio en el servidor, mezclado todo con llamadas a 22 entre el cliente y el servidor (NIS tambin funciona con RPC). RPC e El servidor de NFS, exporta un conjunto de directorios (uno o ms) de forma remota a todos a aquellos clientes que deseen montar ese directorio. Por otro lado, los clientes montan ese directorio v NFS en su sistema de cheros local. La sintaxis para montar un directorio v NFS no es muy a a diferente a la que que se usa para montar directorios locales, ms que aadiendo la mquina que a n a alberga el servidor NFS y el directorio que se desea montar. Como vimos en el cap tulo de diseo, n la mquina que albergar el servidor NFS para el Campus de Mstoles, ser la mquina lechuzo a a o a a (con direccin IP 212.128.4.8), y exportar el directorio /disks/raid/homes.mostoles de cara o a a los clientes, las estaciones del Laboratorio. As para poder montar remotamente los directorios , personales de los alumnos en una estacin cliente, tendr o 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 montado el directorio a remoto /disks/raid/homes.mostoles/ del servidor. El uso de este directorio, ser totalmente a transparente para los usuarios de las estaciones, que lo usar como si de un directorio local se an tratara. Evidentemente, la tarea de montar el servidor de homes est automatizada en el arranque a de las estaciones del laboratorio. Esto se consigue aadiendo una l n nea al chero /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 ms de informacin que la anterior. Las opciones ms interesantes a o a son las opciones rw, y la opcin udp, que monta el directorio del servidor usando el protocolo de o
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. Gutirrez Mayoral e

69

ETSI Informtica a

 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 prdidas y los tiempos de respuesta son en su mayor e 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: Instalacin del servidor NFS a travs de apt-get o e
$ apt - get install nfs - kernel - server

Conguracin del servidor o La conguracin del servidor de NFS unicamente contempla el seleccionar el directorio que se o desea exportar de cara a los clientes. Esta conguracin se lleva a cabo en el chero /etc/exports. o 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 ningn mecanismo de u autenticacin que no sea permitir o denegar el montaje del recurso ateniendo a la direccin IP o o del cliente. Vemos un fragmento del chero de conguracin a continuacin: o o
/ 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 conamos. En principio, cualquier persona que usara una direccin IP del laboratorio (con su ordenador porttil, por ejemplo) ser capaz de montar o a a el recurso NFS sin mayor dicultad. Las operaciones que pueda realizar en ese momento con ese directorio dependen unicamente 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 mquina local se traducirn como operaciones con el usuario root en la a a mquina servidor. a Por el contrario, si se ha exportado el directorio con la opcin root squash, las operaciones o a nombre del usuario root en la mquina local se traducirn como operaciones a a a nombre del usuario nobody en la mquina remota, y por tanto, este usuario solamente a tendr privilegios sobre aquellos cheros que tenga a su nombre. a An as estando el recurso exportado con la opcin root squash, un usuario root local no u , o tendr privilegios sobre nada que no est a su nombre, pero nada impide que intercambiando a e su id de usuario acceda a todos los cheros para los que no tenga privilegios. Vemos por tanto, que las opciones son bastante poco esperanzadoras, en cuanto a seguridad se reere. Adems de a no poder autenticar a los clientes, excepto conar en ellos a travs de su direccin IP, es posible e o acceder en modo lectura y escritura con privilegios desde cualquier cliente y modicar los cheros de cualquier usuario al antojo del atacante, sin ms que escribir unos cuantos comandos de shell. a Como se puede deducir, NFS hoy en d adolece de graves problemas de seguridad que de a momento, y debido a la estructura del kernel de Linux, no est a la vista ser corregidos, pero hoy a en d representa la unica opcin medianamente usable en cuanto a rendimiento y abilidad. a o RAID de disco En un sistema en el que se tienen aproximadamente tres mil cuentas de usuario, resulta imprescindible disponer de una tecnolog que permita aunar gran cantidad de espacio en disco a 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 diseo, vamos a hacer n uso de la mquinas lechuzo y sapientin en el Campus de Mstoles para albergar por un lado a o 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 algn disco de la primera, se u pueda sustituir sta rpidamente (sin ms que cambiar su direccin IP) y no dejar sin servicio a e a a o los laboratorios. Discos disponibles En principio, la conguracin de hardware de las mquinas lechuzo y sapientin no tienen o a porqu ser similares, siendo recomendable unicamente que la segunda tenga al menos el mismo e tamao de espacio en disco que la primera. Incluso, la conguracin del RAID puede variar, no n o teniendo porqu estar conguradas en el mismo nivel. e En la mquina lechuzo, disponemos de cinco discos duros disponibles, de diferentes tamaos, a n 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 Tamao n 400 GB 163 GB 163 GB 163 GB Particin principal o /dev/hdb1 /dev/hde1 /dev/hdi1 /dev/hdm1

Cuadro 4.1: Discos duros de la mquina lechuzo a

Anlogamente, en la mquina sapientin, destinada a albergar las copias de seguridad de los a a directorios personales de los usuarios, disponemos de seis discos duros (sin contar el dedicado a la particin del sistema) de 120 GB de tamao cada uno. El tamao total es aproximadamente o n n de 500 GB, para copias de seguridad. Conguracin del raid en Linux o Dispuestos los discos duros que van a ser dedicados en cada mquina a albergar los directorios a personales de los usuarios (mquina principal y copias de seguridad) debemos congurar un raid a por software bajo Linux, para poder acceder a todos los discos como si de unico dispositivo se tratara. Las herramientas adecuadas que disponen de esta funcionalidad bajo Linux vienen provistas por el paquete mdadm, cuya instalacin se puede completar usando el gestor de o paquetes de Debian (recordamos que en el cap tulo de Diseo establecimos que la distribucin a n o usar en los servidores, iba a ser Debian GNU/Linux): Listado 4.43: Instalacin del gestor de raid mdadm usando apt-get o
$ apt - get install mdadm

La herramienta mdadm es una utilidad para Linux que permite administrar (aadir, borrar n y modicar) raids de disco que funcionen por software (en ausencia de una controladora hardware dedicada). El nombre de la aplicacin mdadm viene de multiple disks. La herramienta mdadm o se distribuye bajo la licencia GNU/GPL. Lo primero que debemos hacer para congurar el RAID de disco, es formatear los discos usando el sistema de cheros ext3. Si previamente, los discos no ten ninguna particin creada, an o debemos crearla haciendo uso de las herramientas fdisk o cfdisk. Una vez que hemos creado las particiones correspondientes, podemos formatearlas usando el sistema de cheros ext3 invocando el programa mkfs.ext3: A. Gutirrez Mayoral e 71 ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Listado 4.44: Automatizacin en la creacin del raid o o
$ 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 automtica. a Lo mismo podemos hacer en la mquina sapientin: a Listado 4.45: Automatizacin en la creacin del RAID o o
$ for i in echo e g i k m ; do mkfs . ext3 / dev / hd$i1 ; done

Concluida esta operacin, podemos crear el RAID de disco deseado. o Niveles de RAID usados Un dispositivo RAID puede ser congurado en diferentes niveles, dependiendo de la conguracin ms ptima para el entorno. Para ilustrar diferentes conguraciones de RAID, o a o vamos a usar el nivel cero (tambin llamada conguracin en tiras) en la mquina lechuzo y la e o a conguracin de nivel cinco (disco en redundancia o disco spare) en la mquina sapientin. Desde o a el punto de vista del espacio en disco, la conguracin ms ptima es la conguracin en tiras, o a o o que aprovecha al mximo el uso de cada disco: el tamao total del RAID es la resultante de a n multiplicar el espacio disponible en cada uno de los discos por el nmero de discos. Sin embargo, u si se produce un error en uno de los discos, el RAID quedar totalmente inutilizable, y ser preciso a a hacer uso de la copia de seguridad. La conguracin en nivel cinco, o con redundancia, hace uso de un disco para almacenar o redundancias entre la informacin, de forma que si se produce un error en alguno de los discos, o nos podremos recuperar de la informacin en caliente, sin ms que cambiar el disco defectuoso. o a Como en principio, disponemos de dos mquinas, vamos a hacer uso de ambas conguraciones a para poder disponer de cada las dos ventajas por el mismo precio. Para la creacin del RAID hacemos uso de la herramienta mdadm de la siguiente forma: o
$ mdadm -- create / dev / md0 -- level - raid 0 -- raid - devices 4 / dev / hd [ beim ]1

En la mquina lechuzo. El dispositivo nal /dev/md0 en esta mquina albergar el raid de a a a disco que podr ser considerado como si de un solo disco se tratara. En el comando expuesto, se a indica que se desea aplicar un nivel de raid cero, con cuatro discos, indicando por supuesto que discos se desea aadir al raid. De la misma forma, en la mquina sapientin, n a
$ 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 conguracin de RAID con redundancia, y por tanto es o necesario indicar mediante el parmetro spare-devices que disco se desea usar para almacenar a esta redundancia. Despus de aplicar estas operaciones, debemos tener en ambas mquinas y e a bajo el directorio /dev/md0 los respectivos dispositivos raid. Usando la propia herramienta de diagnstico del paquete podemos comprobar el estado de cada uno de los raids: o
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 tamao total del dispositivo raid, adems de las fechas de creacin, actualizacin n a o o y de los dispositivos f sicos de los que se compone el raid. De la misma forma en la mquina a sapientin, podemos observar la misma informacin: o
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 unico se tratara, por lo que (aunque no es obligatorio) se recomienda formatear esta nueva particin en el formato de cheros elegido, o en nuestro caso, el sistema de cheros ext3:
$ mkfs . ext3 / dev / md0

Ejecutado en ambas mquinas, formatear los dispositivos para que puedan ser montados a a a partir de ese momento en el sistema. Unicamente nos queda montar los directorios bajo el punto A. Gutirrez Mayoral e 73 ETSI Informtica a

 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 ultimo, reiniciar el demonio NFS en ambas mquinas para que los recursos estn a e disponibles a todas las estaciones del Laboratorio:
$ / etc / init . d / nfs - kernel - server restart

Conguracin del RAID en los servidores del Campus de Fuenlabrada o La conguracin del RAID para los servidores del Campus de Fuenlabrada (bilo y nano) es o muy similar a la creacin del RAID para los servidores de disco del Campus de Mstoles. En o o concreto, usaremos nivel de raid cero (conguracin en tiras) en ambas mquinas. Como vimos o a en el cap tulo de diseo, la mquina bilo albergar el RAID que contendr los cheros personales n a a a de los usuarios de ese campus (como servidor principal) y la mqina nano albergar las copias de a a seguridad de dichos cheros.

4.2.3.

Servidor Web de los Laboratorios

Como vimos en el cap tulo de Diseo, en los Laboratorios (tanto de los Campus de Mstoles n o como de Fuenlabrada) instalaremos un servidor web en una de las mquinas, que cubrir dos a a funcionalidades principalmente: Instalar una pgina principal que sirva para informar a los alumnos de las instalaciones, los a procedimientos principales (apertura de cuenta, cambio de contrasea, etctera), una serie n e de tutoriales (conectar al laboratorio desde casa, congurar el correo electrnico, etctera). o e Que los propios alumnos puedan congurar una pequea pgina personal, con la informacin n a o acadmica que deseen (normalmente los alumnos usan este medio para proporcionar e informacin sobre su persona y sus intereses profesionales). o 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 Mstoles, cuando los Laboratorios o comenzaron a funcionar, siempre se us la mquina pantuo para esta tarea. Como vimos o a en el cap tulo de Especicacin y Diseo, la mquina pantuo implementa la tarea de ser la o n a cabeza visible de los Laboratorios. Proporciona, adems de servidor web, servidor de correo a electrnico para los usuarios, listas de correo, etctera. Por tanto, usaremos la direccin o e o pantuo.escet.urjc.es para instalar la pgina web del Laboratorio. Para las pginas personales a a de los usuarios, usaremos la notacin tradicional de pginas web en un entorno Unix/Linux, es o a decir, el nombre del host, seguido del carcter y el nombre del usuario. As si mi nombre a , de usuario es agutierr, la URL que har referencia a mi espacio web en el servidor ser a a http://pantuo.escet.urjc.es/gutierr/. De la misma forma, en el Campus de Fuenlabrada a tambin dispondremos de un servidor web que servir de pgina principal del Laboratorio. e a a La mquina encargada de albergar este servidor (y por tanto la pgina del Laboratorio a a en Fuenlabrada) ser la mquina bilo, siendo la URL principal del Laboratorio la direccin a a o http://bilo.cct.urjc.es/. A continuacin vamos a ver cmo congurar rpidamente un gestor de contenidos para el o o a Laboratorio, que permita editar, aadir y borrar contenido de forma fcil e intuitiva (incluso, que n a permita a los docentes hacerlo) y cmo congurar el servidor web para que permita a los usuarios o gestionar sus pginas personales. a Proyecto Fin de Carrera 74 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Pgina principal del Laboratorio a Desde el punto de vista informativo y corporativo, siempre resulta interesante como organizacin disponer de una pgina web de informacin, de cara al resto del mundo, que los o a o alumnos o los visitantes puedan utilizar para saber cual es el rgimen de funcionamiento interno e del Laboratorio, as como otra informacin muy interesante de cara a los usuarios nales del o entorno. Es por ello que una de nuestras tareas ser instalar un servidor web que nos permita a congurar un gestor de contenidos para el Laboratorio. Un servidor web es un programa que implementa el protocolo HTTP23 . Este protocolo est diseado para transferir lo que llamamos pginas web o pginas en formato HTML24 . Sin a n a a embargo, es importante resear que HTTP hace referencia al protocolo que permite el visionado n 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, etctera). El navegador, realiza una peticin al servidor y ste le responde con el e o e contenido que ste solicita. Existen multitud de programas que implementan un servidor web, e siendo uno de los ms conocidos en entornos Unix/Linux el servidor web Apache. a Versiones de Apache Hoy en d existen dos versiones principales de Apache: la versin 1.3 y la versin 2. En a, o o el entorno en el que nos encontramos, instalaremos ambas. Ambas siguen en desarrollo, y las principales ventajas de la versin 2 sobre la versin 1 radica en una mejora en las implementaciones o o que mejoran sustancialmente el rendimiento (en plataformas no Unix sobre todo), centrndose a en la modularizacin del servidor. En nuestro entorno, usaremos las dos, principalmente por dos o razones: Existen mdulos que slo estn disponibles para la versin 1 (como es el caso del mdulo o o a o o de PHP5) Existen mdulos que slo estn disponibles para la versin 2 (como es el caso del mdulo o o a o o de Webdav y Subversion) Instalacin o La instalacin en Debian GNU/Linux de Apache (tanto en la versin 1 como en la versin 2) es o o o realmente sencilla e intuitiva. En primer lugar instalaremos Apache 1 con los mdulos necesarios, o en este caso, el mdulo de PHP5. o Listado 4.46: Instalacin de Apache y del mdulo PHP5 para el servidor o o
$ apt - get install apache libapache - mod - php5

Despus de responder a unas preguntas relativas a la conguracin del paquete, lo e o ms probable es que el software se haya instalado correctamente, y ya podamos acudir a a la direccin principal para poder ver una pgina de prueba. Por tanto, en la direccin o a o http://pantuo.escet.urjc.es/ (y respectivamente, a la del Campus de Fuenlabrada) podemos ver la pgina de prueba que nos deja Apache nada ms ser instalado. a a A continuacin, vamos a instalar el servidor web Apache en su versin 2, junto con el mdulo o o o de Webdav/Subversion. Este mdulo nos permitir acceder a repositorios Subversion dentro del o a servidor pantuo, en ocasiones usado por alumnos para versionar el cdigo fuente de sus prcticas. o a
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. Gutirrez Mayoral e

75

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Listado 4.47: Instalacin del servidor Apache2 y del mdulo WebDav/Subversion para el o o servidor
$ apt - get install apache2 libapache2 - svn

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

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

De esta forma, el servidor web Apache 2 arrancar normalmente en el arranque o bajo peticin a o del demonio correspondiente. Conguracin de los Hosts virtuales o 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 pantuo.escet.urjc.es. Este nombre es pantuo.es, que nos sirve para no tener que escribir el nombre completo (a los alumnos les es ms fcil recordar este nombre) y para disponer de un mapa a a propio de nombres que puede ser administrado por el Departamento y por los administradores del Laboratorio. Veremos ms adelante en la seccin de Conguracin del servicio de resolucin a o o o de nombres como congurar una zona concreta con un software de resolucin de nombres. En o este punto, lo unico que nos debe preocupar es que nuestro servidor web sea capaz de atender las peticiones dirigidas tanto a la direccin pantuo.escet.urjc.es como a la direccin pantuo.es o o (y que por supuesto, devuelva el mismo contenido). La conguracin de los hosts virtuales se lleva a cabo en el chero de conguracin de Apache, o o el chero /etc/apache/httpd.conf. En la ultima seccin del chero, podemos encontrar el rea o a de declaracin de hosts virtuales. Como en nuestro caso solamente tenemos dos hosts, vamos a o declarar uno (el host pantuo.escet.urjc.es) y el otro lo vamos a congurar como alias. Esto nos permitir no tener que repetir la misma informacin para el host pantuo.es. La conguracin, a o o por tanto, quedar como sigue: a Listado 4.48: Creacin de un host virtual en Apache para el host pantuo.escet.urjc.es o
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

Alias / pipermail / var / lib / mailman / archives / public Options + Indexes </ VirtualHost >

12 14

Se puede observar en el fragmento del chero de conguracin anterior como se dene el host o pantuo.escet.urjc.es, una direccin de correo para el administrador del mismo, y la etiqueta o DocumentRoot que indica a partir de qu localizacin en el disco f e o sico se han de servir las pginas web referenciadas por las peticiones entrantes al servidor. Tambin podemos ver como a e con ayuda de la directiva ServerAlias, denimos que el host pantuo.es es exactamente lo mismo que el host pantuo.escet.urjc.es. En la siguiente seccin veremos cmo retocar esta o o seccin del chero de conguracin de Apache para que sea capaz de servir las pginas personales o o a de los usuarios bajo los hosts virtuales pantuo.escet.urjc.es y pantuo.es. Gestor de contenidos MediaWiki Una vez hemos instalado un servidor web en cada una de las mquinas visibles de los a Laboratorios (las mquinas pantuo y bilo vamos a proceder a la instalacin de un gestor de a o contenidos que nos permita aadir contenido a las pginas de cada uno de los laboratorios, de n a forma que sea fcil, rpido y que los alumnos y docentes puedan modicar los contenidos. La a a conjuncin de cada una de estas palabras responde a un unico trmino: un wiki. Un wiki (o o e una wiki ) (del hawaiano wiki wiki, ((rpido))) es un sitio web colaborativo que puede ser editado a por varios usuarios. Los usuarios de una wiki pueden as crear, modicar, borrar el contenido de una pgina web, de forma interactiva, fcil y rpida; dichas facilidades hacen de la wiki una a a a herramienta efectiva para la escritura colaborativa. Existen multitud de programas que implementan esta funcionalidad. El escogido para ser usado en nuestro entorno ser la aplicacin MediaWiki25 . Actualmente, uno de los wikis ms a o a 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 adems, permite diferentes mecanismos de a autenticacin de usuarios, entre ellos, autenticacin frente a un directorio LDAP. Es por esta o o razn que nos decantamos en favor de esta aplicacin, puesto que la integracin con el sistema de o o o autenticacin es cien por cien: cualquier usuario con cuenta en los laboratorios (ya sea docente o o alumno) podr aadir o editar contenidos a la pgina del Laboratorio. Por supuesto, existirn a n a a pginas para las que no se dispongan permisos de edicin (o solamente un docente pueda hacerlo). a o En general, no nos preocupa mucho que un alumno pueda borrar el contenido de una pgina: a aparte de que su nombre quedar registrado, la propia estructura de un wiki hace que la a recuperacin sea inmediata. o Instalacin de MediaWiki o La instalacin del software MediaWiki desde las fuentes es realmente sencilla. Para empezar, o debemos descargar la ultima versin26 del software, disponible en la pgina web del Proyecto. Una o a vez descargada y descomprimida, pasamos a leer el chero INSTALL, en el que normalmente se incluyen las instrucciones de instalacin. o Listado 4.49: Descarga e Instalacin de la herramienta MediaWiki o
$ $ $ $ $ $ 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 ultima versin estable es la 1.1 . o

A. Gutirrez Mayoral e

77

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION Una vez descomprimido el software, debemos acudir a la direccin /cong para terminar la o conguracin del mismo. En esta direccin se muestra un formulario para completar los ajustes o o relativos a la base de datos donde se alojarn las pginas de la citada aplicacin, usuarios y a a o dems. Es necesario en este punto disponer de un servidor de bases de datos funcionando (no a tiene porqu ser en la misma mquina donde se instala la aplicacin). Suponemos que de ser as e a o , simplemente introducir amos los parmetros de conexin oportunos (nombre de host donde se a o encuentra el servidor de base de datos, usuario y contrasea para la conexin, nombre de la base n o de datos que albergar el wiki, etctera). Si todo ha ido bien, el script terminar de ejecutar sus a e a acciones instalando en el servidor de base de datos las tablas necesarias para que la aplicacin o pueda funcionar correctamente. Una vez que hemos completado esta accin, nuestro wiki queda correctamente instalado, y o preparado para ser personalizado. Tras unas tareas de edicin en el wiki, tenemos una pgina o a totalmente funcional donde poder informar a los usuarios del Laboratorio de diferentes aspectos, tal y como muestra la imagen 4.9:

Figura 4.9: Pgina principal del Laboratorio de Mstoles a o

En la seccin Noticias, se mostrarn las noticias relacionadas con el servidor (informacin de o a o incidencias, cambios de horario, avisos para los usuarios, etctera). Estos avisos normalmente e tambin se mandarn por correo electrnico mediante la lista de usuarios del Laboratorio, e a o cuya conguracin veremos ms tarde. o a En la seccin Instalaciones se muestran las instalaciones (descripcin del hardware y fotos) o o de las que disponemos en los Laboratorios. Tambin puede resultar de utilidad a futuros e alumnos o a visitantes ajenos a la Universidad. En la seccin Tutoriales se muestran diversas gu de conguracin de los servicios ms o as o a usados en los Laboratorios: cmo congurar el correo de la cuenta, acceder a l mediante el o e webmail, conectarse a las terminales desde casa, abrir una sesin grca desde casa, etctera. o a e Esta seccin sin duda resulta de mucha ayuda a los alumnos que acuden a los Laboratorios o a realizar sus prcticas, y sin duda es una de las ms visitadas. a a Proyecto Fin de Carrera 78 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION En la seccin FAQs se encuentra una seleccin de las preguntas ms frecuentes, relacionadas o o a sobre todo con el Sistema Operativo Linux. Etctera. e Autenticacin en MediaWiki en un directorio LDAP o Como se coment anteriormente, una de las principales ventajas de la aplicacin MediaWiki o o es la integracin de autenticacin a travs de un directorio de usuarios LDAP. Esto nos va a o o e permitir que los usuarios (tanto alumnos como profesores) se puedan autenticar de cara al wiki y puedan editar los contenidos (aadir, modicar o borrar). n Para poder llevar a cabo esta integracin, debemos descargar una extensin de la aplicacin. o o o Una extensin es un aditivo que permite aadir funcionalidad a la aplicacin base. En este caso, o n o esta extensin nos va a permitir autenticar usuarios contra el directorio LDAP del Laboratorio. o n La extensin LDAP Authentication27 aade esta funcionalidad. El mecanismo de o instalacin y conguracin es realmente simple: en primer lugar, debemos descargar la extensin o o o en el directorio de extensiones de la aplicacin: o
$ 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 extensin, lo unico que tendremos que hacer es congurarla. o Para ello, editamos el chero principal de conguracin de la aplicacin, el chero o o /var/www/mediawiki/LocalSettings.php. Tal y como detalla la documentacin de la o extensin, escribimos la conguracin de autenticacin LDAP para el entorno en el que nos o o o encontramos: Listado 4.50: Conguracin de MediaWiki para autenticar usuarios usando LDAP o
2 4 6 8 10 12

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 " ); $wgLDAPUseLocal = true ;

14 16 18 20 22 24 26 28

$ 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 " ); $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. Gutirrez Mayoral e

79

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

$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 " ); $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 );

30 32 34 36 38 40 42

Figura 4.10: Autenticacin en la pgina del Laboratorio mediante el directorio LDAP. o a Vemos cmo, se denen dos grupos diferentes de usuarios: alumnos y profes (en principio, o cada uno dispondr de un conjunto diferente de privilegios). A continuacin, denimos el servidor a o de autenticacin (con uno de ellos hubiera bastado, especicamos el servidor primario) y de o forma especial, destacamos que el mecanimos de conexin al servidor LDAP debe ser SSL. Si no o especicamos esto, la aplicacin MediaWiki intentar conectar al puerto estndar de LDAP en o a a el servidor especicado (389) y la conexin fallar. En la imagen 4.10 podemos ver el resultado o a de esta conguracin. El sitio MediaWiki del Laboratorio permite la autenticacin contra el o o directorio LDAP de usuarios. Web personales de usuarios Un aspecto interesante de la conguracin de Apache es la que permite a los usuarios o colocar una pequea pgina personal de usuario en el servidor. Muchos de los usuarios n a del sistema, utilizan esta posiblidad para colgar informacin sobre su curr o culum, prcticas a realizadas, etctera. Para poder llevar a cabo esta conguracin, debemos editar la entrada e o del virtual host para que busque las pginas personales de los usuarios en el directorio a public html del usuario que se especica en la URL. Por ejemplo, la URL del usuario agutierr ser http://pantuo.escet.urjc.es/ agutierr (para el campus de Mstoles) o a o http://bilo.cct.urjc.es/ agutierr (para el campus de Fuenlabrada). Los cheros que se servirn a Proyecto Fin de Carrera 80 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION en esa URL se localizarn dentro del directorio public html, en el directorio HOME del usuario. a Es necesario que tanto este directorio como el superior, tenga permisos de lectura y ejecucin. o La conguracin que materializa esta funcionalidad se muestra a continuacin: o o Listado 4.51: Conguracin de Apache para dar soporte a pginas personales de usuarios o a
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 > < Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK > Order deny , allow Deny from all </ Limit > </ Directory > </ IfModule >

Aplicando esta conguracin en los servidores web de cada una de las mquinas que lo alojan o a (pantuo y bilo) los usuarios podrn colgar su propia pgina personal alojada en su directorio a a HOME.

4.2.4.

Servidor de correo electrnico o

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

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

A. Gutirrez Mayoral e

81

ETSI Informtica a

 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION 3. Alternativamente, vamos a ofrecer a los usuarios la posibilidad de consultar su correo a travs de un webmail. De esta forma siempre podrn consultar sus correos en cualquier e a momento, unicamente teniendo acceso a un navegador web. Comentaremos a continuacin como conseguimos realizar cada uno de los hitos planteados en o esta seccin. o Entrega de correo electrnico (SMTP) o Para dotar al sistema de un servidor que recoja el correo electrnico dirigido a la mquina o a pantuo.escet.urjc.es instalaremos la aplicacin Postx. Postx es un servidor de entrega de o correo muy potente y muy sencillo de congurar al mismo tiempo. Como nuestro sistema en principio no tiene grandes pretensiones ms que la de simplemente recoger el correo y entregrselo a a a los usuarios, nos decantaremos por esta opcin. o La instalacin de Postx es muy sencilla en mquinas basadas en el sistema de paquetes de o a Debian. En concreto, para la instalacin del mismo, ejecutaremos o Listado 4.52: Instalacin de la herramienta postx usando apt-get o
$ apt - get install postfix

El paquete solicitar conguracin adicional. No obstante, la conguracin es muy sencilla. a o o Conguraremos el gestor como: Sitio de Internet, capaz de recoger correo dirigido al dominio que nos ocupa (pantuo.escet.urjc.es para el campus de Mstoles y bilo.cct.urjc.es para el campus o de Fuenlabrada). El dominio para el cual debe aceptar correo suele ser localhost para el correo local de la propia mquina, localhost.localdomain como extensin al anterior, y por ultimo, el a o dominio visible desde Internet, que en nuestro caso ser pantuo.escet.urjc.es para el a campus de Mstoles y bilo.cct.urjc.es para el campus de Fuenlabrada. o Por ultimo, y esto es muy importante, las IPs desde las cuales el servidor debe poder hacer relay. Hacer relay en un servidor de correo signica desde que IPs o redes de IPs se debe reenviar correo a dominios externos al propio sin pedir una conrmacin o una o autenticacin adicional. En general, se conf siempre en la propia mquina (las subredes o a a con IP 127.0.0.0/24) y las de la propia red local (en nuestro caso ser 212.128.4.0/24 para el a campus de Mstoles y 193.147.73.0/24 para el campus de Fuenlabrada). Si no conguramos o este parmetro con especial cautela, numerosos spammers de Internet pueden usar nuestro a servidor de correo para enviar correo fraudulento, publicidad y derivados. Una vez hemos aplicado la conguracin en concreto para cada una de las mquinas o a que se encargarn de la entrega del correo, podemos comprobar que nuestro servidor a funciona adecuadamente (podemos enviarnos un correo de prueba y comprobar que nos llega correctamente). Si quisiramos modicar algn aspecto de la conguracin, Postx almacena sus e u o opciones de conguracin en los cheros /etc/postx/main.cf y /etc/postx/master.cf. Los o cheros de conguracin de esta herramienta son bastante sencillos y asequibles de modicar. o Recogida de correo electrnico (POP3 e IMAP) o 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 sucientemente motivados como para Proyecto Fin de Carrera 82 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION usar el correo electrnico del servidor pantuo. De no proporcionar un servicio de recogida de o correo, los usuarios se ver obligados a leer el correo electrnico en la propia mquina que lo an o a recibe, a travs del comando mail, o alguno ms avanzado, como Pine o Mutt. e a La disposicin de permitir al usuario recoger el correo electrnico mediante los citados o o protocolos permite al usuario utilizar aplicaciones de correo como Outlook, Evolution, o Thunderbird, y gestionar el correo de forma eciente. Mediante estas aplicaciones sern capaces a de poder leer el correo electrnico que les llegue a su cuenta de correo de pantuo o de bilo sin o 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 aplicacin elegida o para realizar esta tarea ser la aplicacin Dovecot, por las ventajas enumeradas en este cap a o tulo. Esta aplicacin nos permitir que tanto la mquina pantuo como la mquina bilo atiendan el o a a a servicio POP3 e IMAP, a travs de sus correspondientes versiones cifradas (POP3s e IMAPs). e Es necesario recordar que ambos protocolos se transmiten por la red en texto claro, incluyendo nombres de usuario y contraseas, por lo que ser obligado el proporcionar el citado servicio n a utilizando algn mtodo de encriptacin para datos sensibles, como son el correo electrnico y la u e o o informacin de autenticacin. o o Dovecot La aplicacin Dovecot es un servidor de recogida de correo que funciona tanto con cheros o mbox (en los que los correos electrnicos se almacenan en un unico chero) como con el formato o ms actual de almacenamiento de correo electrnico, el formato Maildir. Segn se detalla en a o u la pgina ocial de Dovecot30 , esta aplicacin fue pensada y escrita pensando principalmente a o 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. Adems, soporta multitud de a mecanismos de autenticacin, como por ejemplo la autenticacin mediante los mdulos de PAM o o o (que ser la que usemos en nuestro caso) as como basados en bases de datos. Por ultimo, aunque a no es nuestro caso, Dovecot funciona perfectamente en cl sters de ordenadores en red que usen u 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 aplicacin. o Instalacin de Dovecot o La instalacin de Dovecot resulta bien sencilla, puesto que se encuentra incluido como o paquete Debian en la distribucin estable, y por tanto, una simple llamada al comando apto get bastar para su instalacin: a o Listado 4.53: Instalacin de los demonios necesarios para dar soporte POP3 e IMAP a pantuo o
$ apt - get install dovecot - common dovecot - pop3d dovecot - i mapd

Como vemos, es necesario indicar que se desea instalar el paquete con la funcionalidad bsica a de Dovecot (paquete dovecot-common) adems de los paquetes que proveern funcionalidad a a de los protocolos POP3 e IMAP: los paquetes dovecot-pop3d y dovecot-imapd. Una vez instalados ambos paquetes, ser necesario realizar unos ajustes que nos permitan congurar el a sistema para que los usuarios puedan recoger el correo electrnico mediante cualquiera de los dos o protocolos. Para ello, deberemos editar el chero de conguracin /etc/dovecot/dovecot.conf. o 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 versin segura (apoyados o en las bibliotecas SSL). Lo indicamos de la siguiente forma:
30

http://www.dovecot.org/

A. Gutirrez Mayoral e

83

ETSI Informtica a

 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 obtendrn un error cuando intenten descargar o consultar su correo con la a aplicacin gestora correspondiente. En nuestro caso, los directorios de correo se encuentran o en el directorio /var/mail/ seguido del nombre de usuario en cuestin. Hay que recordar o que debido a que se proporciona funcionalidad IMAP, es necesario que el correo electrnico o se almacene en el formato Maildir, estndar casi de facto en la mayor de servidores de a a correo. Para indicar este parmetro en la conguracin de Dovecot, debemos escribir en el a o chero de conguracin la siguiente l o nea:
default_mail_env = maildir :/ var / mail / %u /

3. Por ultimo, y dado que la autenticacin de los usuarios en el servidor de recogida de correo o ser la estndar del sistema, podemos usar PAM para esta tarea. En ese sentido PAM es a a muy exible, ya que para aadir un nuevo servicio solamente debemos incluir en el directorio n /etc/pam.d/ un chero de nombre dovecot indicando como se realizar la autenticacin a o (exactamente igual al resto de servicios del sistema). Su contenido podr ser el siguiente: a
# %PAM -1.0 @include common - auth @include common - account @include common - session

Una vez realizados estos ajustes en el chero de conguracin de Dovecot, podemos reiniciar o el servicio y comprobar que se encuentra escuchando peticiones de los protocolos indicados correctamente: Listado 4.54: Reiniciando el demonio dovecot tras su reconguracin o
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 cheros de log del servidor de correo podemos ver cmo los usuarios se o 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 mtodo para la consulta del e correo electrnico de sus cuentas @pantuo y @bilo (para el Campus de Mstoles y de o o Fuenlabrada,respectivamente) decidimos instalar un webmail. Un webmail es una aplicacin web o que permite consultar a travs de un navegador web el correo electrnico de una cuenta de un e o usuario en un sistema, normalmente una cuenta Unix o Linux. Dado que la instalacin de este tipo o 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) podrn consultarlo a travs del web. a e Una de las aplicaciones que implementa el servicio webmail ms conocidas hoy en d es la a a Suite Horde, que adems de proporcionar acceso al buzn de correo de un usuario en un sistema a o Unix/Linux, proporciona servicios de agenda, calendario, etctera. De hecho, esta aplicacin es en e o la que se basa el servicio webmail de la Universidad31 . Esto ser una ventaja para nosotros, puesto a que a los usuarios les resultar familiar el interfaz y apenas existir complejidad de adaptacin a a a o una nueva herramienta. Horde El Proyecto Horde se compone de unas bibliotecas (llamado Horde Framework ) que proporcionan funcionalidades bsicas (autenticacin, gestin de preferencias, interfaz grca, a o o a etctera) y que funciona como nexo de unin entre distintas aplicaciones de usuario, que e o son gestionadas como subproyectos independientes, dentro de la aplicacin Horde. Entre estas o aplicaciones encontramos IMP, un sistema webmail que permite el acceso a buzones de correo mediante POP3 o IMAP. A travs de este acceso podremos acceder a los buzones de las cuentas e de los usuarios, tanto en los servidores pantuo como bilo. La instalacin de esta aplicacin es extremadamente sencilla y por esta razn no ser detallada o o o a en exceso en el presente documento. Para llevar a cabo la instalacin, es necesario descargar las o ultimas versiones estables de la aplicacin principal de esta suite, llamada Horde: esta aplicacin o o es la unica no opcional bajo la que se sustentan el resto de mdulos del sistema. Si unicamente o deseamos instalar la aplicacin IMP (webmail), deberemos descargar desde la pgina del proyecto o a el mdulo imp, instalndolo a continuacin de horde. o a o Los unicos aspectos relevantes de la instalacin son: o 1. Como se realiza el acceso al servidor POP3/IMAP donde se encuentran los buzones de los usuarios. En nuestro caso, es la conguracin de correo electrnico que se llev a cabo en o o o el apartado anterior. 2. Como se lleva a cabo la autenticacin de usuarios para poder ingresar en el webmail. o Dado que estas aplicaciones se instalarn en las mquinas pantuo y bilo (es lgico a a o que el webmail se encuentre en la misma mquina que recibe el correo) podemos usar la a autenticacin local de la citada mquina: si un usuario puede entrar con una cuenta en esa o a mquina, podr entrar en el webmail (lgicamente). Para llevar a cabo esta implementacin, a a o o debemos indicarle a IMP que la autenticacin se debe llevar a cabo usando los mdulos o o PAM de la mquina donde se encuentra alojada la aplicacin. a o En el soporte electrnico de este documento se puede encontrar los cheros de conguracin de o o Horde e IMP para esta conguracin. Una vez que se han llevado a cabo estos ajustes, realizamos o
31

https://webmail.urjc.es

A. Gutirrez Mayoral e

85

ETSI Informtica a

4.3. OTROS SERVICIOS DISPONIBLES

Figura 4.11: Webmail de pantuo 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 imgenes 4.11 para el webmail de la mquina pantuo y 4.12 para el webmail de la a a mquina bilo. a Sobre esta conguracin pueden realizarse mejoras adicionales, como dotar al sistema de un o servicio de agenda, calendario, libreta de direcciones, e incluso acceso a las cuentas de usuario (cheros personales de cada cuenta) a travs del navegador web. En nuestro caso, todos estos e servicios se implementan junto al servicio webmail: agenda, libreta de direcciones y acceso a las cuentas a travs del navegador web. e

4.3.

Otros servicios disponibles

En la siguiente seccin se comentarn una serie de servicios que, aunque no son imprescindibles o a para que el correcto funcionamiento del Laboratorio, resultan ms que interesantes para un a funcionamiento ms eciente. En concreto, vamos a comentar brevemente la instalacin de listas a o de correo para la comunicacin entre administradores y usuarios del sistema (algo fundamental, o debido a que no tenemos ms datos de los usuarios que su direccin de correo en el sistema) a o as como la instalacin de una rplica de paquetes de software tanto para Debian como para o e 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 comunicacin entre los usuarios o y los administradores o responsables tcnicos del mismo. En nuestro caso, debido a que la e autenticacin en nuestros laboratorios no se basa en el dominio unico que provee la Universidad, o no disponemos de ms datos de los usuarios que la direccin de correo que poseen en el momento a o en el que se abre la cuenta (la direccin de correo con dominio @pantuo.escet.urjc.es. Por o supuesto ser responsabilidad del usuario leer este correo o redireccionarlo a una direccin que a o 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 gestin de la comunicacin entre los administradores del laboratorio y los usuarios, o o instalaremos la herramienta de listas de correo mailman. Para la comunicacin entre los o administradores del sistema y los usuarios del mismo, creamos dos listas, cuya funcin ser la o a siguiente:

Figura 4.13: Gestin de listas de correo en pantuo con Mailman. o

Una lista para la comunicacin entre los administradores y los usuarios del sistema en el o campus de Mstoles, a la que llamaremos lista pantuo-todos. o Una lista para la comunicacin entre los administradores y los usuarios del sistema en el o campus de Fuenlabrada, a la que llamaremos lista bilo-todos. A. Gutirrez Mayoral e 87 ETSI Informtica a

4.3. OTROS SERVICIOS DISPONIBLES La primera lista, obviamente ser gestionada en uno de los servidores del campus de Mstoles. a o Como vimos en el Cap tulo de Especicacin y Dise o, este servidor ser la mquina o n a a pantuo.escet.urjc.es. Uno de los motivos que lleva a que sea esta mquina la que albergue a las listas de correo para el campus de Mstoles es el dominio de salida de los correos, la mquina o a visible al resto de los usuarios @pantuo.escet.urjc.es. De la misma forma, la segunda lista, destinada a la comunicacin entre los administradores o y los usuarios del sistema en el campus de Fuenlabrada, estar albergada en la mquina a a bilo.cct.urjc.es, que es la mquina destinada a albergar la gestin de la pgina web del a o a Laboratorio y el correo electrnico, entre otros. o Existen otras listas que pueden resultar de utilidad para la gestin interna del laboratorio. o 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, etctera. e Comentamos alguna a continuacin. o La lista pantuo-local tiene como funcin la comunicacin interna entre profesores y o o administradores del laboratorio. La lista pantuo-backups recibe las alertas de las copias de seguridad que se ejecutan peridicamente en el sistema (en ambos campus). o La lista pantuo-nagios-estaciones recibe las alertas por caidas en las estaciones de usuario, enviadas automticamente por la herramienta nagios. a La lista pantuo-nagios-servidores recibe las alertas por caidas en los servidores, enviadas automticamente por la herramienta nagios. a La lista pantuo-raids recibe noticaciones automticas del estado de los raids en todas a las mquinas que los usan. a La lista pantuo-hd-alerts recibe noticaciones de alertas que se puedan producir en los discos duros de las mquinas cr a ticas (servidores principalmente). Debido a que la gestin del laboratorio (tanto del campus de Fuenlabrada como el de Mstoles) o o se suelen hacer f sicamente desde Mstoles, todas estas listas estarn albergadas en la mquina o a a pantuo.escet.urjc.es. Gestin de listas o La gestin de listas a travs de la herramienta mailman es realmente sencilla. Como hemos o e visto, la gestin de estas listas se llevar a cabo en las mquinas pantuo.escet.urjc.es y o a a bilo.cct.urjc.es, en las que est instalado Debian GNU/Linux. Por tanto, la instalacin se puede a o llevar a cabo usando el gestor de paquetes apt-get: Listado 4.55: Instalacin de mailman usando apt-get o
$ apt - get install mailman

Durante la instalacin, es probable que el gestor de paquetes realice alguna pregunta relativa a o la post conguracin del mismo. Una vez instalado, es necesario que se cree una primera lista para o 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: Creacin de una nueva lista de mailman usando el comando newlist o
$ newlist mailman

Proyecto Fin de Carrera

88

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Despus de responder a algunas preguntas relativas a la gestin de la lista (persona que la e o gestiona, contrasea inicial, etctera) ser necesario aadir la informacin de salida del comando n e a n o al chero /etc/aliases. La informacin que el chero contendr por tanto, es parecida a esta: o a
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 resear que despus de haber modicado el contenido de este chero es necesario n e ejecutar el comando newaliases. Si no se hace, no se har visible ninguna modicacin que se a o haya hecho de cara al gestor de correo y a mailman. Una vez que las listas estn correctamente instaladas, la gestin de ellas se puede realizar a o unicamente utilizando un navegador. Solamente es necesario crearlas con el comando newlist, ya que toda su gestin puede realizarse mediante el interfaz web de mailman. En la gura 4.13 o podemos observar la pantalla de administracin de la listas de correo de mailman (para la mquina o a pantuo).

4.3.2.

Mirror de Debian y Ubuntu

Debido a que, como se coment en anteriores cap o tulos, en las estaciones del Laboratorio tenemos instalada la ditribucin Ubuntu Linux, resulta realmente interesante tener disponible de o forma interna a la red un mirror o espejo que nos sirva para poder instalar paquetes de una forma ms eciente. Sin duda la capacidad de la red es bastante alta, y en ese sentido, la instalacin de a o paquetes no resulta para nada lenta en ningn caso. Sin embargo, siempre resulta ms eciente de u a cara al trco de la red descargar los paquetes una unica vez y luego replicarlo en todas aquellas a mquinas en las que sea necesario. a Por ello, se decide llevar a cabo la instalacin (o mejor dicho, la rplica) de un servidor de o e paquetes tanto para Ubuntu, como para Debian. En el caso de Debian la necesidad no es tan alta, puesto que esta distribucin unicamente se usa en los servidores. Adems, la red Rediris provee o a de un mirror o espejo de paquetes para esta distribucin, por tanto la penalizacin de trco por o o a descarga no ser tan alta en este caso. a Para la instalacin de un mirror local usamos la herramienta debmirror, la cual o descargar todos los paquetes necesarios para consolidar la rplica local de una determinada a e versin de Debian (o de Ubuntu), con sus correspondientes ramas y secciones. La herramienta o debmirror se encuentra disponible tanto en Debian GNU/Linux como en Ubuntu como paquete, y con una unica llamada al gestor de paquetes puede ser instalada. Listado 4.57: Instalacin de la herramienta debmirror usando apt-get o
$ apt - get install debmirror

Una vez que ha sido instalada, debe ser congurada para ser ejecutada peridicamente (lo o ms normal, es que se ejecute una vez al d a a). Lo ms fcil para llevar a cabo esta tarea es a a usar una l nea de cron, para asegurar que este comando se ejecuta peridicamente. Como es o sabido , las distribuciones que nos ocupan (Debian y Ubuntu) se dividen en versiones. A su vez estas versiones, estn divididas en secciones. Por tanto, deberemos indicarle a la herramienta a A. Gutirrez Mayoral e 89 ETSI Informtica a

 4.4. MONITORIZACION DEL SISTEMA debmirror que versiones queremos replicar as como qu secciones y ramas de desarrollo. Lo e 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 rplica de Ubuntu usando el comando debmirror e
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 travs del cual se replicar la informacin e a o es archive.ubuntulinux.org, que se usar el mtodo ftp, y que se replicarn las versiones a e a de Ubuntu dapper, edgy, feisty, gutsy, y hardy. Adems, en cada versin se replicarn las a o a secciones main, universe, multiverse y restricted. Por ultimo, le indicamos que la unica arquitectura que se deber replicar es la aquitectura Intel x86 y que se debern ignorar las a a advertencias relativas a las rmas PGP. El caso de Debian es ms simple, puesto que tanto el nmero de versiones como las ramas y a u secciones es mucho menor, tal y como muestra la llamada a debmirror del listado 4.59. Listado 4.59: Descargando la rplica de Debian usando el comando debmirror e
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 unicamente se debern replicar las versiones de Debian testing, a stable, unstable y experimental, las secciones main, contrib y non-free en la arquitectura Intel x86. Una vez que hemos congurado el servidor de paquetes como rplica para Ubuntu y Debian, e congurar los clientes para que usen este mirror es trivial. Para ello, editamos el chero /etc/apt/sources.list. Como comentamos en el cap tulo Dise o, la mquina peloto ser la n a a encargada de albergar el mirror de Ubuntu y de Debian en el Laboratorio, por tanto, en el caso de Ubuntu, el contenido del chero podr ser el mostrado en el listado 4.60. a Listado 4.60: Contenido del chero /etc/apt/sources.list usando la rplica del Laboratorio e
2

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 versin feisty de Ubuntu. o Para el caso de Debian, el contenido del chero es prcticamente el mismo, y por tanto no a ser mostrado a continuacin. a o

4.4.

Monitorizacin del Sistema o

Una vez que todo el sistema est implantado y se ha comprobado el correcto funcionamiento de a todos los objetivos que nos plantebamos, la monitorizacin del mismo es un aspecto fundamental. a o 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 muy importante conocer el estado de a aquellas mquinas que ofrecen servicios que resultan cr a ticos para el correcto funcionamiento de los laboratorios, es decir, los servidores. La monitorizacin de las estaciones de trabajo es algo importante, pero en todo caso, el que o una estacin de trabajo no funcione en un momento dado, no origina que el resto de estaciones o 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 extrao est ocurriendo y requiere nuestra atencin. n a o Existen numerosas aplicaciones que prestan funcionalidad de monitorizacin de servicios o y mquinas en una red local. Como vimos en el cap a tulo Estado del arte, hemos elegido la herramienta Nagios para la monitorizacin bsica de estaciones, servidores y servicios en cada o a una de ellas (alertar de posibles ca das en mquinas y/o servicios y env de mensajes). Por otro a o lado, hemos elegido la herramienta Munin para recolectar informacin ms elaborada acerca del o a funcionamiento de cada uno de los servidores. Esta informacin ser representada a travs de o a e grcas que podremos visualizar a travs de nuestro navegador web favorito. a e Por otro lado, utilizaremos un script muy sencillo que informar del estado de las estaciones a de cara a los usuarios del mismo (principalmente, los alumnos). Esta utilidad volcar en una a pgina web el estado de todas las estaciones, para las que se identicarn tres estados posibles: a a la mquina est apagada, la mquina est encendida pero solo responde al ping y por ultimo, la a a a a mquina est encendida y responde al ping (est disponible). A esta utilidad la llamaremos parte a a a de guerra y estar disponible tanto en el campus de Mstoles y de Fuenlabrada. A continuacin a o o vamos a ver de forma ms detallada el proceso de monitorizacin de los servidores y de las a o estaciones.

4.4.1.

Monitorizacin de servidores o

Como ya se ha comentado, para la monitorizacin de los servidores usaremos dos aplicaciones o principalmente. Utilizaremos Nagios para la monitorizacin bsica de mquinas y servicios (esto o a a es, saber si las mquinas y los servicios estn o no disponibles) y de forma ms avanzada, a a a utilizaremos Munin para una monitorizacin ms avanzada de los servidores. Munin proporciona o a informacin ms detallada y extensa de una mquina en concreto, representada a travs de o a a e grcas, que se pueden ver a travs del navegador web. Munin est compuesto de dos aplicaciones a e a principales: el cliente, que env informacin de la mquina al servidor Munin, y el servidor, que a o a recolecta la informacin que le env los clientes y la representa a travs de grcas clasicadas o an e a en diferentes reas. Ser muy interesante obtener a travs de Munin la informacin del uso de a a e o CPU, memoria, procesos, uso de la red, uso del servidor NFS en una mquina en concreto. a La mquina que usaremos como vig de toda esta informacin (tanto Nagios como Munin) a a o ser la mquina espatula, como ya se estudi en el cap a a o tulo Especicacin y Diseo. o n Instalacin de Nagios o La instalacin de Nagios usando apt-get es realmente sencilla, mostrndose en el listado 4.61. o a Listado 4.61: Instalacin de la herramienta Nagios con apt-get o
$ apt - get install nagios - text

Nagios est disponible en diferentes paquetes. En concreto usaremos ste, que almacena la a e informacin en cheros de texto. Otros paquetes de Nagios almacenan la informacin de las o o mquinas monitorizadas en bases de datos MySQL. Por no aadir otro servicio a la instalacin, a n o A. Gutirrez Mayoral e 91 ETSI Informtica a

 4.4. MONITORIZACION DEL SISTEMA decidimos usar la versin de nagios que no necesita de ningn sistema gestor para poder funcionar o u adecuadamente. Una vez que la herramienta ha sido instalada, sta debe ser congurada. En el directorio e /etc/nagios existen numerosos cheros de conguracin que es necesario editar al gusto para o que la herramienta funcione segn nuestras necesidades. La conguracin de nagios puede u o resultar un tanto tediosa si no se automatiza apoyndonos en scripts de automatizacin. Es muy a o recomendable disponer de un chero de texto en el que se encuentren reejadas todas las IPs que se desean monitorizar, as como el nombre de cada mquina. A travs de este chero y usando a e scripts bsicos de shell, la conguracin resulta muy sencilla. Vamos a comentar a continuacin a o o los cheros principales de Nagios que es preciso editar para que funcione correctamente: /etc/nagios/hosts.cfg: almacena la informacin de las mquinas que se desean o a monitorizar (bsicamente, la direccin IP y el nombre de la mquina). a o a /etc/nagios/hostgroups.cfg: agrupa las mquinas aadidas en el chero de conguracin a n o anterior en grupos de mquinas. En nuestro caso, resulta aconsejable agrupar las mquinas a a de cada aula en un grupo diferente, y crear otro para los servidores. /etc/nagios/contacts.cfg: contiene la informacin de las personas de contacto para los o avisos automticos de la aplicacin. La informacin reejada en este chero consta de a o o nombre de la persona de contacto, correo electrnico, telfono, etctera. o e e /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 administracin de cada mquina estuviera separada. En nuestro caso (debido a que el equipo o a tcnico es ms bien pequeo) no se usar, y unicamente existir un grupo. e a n a a /etc/nagios/services.cfg: este chero almacen la informacin de los servicios que se o desean monitorizar de una mquina o de un grupo de mquinas en concreto. Por ejemplo, a a a monitorizar que la mquina est disponible (servicio check ping), que la mquina tiene el a a servicio SSH ejecutando (servicio check ssh), etctera. e Una vez que todos los cheros han sido congurados, es necesario reiniciar el servico nagios, para que la conguracin se actualice y todo empiece a funcionar adecuadamente. Existen o diferentes otros cheros de conguracin que no son exactamente relativos a Nagios, como son la o conguracin de Apache, los usuarios que pueden acceder a la informacin, etctera. o o e Una vez que est todo funcionando, podemos acceder al sistema de monitorizacin32 . En la a o imagen 4.14 se pude observar la pgina principal del estado de los servicios en Nagios. Podemos a ver las mquinas del Laboratorio de Mstoles agrupadas por aula (106, 108, 109 y 111) y los a o servidores. Por cada grupo, se puede observar las mquinas que estn disponibles y el estado de a a los servicios que se monitorizan en esas mquinas. Podemos ver que en todas las aulas todas las a mquinas estn disponibles (estado OK) menos en el aula 108, que hay dos que no lo estn, y a a a que en principio la mayor de los servicios estn disponibles (excepto de las mquinas que estn a a a a apagadas, por supuesto). Por cada mquina se monitorizan como m a nimo dos servicios: servicio ping y servicio ssh. Para los servidores, se monitorizan ms cosas. Por ejemplo, en pantuo a nos interesar saber que los servidores web (HTTP) y correo (SMTP, POP3s e IMAPs) estn a a disponibles. En la parte de la izquierda de la pgina se muestra el men de opciones de Nagios (que son a u bastantes). La parte ms interesante ser saber los problemas de los servicios que haya en algunas a a mquinas. Podemos acudir a la opcin service problems para ver los problemas que hay en las a o
32

http://espatula.pantuo.es/nagios/

Proyecto Fin de Carrera

92

Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION

Figura 4.14: La pgina de resumen de estado de Nagios para el Laboratorio de Mstoles. a o

Figura 4.15: La pgina de problemas de Nagios muestra los problemas en algunas mquinas. a a mquinas que se monitorizan. En la imagen 4.15 podemos ver la informacin contenida en esta a o seccin, las mquinas que tienen problemas, la duracin del mismo y cuando se comprob por o a o o ultima vez. Adems de esta informacin, por supuesto, los problemas que pueda tener una mquina en a o a concreto se pueden enviar por correo electrnico. Para ello, es preciso congurar los cheros que o 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 Mstoles, y 100 en el o campus de Fuenlabrada. A cada reinicio de mquina, tendremos dos mensajes de correo electrnico a o (servicio DOWN y servicio UP). Esto puede ocasionar demasiados mensajes y producir un efecto rebote, que nos haga prescindir de esta informacin. En nuestro caso, los mensajes de alerta de las o estaciones se enviarn a una direccin de correo y los de los servidores (ya que requieren mucha a o ms atencin) se enviarn a otra. a o a Instalacin de Munin o Vamos a utilizar Munin como sistema de recoleccin de informacin para los servidores o o unicamente. Como hemos visto, Munin se compone de un servidor que representa la informacin o de los clientes, y los nodos que env la informacin al servidor. La instalacin de Munin es muy an o o sencilla en un sistema Debian o basado en la herramienta apt-get: En el servidor:

A. Gutirrez Mayoral e

93

ETSI Informtica a

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

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

En los clientes, unicamente ser necesario indicar qu servidor puede conectarse al puerto de a e escucha de Munin y obtener la informacin de la mquina. Esto se puede indicar editando el o a chero /etc/munin/munin-node.conf : Listado 4.64: Instalacin de la herramienta Munin (cliente) con apt-get o
host_name lechuzo allow ^212\.128\.4\.9 $

Los parmetros ms importantes son el nombre que se mostrar en la pgina de Munin, a a a a y la IP que puede acceder al nodo para recopilar la informacin. Este parmetro obviamente o a depender de la mquina que recoja los datos de los clientes de Munin. a a

4.4.2.

Monitorizacin de estaciones o

La monitorizacin de estaciones de cara a los usuarios del sistema se llevar a cabo a travs de o a e 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 prcticas. a

Figura 4.16: El parte de guerra de Mstoles muestra el estado de las estaciones. o En la imagen 4.16 puede observarse la visualizacin del parte de guerra para el campus de o Mstoles33 . Como se puede observar, para cada estacin se representa mediante el color verde o o
33

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

Proyecto Fin de Carrera

94

Universidad Rey Juan Carlos

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

4.5.

Seguridad

Para nalizar, el ultimo de nuestros objetivos ser elevar el grado de seguridad de todos los a servicios disponibles. En concreto, vamos a centrar nuestros esfuerzos en tener controlados los siguientes aspectos: Limitar los accesos remotos a las mquinas clave para el correcto funcionamiento del a laboratorio (servidores, principalmente). Detectar intrusiones en las estaciones mediante geolocalizacin de las conexiones de hosts o remotos. Deteccin de ataques de fuerza bruta en los intentos de autenticacin a las estaciones o o Evaluar la debilidad de las contraseas de los usuarios mediante la herramienta John the n ripper.

4.5.1.

Limitar los accesos remotos

En primer lugar, vamos a impedir el acceso a aquellas mquinas que son cr a ticas para el correcto funcionamiento del Laboratorio. Principalmente, los servidores, tanto del campus de Mstoles como el de Fuenlabrada. Aunque tambin, ser necesario limitar las conexiones en o e a los servidores LDAP para que solamente sea posible que se conecten a ellos estaciones de los Laboratorios. Limitar el acceso SSH mediante los cheros 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 Telemticos o al Laboratorio. Esto es, a a mquinas pertenecientes a la subredes 212.128.4.0/24, 193.147.71.0/24 para el Campus de a Mstoles, y 193.147.73.0/24 junto con la subred 193.147.71.0/24 para el Campus de Fuenlabrada. o De esta forma, aseguramos que nadie pueda iniciar una sesin SSH en ningn servidor si no lo o u hace desde dentro de alguna de nuestras redes. Esta norma se aplicar a todos los servidores a excepto al servidor pantuo y al servidor bilo, en los que se puede iniciar una sesin SSH en o principio desde cualquier host. Para poder llevar a cabo esta restriccin, haremos uso de los cheros /etc/hosts.deny y o /etc/hosts.allow. En concreto, en el chero /etc/hosts.deny, debemos indicar que por defecto se deniegue cualquier conexin SSH a no ser que alguna regla lo permita (descrita en el chero o /etc/hosts.allow. Por tanto, el chero /etc/hosts.deny debe contener lo siguiente:
sshd : ALL
34

http://bilo.cct.urjc.es

A. Gutirrez Mayoral e

95

ETSI Informtica a

4.5. SEGURIDAD De esta forma estamos indicando que el servicio SSH ser denegado a cualquier host, a no ser a que el chero /etc/hosts.allow diga lo contrario. Y es aqu donde este chero 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 usar el servicio SSH. De esta forma, no podremos abrir una conexin SSH a o desde fuera de estas tres subredes, lo que a priori, reducir considerablemente la probabilidad a de que alguien ajeno a los laboratorios o al departamento intente nada contra estas mquinas. a 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 blica/privada u Si queremos aumentar an ms el grado de seguridad a la hora de inicar una sesin u a o SSH en cualquiera de los servidores, podemos desactivar el inicio de sesin mediante o desaf pregunta/respuesta (el tradicional acceso introduciendo una contrasea), y activar la o n autenticacin unicamente usando mecanismos de criptograf de clave pblica/privada. De esta o a u forma, ser necesario generar un par de claves, copiar la clave p blica del host desde el que a u queremos conectar al servidor en cuestin y aadirlo en el chero authorized keys del directorio o n /root/.ssh/. De esta forma, solamente podrn inciar sesin en el servidor aquellos usuarios que a o posean la clave privada y la palabra de paso que la desbloquea (en caso de que haya sido generada con contrasea). Adems, en caso de perder la clave privada, no tendr n a amos por qu preocuparnos (demasiado) debido a que sin la palabra de paso, es una clave totalmente intil. e u Por tanto, para poder iniciar sesin en cualquiera de los servidores, necesitaremos cumplir o 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 adems saber la palabra de paso que desbloquea la clave) a Como vemos, son dos requisitos sucientemente restrictivos que nos proporcionan bastante tranquilidad en la seguridad del servidor y disminuyen bastante la probabilidad de intrusin en o la mquina. a Impedir la conexin a los servidores LDAP desde fuera de los Laboratorios o Los servidores LDAP, si nada lo impide, permiten que cualquier mquina pueda realizar a peticiones de lectura sin emplear ningn mecanismo de autenticacin previo. Debido a la u o arquitectura de LDAP como mecanismo de autenticacin, es necesario que de forma annima, o o un usuario pueda realizar peticiones de lectura de su nombre de usuario (adems de otra serie a de datos), de forma totalmente annima (de hecho, esto es lo que le permite autenticarse). Cabe o resear que entre estos datos no se encuentra la contrasea, aunque existen otros que son tambin n n e muy sensibles, y que se pueden consultar de forma annima si nada lo impide. La otra posibilidad o es introducir un usuario que permita leer los datos de todos los usuarios, inclu la contrasea, y da n congurar los clientes para que se aten a este usuario para realizar operaciones de autenticacin. o En nuestro caso hemos optado por el primer mecanismo, ya que conguraremos los servidores para que no respondan a peticiones que vengan de mquinas que no se encuentran en los Laboratorios. a Proyecto Fin de Carrera 96 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Para llevar a cabo esta restriccin, vamos a emplear el mismo mecanismo que en el punto o anterior, cuando limitbamos el acceso a los servidores mediante SSH: haciendo uso de los cheros a 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 autenticacin de un campus pueden o 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 chero /etc/hosts.deny:
slapd : ALL

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

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

4.5.2.

Auditor de usuarios a

Otro de los aspectos que es muy importante de cara a la seguridad general del sistema es la implantancin de algn tipo de sistema de auditor tanto de los usuarios que se encuentran en un o u a, momento dado en el sistema como de los comandos que ejecutan en cualquiera de las estaciones. En este sentido, no hemos encontrado ninguna aplicacin en sistemas operativos Linux que o realize esta tarea de forma automtica. En concreto, para la auditor de comandos realizados a a por los usuarios, existe un parche para el kernel de Linux llamado process accounting a travs e del cual, el kernel del sistema operativo vuelca en un chero (situado en el directorio /proc) que puede ser leido en principio por aplicaciones que obtienen en un formato legible por humanos la informacin concerniente a los diversos comandos que los usuarios ejecutan en el sistema. o No obstante, esta informacin es demasiado verbosa, ya que aade una entrada por cada o n proceso que el usuario ejecuta en un momento dado. Cuando realizamos algunas pruebas de este sistema de auditor nos encontramos con que en un slo d podemos obtener miles y miles de a o a l neas de informacin (debido al elevado nmero de estaciones y de usuarios) con el consecuente o u problema de almacenamiento que ello supon (adems del indexado posterior en un momento a a determinado). Sin embargo, la auditor de los usuarios conectados en el sistema en un momento dado a no resulta ni tan verbosa ni tan costosa en trminos de almacenamiento. Es por ello que nos e planteamos la creacin de un sistema que registre en cualquier momento los usuarios que se o encuentran logueados en el sistema, en cualquier mquina del laboratorio. a Como ya hemos comentado anteriormente, no encontramos ninguna aplicacin que nos o resolviera esta funcionalidad de forma satisfactoria, por lo que optamos por programar nuestro propio sistema de auditor a medida. El sistema no debe tener grandes pretensiones: simplemente a 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 bsicos de shell que recojan la salida de comandos estndar de Unix que devuelven a a la informacin relativa a los usuarios conectados en el sistema en un momento dado (como por o ejemplo los comandos w o who). En principio, la informacin que nos gustar almacenar de cada usuario ser la siguiente: o a a Host o estacin en la que el usuario se encuentra conectado o logueado. o A. Gutirrez Mayoral e 97 ETSI Informtica a

4.5. SEGURIDAD Consola en la que ha iniciado sesin (una consola virtual, de texto o la consola grca). o a Fecha y hora en la que ha iniciado sesin o Fecha y hora actual Host remoto desde el que ha iniciado la sesin. o El almacenamiento de esta informacin en una base de datos MySQL supondr la creacin o a o de una base de datos y una tabla a tal efecto. Para la informacin que necesitamos almacenar, o podemos usar las siguientes sentencias de SQL mostradas en el el listado 4.65. Listado 4.65: Creacin de una tabla en MySQL para almacenar la informacin relativa a auditor o o 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 sucientes 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 informacin o relativa a la auditor de usuarios: a Listado 4.66: Script bsico para registrar informacin de auditor de usuarios a o a
#!/ bin / bash
2 4 6 8 10 12 14 16

TMP_FILE1 = mktemp -p $HOME / bin / TMP_FILE2 = mktemp -p $HOME / bin / / usr / bin / who | sed s / / _ / g > $TMP_FILE1 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 $MYSQL_HOST -- pas sword = $MYSQL_PASSWORD $MYSQL_DATABASE 1 > / dev / null 2 > / dev / null rm $TMP_FILE1 rm $TMP_FILE2

18 20

22

A travs del script anterior, se registrarn los usuarios que estn conectados en una mquina e a a a 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 automticamente todos los usuarios que estn conectados en una estacin, con una frecuencia muy a e o baja (cada minuto). La siguiente l nea de cron puede ser suciente para dejar denida la tarea: Listado 4.67: L nea de cron para la automatizacin de la auditor de usuarios en el sistema o a
*/1 * * * * sh / root / who - mostoles . sh

La posterior consulta de datos en un momento determinado, dado que stos son almacenados e en una base de datos MySQL, se puede realizar a travs de sentencias bsicas de SQL. Incluso, se e a puede realizar a travs de un portal PhpMyAdmin35 , para minimizar la dicultad en la consulta e de estos datos.

4.5.3.

Deteccin de intrusos o

Deteccin de IPs no espa olas o n Gracias al sistema que hemos diseado e implantado para registrar los accesos de los usuarios n en cada una de las estaciones, podemos disear diversos sistemas de alerta que nos avisen ante n situaciones sospechosas. Una de estas situaciones podr ser la conexin en una estacin desde un a o o host remoto fuera de Espaa. No es frecuente en el entorno que tenemos instalado que se conecten n al laboratorio alumnos desde fuera del pa excepto contadas excepciones, las cuales podr ser s, an enumeradas en un chero de nombres de usuario a no tener en cuenta por este monitor. Para poder detectar si un host remoto pertenece o no al pa podemos usar la herramienta s, geoiplookup, tal y como se muestra en el ejemplo mostrado en el listado 4.5.3. La ejecucin de o este comando devuelve el cdigo de pa correspondiente a la geolocalizacin del host. o s o
agutierr@minervo ~ $ geoiplookup 212.128.4.4 GeoIP Country Edition : ES , Spain

Si a travs de la salida de este comando se detecta que la IP o host remoto no pertenece a e Espaa (es decir, haciendo bsquedas por cdigos no pertenecientes a ES, Spain tendremos una n u o lista de IPs (combinando con la estacin y nombre de usuario que se ha usado en la conexin) o o cuanto menos, sospechosas de ser investigadas. El monitor o script que realiza esta tarea puede ser consultado en el apndice de este e 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 prcticas, existen unos l a 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 prcticas a altas horas de la madrugada). Debido a que encontrar usuarios trabajando a altas a horas de la noche tambin puede ser sospechoso a priori, podemos programar otro monitor que e 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 Aplicacin que permite realizar operaciones de gestin y consulta sobre un sistema gestor MySQL a travs de o o e un navegador.

A. Gutirrez Mayoral e

99

ETSI Informtica a

4.5. SEGURIDAD

echo " SELECT hostname , logname , now , \ from \ FROM \ who \ WHERE now >= \" $DATE 02:00\" AND now <= \" $DATE 07:00\" AND \ from \ != AND \ from \ NOT LIKE %: % and pts not like tty " | / usr / bin / mysql -u who2 -- password = $MYSQL _PASSWORD -h $MYSQL_HOST who - escet > $TMPFILE

Para ello, basta generar una sentencia SQL que obtenga los usuarios que han iniciado conexin o nocturna en el presente d entre las dos y las 7h del d en cuestin, tal y como muestra el a, a o listado de cdigo 4.68. Este volcado nos devolver la lista de logins, estacin y fecha/hora en la o a o que el usuario ha iniciado una sesin nocturna, que puede ser enviado por correo electrnico a un o o administrador del laboratorio, para su posterior estudio, por ejemplo. Como se puede observar, las posibilidades que ofrece un sistema de auditor son bastante a elevadas, y puede resultar muy interesante estudiar estos registros, y no con nes necesariamente basados en la seguridad del sistema. La generacin de estad o sticas de uso de las estaciones, disponibilidad, etctera, pueden ser tambin objetivo del uso de estos indicadores. e e

4.5.4.

Ataques de fuerza bruta v SSH a

Los ataques de fuerza bruta son muy frecuentes en ordenadores con sistema operativo Unix, con multitud de usuarios y con IPs pblicas accesibles desde cualquier punto del mundo, en el que u adems, se dispone de un rango entero de direcciones para poder intentar romper una contrasea a n y lograr estar dentro del sistema. Desde este punto de vista, nuestro sistema cumple con todos los aspectos deseables para un intruso: disponemos de 160 mquinas con IPs pblicas, servicio a u SSH y gran multitud de usuarios. Por si fuera poco, el conseguir entrar en una cuenta en uno de los equipos, proporciona evidentemente acceso al resto. Resulta muy atractivo desde el punto de vista del intrusismo de sistemas el conseguir penetrar en un estacin de una red universitaria. o Ya no solamente por el mero hecho de conseguirlo, sino por las consecuencias o las posibilidades que esto puede traer. Debido a la gran cantidad de estaciones de las que dispone el laboratorio y la gran capacidad de ancho de banda del mismo, un ataque de denegacin de servicio lanzado o adecuadamente puede provocar la caida de cualquier sitio en Internet. En la traza del chero /var/log/auth.log mostrada en el listado 4.69 podemos ver los intentos de conexin usando o fuerza bruta para conseguir entrar en el sistema probando nombres de usuario y contraseas n aleatorios. Listado 4.69: Intentos de ataque de SSH mediante fuerza bruta o diccionario
2 4 6 8

Jun Jun Jun Jun Jun Jun Jun Jun

26 26 26 26 26 26 26 27

08:43:28 08:43:36 08:43:40 08:43:44 08:43:49 08:43:54 08:43:57 21:48:29

delta08 delta08 delta08 delta08 delta08 delta08 delta08 delta08

sshd [7699]: Invalid user staff from 82.187.180.163 sshd [7701]: Invalid user sales from 82.187.180.163 sshd [7703]: Invalid user recruit from 82.187.180.163 sshd [7705]: Invalid user alias from 82.187.180.163 sshd [7707]: Invalid user office from 82.187.180.163 sshd [7709]: Invalid user samba from 82.187.180.163 sshd [7712]: Invalid user tomcat from 82.187.180.163 sshd [17458]: Invalid user fluffy from 59.144.127.75

Vemos como, en el mismo d y desde la misma IP, se intenta acceder al sistema usando a, nombres de usuario aleatorios (normalmente provenientes de diccionarios anglosajones) sin xito, e por supuesto. Es por esto que reducir las posibilidades de que un atacante consiga una cuenta de un usuario mediante fuerza bruta ser un aspecto fundamental del sistema. Para lograr que esto a no pase, nos planteamos defendernos en dos aspectos principales: Limitar la conectividad a un usuario que intenta en sucesivas ocasiones autenticarse, Fortalecer la seguridad de las contraseas de los usuarios, mediante la ejecucin peridica n o o de herramientas del estilo de John the ripper. Proyecto Fin de Carrera 100 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION Limitar la conectividad a un usuario segn el nmero de intentos errneos de autenticacin en u u o o un periodo determinado de tiempo es una tarea bastante sencilla, si se desea programar mediante scripts caseros y no usar ninguna aplicacin que ya permita realizar esta tarea. Basta auditar o el chero de autenticacin /var/log/auth.log en busca de entradas de autenticacin errnea, o o o obtener el host remoto que ha iniciado la autenticacin e impedir la posterior autenticacin a o o este usuario. Para impedir a este usuario que se vuelva a autenticar en el sistema podemos usar iptables, aadiendo reglas concretas de denegacin de servicio SSH para la IP concreta n o correspondiente a su Host o incluyendo la IP correspondiente en el chero /etc/hosts.deny. Hay que tener en cuenta que un nmero muy extenso de reglas en IPTables puede provocar la u sobrecarga del sistema a la hora de atender peticiones de red, por lo que se recomienda el uso de los cheros /etc/hosts.allow y /etc/hosts.deny, como hemos visto anteriormente. Sin embargo, la programacin de estos scripts y ltros, adems del conseguiente uso de o a iptables para denegar o aceptar conexiones a determinados hosts puede resultar un tanto tediosa, por lo que en nuestro caso, vamos a usar una aplicacin que se encarga precisamente de ltrar o los intentos de ataques de fuerza bruta en el servicio SSH. Esta aplicacin es Denyhosts, y o est programada en Python. Adems, se incluye como paquete Debian tanto en Debian estable a a como en Ubuntu, por lo que la podremos instalar tanto en las estaciones de trabajo de los usuarios como en la mayor de los servidores. a Denyhosts Como hemos descrito anteriormente, Denyhosts36 es una herramienta que intenta eliminar la mayor de los ataques de fuerza bruta mediante SSH, monitorizando para ello el chero a /var/log/auth.log en busca de intentos de acceso con usuarios inexistentes, o intentos de autenticacin errneos. Una vez detectados estos intentos, clasicados como ataques, se incluir el o o a host que ha provocado tal intento en el chero /etc/hosts.deny, impidiendo al host remoto la conectividad al puerto SSH de la v ctima, o directamente, a cualquier servicio. La herramienta Denyhosts es muy popular entre administradores de sistemas de todo el mundo, existiendo de hecho una base de datos de atacantes y atacados, que puede ser consultada y descargada por cualquier mquina que se encuentre ejecutando la herramienta. Esto permite prevenir de alguna a usando listas negras de atacantes que nos puedan atacar, aunque esta ultima caracter stica, no siempre es bien acogida, debido a que podemos clasicar a priori como atacante a una mquina que a no lo es (supongamos un escenario en el que existe una red de mquinas que usan IPs privadas, a saliendo a Internet mediante un NAT con una unica IP pblica). Es por ello, que se deja a u eleccin del administrador el descargar la base de datos de IPs de los atacantes ms frecuentes, o a o no. De la misma forma, y para que la caracter stica anterior funcione, tambin podremos e informar de nuestros atacantes a la base de datos global de Denyhosts, para conocimiento del resto de administradores o de mquinas. Todo esto es fcilmente congurable a travs del chero a a e de conguracin de Denyhosts. o La instalacin de Denyhosts es inmediata en sistemas basados en Debian. Una unica llamada o al gestor de paquetes basta para realizar la instalacin: o Listado 4.70: Instalacin de la herramienta Denyhosts o
pantuflo :~# apt - get install denyhosts

Una vez instalada la herramienta, podemos congurar la multitud de opciones que permiten el funcionamiento a medida segn el grado de seguridad que queramos implantar en nuestra u mquina. Para ello, podemos editar el chero /etc/denyhosts.conf. Algunas de las opciones a ms importantes, pueden ser: a SECURE LOG, que indica la ruta hacia el chero que se debe monitorizar.
36

http://denyhosts.sourceforge.net/

A. Gutirrez Mayoral e

101

ETSI Informtica a

4.5. SEGURIDAD HOSTS DENY, que indica la ruta hacia el chero donde deben incluirse los atacantes para la posterior denegacin del servicio SSH. o PURGE DENY, que indica el plazo de denegacin una vez que se incluye el atacante en o as, el chero HOSTS DENY. Este plazo puede indicarse en minutos, horas d semanas, o aos. En el caso de las estaciones del Laboratorio, el tiempo de denegacin es de 12 horas. n o DENY THRESHOLD INVALID, que indica el umbral de intentos con login incorrecto. En el caso en el que se intente acceder al sistema con un usuario que no existe un nmero de veces igual a este valor ms uno, el host ser clasicado como atacante u a a e incluido en el chero HOSTS DENY. En el caso del Laboratorio este valor es de 5 intentos. HOSTS DENY, muy similar al parmetro anterior, pero para intentos con login vlido a a pero contrasea incorrecta. En el caso del Laboratorio, este valor es de 10 intentos. n DENY THRESHOLD ROOT, nmero de intentos invlidos para el usuario root, a u a partir del cual debe considerarse al host remoto como atacante. En el caso del Laboratorio, un intento. Hay que tener en cuenta que en el Laboratorio, la mayor de veces que se a accede como usuario root a las estaciones es con clave pblica, y no mediante desaf de u o contrasea. Por lo que, el monitorizar esta accin puede resultar cuanto menos, sospechoso. n o SYNC UPLOAD, activando este parmetro informaremos de nuestros atacantes a la a pgina de Denyhosts, para compartirlos con el resto de usuarios. a SYNC DOWNLOAD, y de la misma forma, podremos descargar la informacin de o atacantes del resto de usuarios mundiales de Denyhosts. El chero de conguracin de Denyhosts es bastante extenso, permitiendo un gran nmero de o u combinaciones que permiten subir o bajar el nivel de seguridad a la hora de clasicar los intentos de ataques de fuerza bruta. Recomendamos la consulta de uno de los cheros de conguracin de o Denyhosts que se incluyen tanto en el apndice de este documento como en el soporte electrnico e o adjunto, correspondiente al chero de conguracin que se usa en las estaciones del Laboratorio. o La aplicacin Denyhosts es casi fundamental para impedir la multitud de ataques diarios de o fuerza bruta que se produc en el sistema antes de instalarla. Sin ella, debido a la debilidad de an las contraseas de los usuarios, tendr n amos multitud de intrusiones en las estaciones de usuario (como pasaba anteriormente, cuando no se usaba).

4.5.5.

Seguridad en las contrase as de los usuarios n

Los intentos de securizar al mximo el sistema pueden resultar en vano si posteriormente, a los usuarios emplean contraseas dbiles en sus cuentas. Esta situacin puede provocar que un n e o usuario malicioso que tenga en su poder la lista de usuarios del sistema (lo cual no resulta muy complicado) pueda sentir impulsos de romper las contraseas de los usuarios. Esta accin puede n o llevarse de manera muy simple, y aunque como vimos en secciones anteriores, hemos intentado limitar el nmero de accesos por estacin y usuario incorrecto, el usuario textit malicioso puede u o tener suerte y conseguir hacerse con una cuenta ajena. Una vez que un usuario ajeno tiene acceso a una cuenta de usuario, los daos suelen basarse en el uso de las estaciones para lanzar ataques n DOS sobre sitios web, etctera, accin que causa bastantes problemas de cara al funcionamiento e o de la red dentro de la Universidad. Sin duda, uno de los aspectos ms importantes del lado de la seguridad del sistema reside en a concienciar a los usuarios de que las contraseas de sus cuentas deben cumplir al menos, unos n requisitos m nimos de seguridad. Aunque al principio y a lo largo del curso se informa a los Proyecto Fin de Carrera 102 Universidad Rey Juan Carlos

 CAP ITULO 4. IMPLANTACION usuarios de esta situacin, no son pocos los que no hacen caso y deciden establecer contraseas o n no muy seguras para sus cuentas. En este caso, nos vemos obligados a intentar avisarles de la situacin personalmente y si deciden no hacer caso y como ultimo remedio, cambiar su contrasea o n automticamente. Para intentar automatizar esta tarea al mximo, programamos un script que a a con ayuda de la herramienta John the ripper compruebe la dureza de las contraseas del n sistema. Este script se ejecutar todas las noches tanto para las cuentas del campus de Mstoles a o como para el de Fuenlabrada. John the ripper John the Ripper es un programa de criptograf que aplica fuerza bruta para descifrar a contraseas. Es capaz de romper varios algoritmos de cifrado o hash, como DES, SHA-1 y otros. n Es una herramienta de seguridad muy popular, ya que permite a los administradores de sistemas comprobar que las contraseas de los usuarios son sucientemente buenas. John the Ripper es n capaz de autodetectar el tipo de cifrado de entre muchos disponibles, y se puede personalizar su algoritmo de prueba de contraseas. Eso ha hecho que sea uno de los ms usados en este campo. n a Ejecutando John the ripper regularmente Apoyndonos en la herramienta John the ripper, vamos a comprobar la dureza de las a contraseas de los usuarios diariamente. El procedimiento a seguir ser el siguiente: n a Descargar el chero de usuarios del sistema (para cada campus) en formato LDIF. Transformar ese chero al formato clsico passwd/shadow. En este punto usaremos el a script auxiliar ldif2passwd, escrito en Perl. Ejecutar John the ripper durante ocho horas, aproximadamente. Pasadas estas ocho horas, todos aquellos usuarios para los que su contrasea haya sido descifrada, sern n a avisados mediante correo electrnico de la situacin. Sern avisados como mucho dos o o a veces, ya que a la tercera, su cuenta ser desactivada temporalemente (su contrasea a n ser modicada automticamente). La nueva contrasea ser elegida automticamente con a a n a a ayuda del comando pwgen. De esta forma, nos aseguramos que las contraseas de los usuarios cumplen unos m n nimos requisitos de seguridad, y que la posibilidad de que un usuario pueda colarse a travs de una e cuenta ajena es m nima. En el apndice de este documento, as como en el soporte electrnico e o adjunto, puede consultarse el script que lleva a cabo esta tarea de forma automtica. a

A. Gutirrez Mayoral e

103

ETSI Informtica a

4.5. SEGURIDAD

Proyecto Fin de Carrera

104

Universidad Rey Juan Carlos

Captulo

Conclusiones
Con el cap tulo Conclusiones llegamos al nal de este documento. En este breve cap tulo que sirve como cierre del proyecto evaluaremos si se han cumplido todos los hitos que nos plantebamos a en un principio. A continuacin, intentaremos realizar una lista de todos los conocimientos que o se han adquirido gracias a la realizacin del proyecto. Por ultimo, intentaremos plantear l o neas futuras de trabajo que pueden servir como base para la continuacin de este proyecto, bien a travs o e de un proyecto perteneciente a un programa de postgrado o bien como un proyecto derivado para titulaciones de grado.

105

5.1. LOGROS ALCANZADOS

5.1.

Logros alcanzados

En esta seccin haremos un breve resumen por todos aquellos hitos que se han completado o satisfactoriamente durante la realizacin del proyecto. o Desarrollar un sistema de instalaciones masivas y completamente desatendidas: Se ha implementado un mecanismo de instalacin para sistemas Linux (en concreto para la o distribucin Ubuntu Linux) totalmente desatendido, que prepara un sistema listo para ser o usado en un entorno docente como en el que nos encontramos. El sistema est personalizado a para los requisitos docentes del Departamento, pero puede ser adaptado para cualquier entorno docente o empresarial muy fcilmente. Este sistema facilita la tarea al administrador a de cara a realizar instalaciones masivas en cualquier entorno de una forma limpia, sencilla y eciente. Implantar un sistema de cuentas de usuario y disco en red: Despus de evaluar e las diferentes alternativas de las que se dispon para implementar un sistema de cuentas an de usuario en red, se ha puesto en marcha un servicio de directorio basado en LDAP que proporciona un servicio de autenticacin de usuarios en entornos Unix. A travs de este o e protocolo los usuarios pueden iniciar una sesin en una estacin del Laboratorio y realizar o o su trabajo diario. Adems, se facilita un servicio de disco en red para que los usuarios a dispongan de su propio directorio personal una vez que inician su sesin. Gracias a este o directorio pueden almacenar sus prcticas, as como sus cheros personales (documentos, a apuntes, etctera). e Dotar al entorno de una serie de servicios de valor a adido: Los hitos anteriores n conforman las bases principales del proyecto. Sin embargo, una vez que estos objetivos se completan, se dota al entorno con un conjunto de servicios que lo van a convertir en un entorno ms agradable y funcional de cara a los usuarios del mismo. Estos servicios son: a 1. Pgina web del Laboratorio, donde se incluye la mxima documentacin del a a o entorno de cara a los usuarios (horarios, preguntas de uso frecuente, noticias y notas de rgimen interno de los Laboratorios, etctera). Adems se da la posibilidad a los e e a usuarios de disponer de su propio espacio personal donde puedan colgar material relacionado con cualquiera de las asignaturas que cursan. 2. Sistema de correo electrnico, se pone en marcha un sistema de correo electrnico o o que sirva como mecanismo de comunicacin entre los administradores del Laboratorio o y los propios usuarios. Adems, los usuarios pueden usar este buzn como cuenta de a o correo electrnico personal. o 3. Listas de correo, las cuales son usadas para los anuncios que se env a todos los en usuarios del sistema (en ambos Campus) as como un mecanismo de env de alertas o sobre cualquier tipo de incidencia que se pueda producir en cualquiera de los servidores. 4. Espejos locales de las distribuciones Ubuntu y Debian, de cara a aumentar la velocidad de los procesos de instalacin de los sistemas y de cualquier software en los o Laboratorios, se instala un mirror local en la organizacin de las distribuciones que o usamos en el Laboratorio: Debian GNU/Linux y Ubuntu. Este mirror puede ser usado por los propios alumnos desde sus porttiles o incluso en sus equipos personales de a casa. Instaurar un servicio de monitorizacin de la red y de los servicios: Se instala y o congura una herramienta de monitorizacin de la red (Nagios) la cual nos va a permitir o Proyecto Fin de Carrera 106 Universidad Rey Juan Carlos

CAP ITULO 5. CONCLUSIONES controlar en todo el momento el estado de nuestro entorno, tanto si las mquinas estn a a todas encendidas y funcionando como si stas se encuentran ejecutando todos los servicios e correspondientes. Esta herramienta, fundamental en un entorno en el que nos encontramos, nos va a permitir detectar por medio de alertas enviadas por correo electrnico cualquier o problema que se produzca en un plazo muy corto de tiempo. Aumentar al mximo la seguridad del entorno: La seguridad en nuestro es un aspecto a bastante cr tico, debido a que el nmero de estaciones es muy elevado, as como la cantidad u de cuentas de usuario. Al tener todas las estaciones direcciones IP pblicas, digamos que u hay muchas posibilidades de que si no se toma ninguna medida, un usuario annimo fuera o capaz de conseguir una cuenta de usuario de forma ileg tima. A travs de las medidas que e tomamos en esta seccin conseguimos aumentar la seguridad del entorno en tres frentes o principales: establecer pol ticas de acceso a servidores en funcin de la direccin IP de o o los clientes, intentar detectar los intentos de ataques de fuerza bruta al servicio SSH y restringir el acceso desde esas IP, y revisar la fuerza de las contraseas de los usuarios n utilizando la herramienta John the ripper. Podemos concluir por la experiencia que gracias a estas medidas las cuentas robadas por usuarios maliciosos ha disminuido hasta casi cero.

5.2.

Conocimientos adquiridos

El llevar a cabo todos los hitos planteados en la fase inicial del desarrollo nos ha dotado con una serie de conocimientos adquiridos que pueden suponer el inicio de una carrera o de un perl basado en la administracin de sistemas, un perl muy valorado hoy en d en el entorno o a empresarial. Estos conocimientos son, entre otros, los siguientes: Conocimientos avanzados de entornos Unix/Linux: La administracin diaria de o este entorno supone una base muy slida en esta familia de sistemas operativos. Aunque o las distribuciones usadas en nuestro entorno han sido Debian GNU/Linux y Ubuntu, estos conocimientos son fcilmente aplicables o extensibles a cualquier distribucin, y a o por supuesto aplicable en cualquier sistema operativo de la familia Unix. En este sentido podemos tambin garantizar los conocimientos adquiridos en la administracin diaria del e o entorno, en la creacin de scripts o guiones, lo que proporciona conocimientos en lenguajes o de shell como bash, python o perl. Procesos de instalaciones desatendidos para PCs: A travs de la construccin del e o proceso de instalacin desatendido de Ubuntu para las estaciones del Laboratorio, nos o hemos visto obligados a probar otras alternativas (era el caso de la clonacin de disco). o Aunque no fue nalmente el mtodo elegido como proceso de instalacin para nuestros e o equipos, adquirimos bastantes conocimientos en la l nea de estas herramientas, muy usadas en entornos docentes o empresariales donde se requiere la instalacin clnica de sistemas o o operativos de escritorio en general de numerosos equipos. Por supuesto, se han adquirido conocimientos del mtodo de los cheros de preconguracin de paquetes o preseeds en e o Debian. Este mtodo es muy potente y a medida que avance el tiempo y se documente un e poco ms ser muy usado en entornos empresariales y docentes. a a Sistemas de cuentas de usuario en red: Dado que anteriormente la solucin en o produccin en el Laboratorio para proporcionar servicio de cuentas de usuario en red estaba o basada en la tecnolog NIS de Sun Microsystems, podemos armar que se ha aprendido a a manejar esta tecnolog a administrar cuentas de usuario distribuidas usando este protocolo. a Una vez planteado el cambio a un directorio LDAP, tuvimos que conocer el funcionamiento A. Gutirrez Mayoral e 107 ETSI Informtica a

5.3. TRABAJO FUTURO de este protocolo y las aplicaciones que lo implementaban, como OpenLDAP, por lo que tambin hemos aprendido a manejar un directorio de usuarios basado en LDAP, con todo e lo que ello conlleva. Adems, se han llevado a cabo conguraciones avanzadas de servidores a LDAP, incluyendo replicacin, tolerancia a fallos y seguridad en las comunicaciones. Estos o conocimientos son particularmente interesantes ya que LDAP supone ya casi un estndar a de facto como mecanismo de autenticacin de usuarios, por su exibilidad y sencillez. o Aplicaciones de servidor en entornos Unix: Debido a la implantacin de diferentes o servicios de valor aadido. En concreto, podemos enumerar los siguientes: n 1. Apache, como servidor de pginas web, para la publicacin de la pgina web del a o a Laboratorio as como la gestin de las pginas web de usuarios. o a 2. Dovecot como servidor de recogida de correo POP3 e IMAP y postx como agente de transporte de correo electrnico. o 3. NFS como sistema de cheros en red, para facilitar el uso de directorios personales por parte de los usuarios. 4. Soluciones RAID para poder proporcionar un servicio de disco en red lo sucientemente grande para dar espacio a todas las cuentas de usuario que posee el sistema. En particular, se ha usado la herramienta mdadm para la gestin del o RAID v software, tomando nociones de los diferentes niveles de RAID existentes y a ponindolo en prctica. e a 5. Mailman como gestor de listas de correo para el env de anuncios a los usuarios del o Laboratorio, y el env de alertas por parte del sistema de monitorizacin. o o 6. MediaWiki como gestor de contenidos para la pgina web de los Laboratorios de los a Campus de Mstoles y Fuenlabrada. o 7. Munin y Nagios como herramientas de monitorizacin. En concreto Munin est ms o a a orientado a conocer el estado particular de una mquina (un servidor) y Nagios a ms orientado a conocer el estado de la red, enviando alertas ante cualquier tipo de a incidencia que se encuentre.

5.3.

Trabajo futuro

Por ultimo y de forma muy breve, se comentan algunas l neas de investigacin o de desarrollo o futuras basadas en todo el trabajo desarrollado: Creacin de una herramienta personalizada para la administracin de cuentas en el o o Laboratorio. Dicha herramienta podr tratarse de una aplicacin web, para que pueda a o ser usada en principio tanto por los administradores del Laboratorio como por los propios profesores. Uso de virtualizacin en los servidores. En vez de usar mquinas f o a sicas, se podr an virtualizar todos aquellos servidores que se consideraran oportunos. La tcnica de la e virtualizacin est muy de moda hoy en d y supone un gran avance en la administracin o a a o de sistemas. A travs de ella se consigue que en un mismo servidor se puedan ejecutar e mltiples servidores virtuales aislados y seguros. u Creacin de herramientas para la sincronizacin y la instalacin automtica de paquetes. o o o a Ahora mismo, la sincronizacin en la instalacin de los paquetes as como en los propios o o cheros de cada mquina es totalmente manual. a

Proyecto Fin de Carrera

108

Universidad Rey Juan Carlos

 Apendice

Scripts de Instalacin Automtica o a

En el siguiente apndice se incluirn todos aquellos cheros de preconguracin necesarios e a o para la herramienta de instalacin automtica desarrollada para los Laboratorios. En concreto o a y para este caso, no hay muchos cheros importantes: el chero de preconguracin para la o instalacin, el chero de Isolinux necesario para el arranque por red y posterior comienzo de la o instalacin y los cheros de conguracin del servidor DHCP. o o

 A.1. FICHERO DE PRECONFIGURACION GENERICO

A.1.

Fichero de preconguracin genrico o e

El siguiente chero de preconguracin se usa para la instalacin del Laboratorio 111 de los o o Laboratorios de Linux de la ETSII, en el Campus de Mstoles. Sin embargo, la adaptacin a o o cualquier otro equipo o instalacin es extremadamente simple, unicamente es necesario modicar o el esquema de particionado del disco y si se desea, el script de postinstalacin que realiza los o ajustes necesarios una vez que se ha instalado el sistema base. Listado A.1: El chero de preconguracin necesario para la instalacin desatendida. o o
## Network Configuration # Note that any hostname and domain names assigned from dhcp take # precidence over values set here . However , setting the valu es still # prevents the questions from being shown even if values come from dhcp . d-i netcfg / get_hostname string gsyc d-i netcfg / get_domain string pantuflo . es # Disable that annoying WEP key dialog . d-i netcfg / wireless_wep string
10

# netcfg will choose an interface that has link if possible . This makes it # skip displaying a list if there is more than one interface . d-i netcfg / choose_interface select eth0
15

20

# If you prefer to configure the network manually , here s how : d-i netcfg / disable_dhcp boolean false #d - i netcfg / get_nameservers string 212.128.4.2 #d - i netcfg / get_ipaddress string 212.128.4.57 #d - i netcfg / get_netmask string 255.255.255.0 #d - i netcfg / get_gateway string 212.128.4.1 d-i netcfg / confirm_static boolean true ## Mirror Settings d-i mirror / country string enter information manually d-i mirror / http / hostname string peloto . escet . urjc . es d-i mirror / http / directory string / ubuntu / d-i mirror / suite string hardy d-i mirror / http / proxy string # Alternatively , you can specify a disk to partition . The dev ice name can # be given in either devfs or traditional non - devfs format . # For example , to use the first disk devfs knows of : d-i mirror / security - host peloto . escet . urjc . es d - i partman - auto partman - auto / select_disk string / dev / sda d - i partman - auto / method string regular # Si no , puede colocar la receta en una l nea . Este ejemplo crea una partici n o # / boot peque~ a , una partici n de intercambio apropiada y usa el resto del n o # espacio para la partici n ra z : o d - i partman - auto / expert_recipe string boot - root :: 300 7000 40000 ext3 $primary { } $bootable { } method { format } format { } use_filesystem { } fi lesystem { ext3 } mountpoint { / } . 64 512 300 % linux - swap method { swap } format { } . 100 10000 1000000000 ext3 method { format } format { } use_filesystem { } filesystem { ext3 } mountpoint { / data } .

25

30

35

40

#d - i partman - auto / expert_recipe string boot - root :: 20 10 000 10000000 ext3 $primary { } $bootable { } method { format } format { } use_filesystem { } fi lesystem { ext3 } mountpoint { / } . 500 10000 1000000000 ext3 method { format } f ormat { } use_filesystem { } filesystem { ext3 } mountpoint { / data } . 64 512 300 % linux - swap method { swap } format { } . # en un formato m s legible : a # boot - root :: # 40 50 100 ext3 # $primary { } $bootable { } # method { format } format { } # use_filesystem { } filesystem { ext3 } # mountpoint { / boot }

45

50

Proyecto Fin de Carrera

ii

Universidad Rey Juan Carlos

 APENDICE A. SCRIPTS DE INSTALACION AUTOMATICA

# # # # # # # # # . 500 10000 1000000000 ext3 method { format } format { } use_filesystem { } filesystem { ext3 } mountpoint { / } . 64 512 300 % linux - swap method { swap } format { } .

55

60

# This makes partman automatically partition without confi rmation . d-i partman / choose_partition select Finish partitioning and write changes to disk d-i partman / confirm boolean true
65

70

75

## Boot loader # This is fairly safe to set , it makes grub install automatica lly to the MBR # if no other operating system is detected on the machine . d-i grub - installer / only_debian boolean true # This one makes grub - installer install to the MBR if if finds some other OS # too , which is less safe as it might not be able to boot that oth er OS . d-i grub - installer / with_other_os boolean true # Alternatively , if you want to install to a location other than the mbr , # uncomment and edit these lines : #d - i grub - installer / bootdev string ( hd0 ,0) #d - i grub - installer / only - debian boolean false #d - i grub - installer / with_other_os boolean false d-i languagechooser / language - name - fb select Spanish d-i debian - installer / locale select es_ES . UTF -8 d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i d-i finish - install / reboot_in_progress note 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

80

85

90

95

## Zona horaria d-i time / zone string Europe / Madrid ## comando final , termina de ajustar el host con los parametr os y aplicaciones del laboratorio d-i preseed / late_command string wget http :// espatula . pa ntuflo . es / preseeds / hardy /111/ ajustes / ajusta - instalacion . sh ; chmod + x ajusta - in stalacion . sh ; sh ajusta instalacion . sh

100

## Timezone d-i tzconfig / gmt boolean false d-i tzconfig / choose_country_zone / Europe select Madrid d-i 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 ###### Account setup . #### Stolen from oem . seed # Create a special user with a preconfigured uid . # passwd passwd / user - fullname string OEM Configuration ( t emporary user ) # passwd passwd / username string oem # passwd passwd / user - uid string 29999

105

110

115

# # # #

To preseed the root password , you have to put it in the clear in this file . That is not a very good idea , use caution ! passwd / root - password password r00tme passwd / root - password - again password r00tme

A. Gutirrez Mayoral e

iii

ETSI Informtica a

 A.1. FICHERO DE PRECONFIGURACION GENERICO

# If you want to skip creation of a normal user account . # passwd / make - user boolean false
120

# lUsers d-i d-i d-i

125

passwd / user - fullname passwd / username passwd / user - password - crypted

string agutierr string agutierr passwd $1$ascCqW . t $ b f U O F H D Q L p B m p r 9 d O r P . a0

130

135

## Package selection #d - i pkgsel / install - pattern string ~ t ^ ubuntu - standard$ |~ n ^ openssh - server$ |~ n ^ ubuntu - desktop$ #d - i pkgsel / install - pattern string ~ t ^ ubuntu - desktop$ |~ n ^ openssh - server$ d-i tasksel / first multiselect ubuntu - desktop # You can choose to install any combination of tasks that are a vailable . # Available tasks as of this writing include : Desktop enviro nment , # Web server , Print server , DNS server , File server , Mail server , # SQL database , manual package selection . The last of those will run # aptitude . You can also choose to install no tasks , and force the # installation of a set of packages in some other way . # XXX : this will not work until tasksel 2.12 is available # d-i tasksel tasksel / first multiselect Desktop environme nt # tasksel tasksel / first multiselect Web server , Mail server , DNS server # d-i tasksel tasksel / first multiselect spanish # During a normal install , exim asks only two questions . Here s how to # avoid even those . More complicated preseeding is possible . #d - i exim4 - config exim4 / d c _ e x i m c o n f i g _ c o n f i g t y p e selec t no configuration at this time #d - i exim4 - config exim4 / dc_postmaster string

140

145

## X Configuration # Preseeding Debian s X config is possible , but you probably need to know # some details about the video hardware of the machine , since Debian s X # configurator does not do fully automatic configuration of everything .
150

# X can detect the right driver for some cards , but if you re pr eseeding , # you override whatever it chooses . Still , vesa will work most places . # xserver - xorg xserver - xorg / config / device / driver selec t vesa
155

# A caveat with mouse autodetection is that if it fails , X will retry it # over and over . So if it s preseeded to be done , there is a poss ibility of # an infinite loop if the mouse is not autodetected . # xserver - xorg xserver - xorg / autodetect_mouse boolean true # d-i xserver - xorg xserver - xorg / autodetect_monitor bool ean true # xserver - xorg xserver - xorg / config / monitor / selection - method select medium # xserver - xorg xserver - xorg / config / monitor / mode - list s elect 1024 x768 @ 60 Hz # xserver - xorg xserver - xorg / config / display / modes multi select 1024 x768 , 800 x600 # Things below here slurped in from data / debconf snippet if it exists # console - common console - data / keymap / policy select Don t touch keymap # console - data console - data / keymap / policy select Don t t ouch keymap # keyboard layouts # console - data console - data / keymap / qwerty / layout selec t ES spanish # console - data console - data / keymap / family select qwerty # console - common console - data / keymap / family select qwer ty # # preguntas de ldap # LDAP version to use : # Choices : 3 , 2 ldap - auth - config ldap - auth - config / ldapns / ldap_versio n select 3 # Unprivileged database user : ldap - auth - config ldap - auth - config / binddn string cn = proxyuser , dc = example , dc = net # LDAP server Uniform Resource Identifier : ldap - auth - config ldap - auth - config / ldapns / ldap - server string ldapi :/// findme # Distinguished name of the search base :

160

165

170

175

180

Proyecto Fin de Carrera

iv

Universidad Rey Juan Carlos

 APENDICE A. SCRIPTS DE INSTALACION AUTOMATICA

ldap - auth - config ldap - auth - config / ldapns / base - dn # Does the LDAP database require login ? ldap - auth - config ldap - auth - config / dblogin # Make local root Database admin : ldap - auth - config ldap - auth - config / dbrootlogin # LDAP account for root : ldap - auth - config ldap - auth - config / rootbinddn net # LDAP root account password : ldap - auth - config ldap - auth - config / rootbindpw stri ng dc = example , dc = netfindme

185

boolean fals e boolean false string cn = manager , dc = example , dc =

190

password

195

# not manage with debconf ldap - auth - config ldap - auth - config / move - to - debconf sel ect No ldap - auth - config ldap - auth - config / move - to - debconf boo lean false # ldap - auth - config ldap - auth - client / move - to - debconf bo olean false ldap - auth - client ldap - auth - client ldap - auth - config ldap - auth - client / move - to - debconf ldap - auth - client / move - to - debconf ldap - auth - config / override sel ect No boo lean false boolean fal se

200

205

clock - setup clock - setup / utc boolean false # ajustes finales d-i preseed / late_command string wget http :// espatula . pa ntuflo . es / preseeds / hardy /111/ ajustes / ajusta - instalacion ; chmod + x ajusta - insta lacion ; sh ajusta - instalacion

A.2.

Conguracin Isolinux o

Adems del chero de preconguracin, es necesario modicar el chero Isolinux para que a o arranque con el chero de preconguracin que se detalla anteriormente. Estos detalles se o especican en el cap tulo de Implantacin del presente documento. A continuacin mostramos el o o chero de conguracin de Isolinux necesario para llevar a cabo esta accin. o o Listado A.2: Fichero de conguracin de Isolinux para el arranque por red. o
DISPLAY ubuntu - installer / i386 / boot - screens / boot . txt F1 F2 F3 F4 F5 F6 F7 F8 F9 F0 ubuntu - installer / i386 / boot - screens / f1 . txt ubuntu - installer / i386 / boot - screens / f2 . txt ubuntu - installer / i386 / boot - screens / f3 . txt ubuntu - installer / i386 / boot - screens / f4 . txt ubuntu - installer / i386 / boot - screens / f5 . txt ubuntu - installer / i386 / boot - screens / f6 . txt ubuntu - installer / i386 / boot - screens / f7 . txt ubuntu - installer / i386 / boot - screens / f8 . txt ubuntu - installer / i386 / boot - screens / f9 . txt ubuntu - installer / i386 / boot - screens / f10 . txt

10

DEFAULT install
15

LABEL install kernel ubuntu - installer / i386 / linux append vga = normal initrd = ubuntu - installer / i386 / initrd . gz netcfg / choose_interface = eth0 locale = es_ES console - setup / ask_detect = false console - setup / layoutcode = es languagechooser / language - name = Spanish countrychooser / shortlist = ES console keymaps - at / keymap = es netcfg / get_hostname = unassigned - hostname preseed / url = http :// espatula . pantuflo . es / preseeds / hardy /111/ preseed -20

PROMPT 1 TIMEOUT 1

Como se puede observar, se indica en la etiqueta INSTALL que se cargue el chero de preconguracin correspondiente con la directiva preseed/url. o A. Gutirrez Mayoral e v ETSI Informtica a

 A.3. FICHERO DE CONFIGURACION DEL SERVIDOR DHCP

A.3.

Fichero de conguracin del servidor dhcp o

Por ultimo, para que el equipo sea capaz de arrancar correctamente por red, es necesario poner en marcha un servidor DHCP que despache direcciones IP y el resto de la conguracin o por red necesaria para esta tarea. El chero de conguracin del demonio DHCP que lleva a cabo o esta labor se muestra a continuacin. Para no exceder en nmero de l o u neas del documento, se muestra unicamente la entrada para un host en concreto (el host beta01 ) ya que la conguracin o es similar para N hosts. En el soporte electrnico adjunto se puede encontrar el chero en su o totalidad, para los 160 hosts existentes en el Laboratorio. Listado A.3: Fichero de conguracin de Isolinux para el arranque por red. o
# # # # # # # # Sample configuration file for ISC dhcpd for Debian Attention : If / etc / ltsp / dhcpd . conf exists , that will be used as configuration file instead of this file . $Id : dhcpd . conf , v 1.1.1.1 2002/05/21 00:07:44 peloy Exp $

10

# The ddns - updates - style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed . We defau lt to the # behavior of the version 2 packages ( none , since DHCP v2 didn t # have support for DDNS .) ddns - update - style none ; # option definitions common to all supported networks ... option domain - name " pantuflo . es "; option domain - name - servers 212.128.4.1 , 212.128.4.3;

15

20

default - lease - time 600; max - lease - time 7200; # If this DHCP server is the official DHCP server for the local # network , the authoritative directive should be uncomment ed . # authoritative ; # Use this to send dhcp log messages to a different log file ( you also # have to hack syslog . conf to complete the redirection ) . log - facility local7 ;

25

30

# No service will be given on this subnet , but declaring it hel ps the # DHCP server to understand the network topology . # subnet 212.128.4.0 netmask 255.255.255.0 { #} # This is a very basic subnet declaration . # subnet 10.254.239.0 netmask 255.255.255.224 { # range 10.254.239.10 10.254.239.20; # option routers rtr -239 -0 -1. example . org , rtr -239 -0 -2. e xample . org ; #} # This declaration allows BOOTP clients to get dynamic addresses , # which we don t really recommend . # subnet 10.254.239.32 netmask 255.255.255.224 { # range dynamic - bootp 10.254.239.40 10.254.239.60; # option broadcast - address 10.254.239.31; # option routers rtr -239 -32 -1. example . org ; #} # A slightly different configuration for an internal subnet . subnet 212.128.4.0 netmask 255.255.255.0 { # range 212.128.4.19 212.128.4.254;

35

40

45

50

55

Proyecto Fin de Carrera

vi

Universidad Rey Juan Carlos

 APENDICE A. SCRIPTS DE INSTALACION AUTOMATICA

option domain - name - servers 212.128.4.2 , 212.128.4.3; option domain - name " pantuflo . es "; option routers 212.128.4.1; option broadcast - address 212.128.4.255; default - lease - time 400; max - lease - time 7200; } # # # # Hosts which require special configuration options can be l isted in host statements . If no address is specified , the address will be allocated dynamically ( if possible ) , but the host - specif ic information will still come from the host declaration .

60

65

70

# host passacaglia { # hardware ethernet 0:0: c0 :5 d : bd :95; # filename " vmunix . passacaglia "; # server - name " toccata . fugue . com "; #} # Fixed IP addresses can also be specified for hosts . These ad dresses # should not also be listed as being available for dynamic ass ignment . # Hosts for which fixed IP addresses have been specified can boot using # BOOTP or DHCP . Hosts for which no fixed address is specified can only # be booted with DHCP , unless there is an address range on the s ubnet # to which a BOOTP client is connected which has the dynamic - b ootp flag # set . # host fantasia { # hardware ethernet 08:00:07:26: c0 : a5 ; # fixed - address fantasia . fugue . com ; #} # # # # You can declare a class of clients and then do address alloca tion based on that . The example below shows a case where all clien ts in a certain class get addresses on the 10.17.224/24 subnet , and all other clients get addresses on the 10.0.29/24 subnet .

75

80

85

90

# class " foo " { # match if substring ( option vendor - class - identifier , 0 , 4) = " SUNW "; #}
95

100

105

110

# shared - network 224 -29 { # subnet 10.17.224.0 netmask 255.255.255.0 { # option routers rtr -224. example . org ; # } # subnet 10.0.29.0 netmask 255.255.255.0 { # option routers rtr -29. example . org ; # } # pool { # allow members of " foo "; # range 10.17.224.10 10.17.224.250; # } # pool { # deny members of " foo "; # range 10.0.29.10 10.0.29.230; # } #} # host beta01 { hardware ethernet 00:0 F :1 F : E4 : A9 :20; fixed - address 212.128.4.19; next - server 212.128.4.12; filename " hardy /111/ pxelinux .0"; }

115

A. Gutirrez Mayoral e

vii

ETSI Informtica a

 A.3. FICHERO DE CONFIGURACION DEL SERVIDOR DHCP

Proyecto Fin de Carrera

viii

Universidad Rey Juan Carlos

 Apendice

Scripts adicionales
En el presente apndice incluimos la mayor de los scripts que se usan a diario en la e a administracin de todo el entorno. Los ms importantes son los scripts de copias de seguridad, o a sobre todo aquellos que se ocupan de realizar una copia de seguridad de los cheros personales de los usuarios (de forma diaria, en otra mquina). Tambin son muy importantes todos los a e scripts que se usan para poder iniciar una sesin SSH en cualquier estacin del Laboratorio como o o usuario root o superusuario, sin necesidad de incluir la contrasea correspondiente. A travs de n e estos scripts se realizan diferentes tareas, como la instalacin de paquetes, la sincronizacin de o o algn directorio en particular o la actualizacin de todos los paquetes del sistema. Sin duda sin u o estos scripts estar amos en un serio problema, ya que tendr amos que realizar cada accin equipo o por equipo introduciendo la contrasea correspondiente del superusuario. n

ix

B.1. SCRIPTS DE COPIAS DE SEGURIDAD

B.1.
B.1.1.

Scripts de copias de seguridad

De lechuzo a sapientin
Listado B.1: Script backup-sapientin.sh

#!/ bin / bash DIR_ORIGEN =/ disks / raid / homes . mostoles DIR_DESTINO =/ disks / raid / homes . mostoles LOG =/ var / log / backups / log_backups_ date + %Y- %m- %d RSYNC =/ usr / bin / rsync ## 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 . echo " Hora de comienzo : " date >> $LOG for i in ls $DIR_ORIGEN ; do echo Haciendo backup a sapientin >> $LOG echo * origen $DIR_ORIGEN / $i >> $LOG echo * destino $DIR_DESTINO / $i >> $LOG $RSYNC - arzvvS -- delete -- exclude ="*. disk " -- max - size =500 M \ -- exclude =" debian - mirror *" \ -- exclude ="*. mp3 " \ -- exclude ="*. avi " \ -- exclude ="*. mpg " \ -- exclude =".*" \ -- include =". forward " \ -- include =". ssh " \ $DIR_ORIGEN / $i root@212 .128.4.6: $DIR_DESTINO done echo " Hora de fin : " date >> $LOG
30

10

15

20

25

echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG echo BACKUP A SAPIENTIN TERMINADO >> $LOG echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> $LOG
35

cat $LOG | mail -s " Backup lechuzo - > 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 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

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

20

25

/ etc / init . d / nscd start

B.1.3.

De sapientin al disco USB

Listado B.3: Script backup-usb.sh

#!/ bin / bash 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 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. Gutirrez Mayoral e

xi

ETSI Informtica a

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 fi mail -s " Backup nano -> disco usb en date " pantuflo - backup s@pantuflo . escet . urjc . es < $LOG

15

20

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 de usuarios a

La auditor de usuarios nos permite saber en todo momento los usuarios que iniciaron una a sesin en el Laboratorio en un momento determinado, con todo lujo de detalles: nombre de usuario, o mquina en la que iniciaron una sesin, fecha y hora del inicio de la sesin, etctera. Estos datos se a o o e 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 continuacin mostramos el script de creacin de o o la base de datos y el de insercin de datos. o

B.3.1.

Creacin de la base de datos o

Listado B.6: Creacin de la base de datos de Auditor o a

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.

Insercin de los datos de auditor o 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 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

10

15

20

B.4.

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

Los scripts llamados ssh-a-todos son algo imprescindible en el sistema. A travs de ellos, e conseguimos iniciar una sesin SSH desde un servidor o estacin a todos las estaciones del o o Laboratorio, como usuario root, sin necesidad de introducir ninguna contrasea. Gracias a esto, n podemos copiar cheros, sincronizar directorios, instalar software, en denitiva, lanzar cualquier comando en cualquier estacin o en un grupo de estaciones de forma totalmente automtica. o a Para realizar esta tarea se utiliza un mecanismo de autenticacin por clave pblica-privada, o u conteniendo la clave pblica del servidor desde el cual iniciamos una sesin en el chero u o /root/.ssh/authorized keys de todas las mquinas del laboratorio. a

B.4.1.

Scripts ssh-a-todos

Disponemos de un script que inicia una sesin SSH a un laboratorio concreto (sala alpha, o 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
#!/ 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

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

A. Gutirrez Mayoral e

xiii

ETSI Informtica a

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

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

Listado B.11: Script sshatodos-deltas.sh

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

Listado B.12: Script sshatodos.sh

#!/ 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 sesin SCP a un laboratorio concreto (sala alpha, o 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
#!/ bin / bash for j in seq -w 01 40 ; do echo scp $1 alpha$j : $2 scp $1 alpha$j : $2 done

Listado B.14: Script scpatodos-betas.sh

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

Listado B.15: Script scpatodos-gammas.sh

#!/ 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

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

#!/ 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 as n

Como indicamos en el cap tulo 4 (Implantacin), diriamente se comprueba la debilidad de o las contraseas de los usuarios, utilizando la herramienta John the Ripper. Para automatizar n esta tarea, se ha desarrollado un script para cada Campus que comprueba la debilidad de las contraseas en cada una de las ramas del directorio LDAP: para los usuarios cuya cuenta se n encuentra en el subrbol de Mstoles as como para los que su cuenta se encuentra en el subrbol a o a de Fuenlabrada. Dichos scripts tienen por nombre john-laboratorio-mostoles para el Campus de Mstoles y john-laboratorio-fuenla para el Laboratorio de Fuenlabrada. o 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 LDAPPASSWD =/ usr / bin / ldappasswd LDIF2PASSWD =/ usr / bin / ldif2passwd . pl LDAPSEARCH =/ usr / bin / ldapsearch MAIL =/ usr / bin / mail
15

10

## 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

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

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 .

35

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

A. Gutirrez Mayoral e

xv

ETSI Informtica a

 B.5. SCRIPT DE DEBILIDAD DE CONTRASENAS

## 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 } ## 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

40

45

50

55

60

65

70

75

80

85

Proyecto Fin de Carrera

xvi

Universidad Rey Juan Carlos

 APENDICE B. SCRIPTS ADICIONALES

done
90

} ## 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 }

95

100

105

110

115

120

125

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 ;; 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 /* ;; alerta ) comprueba_alertas

130

135

140

145

150

A. Gutirrez Mayoral e

xvii

ETSI Informtica a

 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 LDAPPASSWD =/ usr / bin / ldappasswd LDIF2PASSWD =/ usr / bin / ldif2passwd . pl LDAPSEARCH =/ usr / bin / ldapsearch MAIL =/ usr / bin / mail
15

10

## 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

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

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 .

35

40

45

50

## ## 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

55

Proyecto Fin de Carrera

xviii

Universidad Rey Juan Carlos

 APENDICE B. SCRIPTS ADICIONALES

}
60

65

70

75

80

85

90

## 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

95

100

105

110

A. Gutirrez Mayoral e

xix

ETSI Informtica a

 B.5. SCRIPT DE DEBILIDAD DE CONTRASENAS

} ## 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 }

115

120

125

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 ;; 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 /* ;; alerta ) comprueba_alertas ;; esac

130

135

140

145

150

Proyecto Fin de Carrera

xx

Universidad Rey Juan Carlos

 Apendice

Ficheros de conguracin o
Por ultimo, incluiremos en este apndice los cheros de conguracin de aquellos servicios que e o hemos considerado ms importantes. Para agrupar estos cheros de conguracin, realizaremos a o una clasicacin en primer lugar a nivel de mquina donde se alojan y en segundo lugar, en o a cuanto al servicio que prestan.

xxi

 C.1. MAQUINAS ZIPI Y ZAPE

C.1.

Mquinas zipi y zape a

Las mquinas zipi y zape son servidores secundarios LDAP y a la vez, sirven el mapa del a dominio .pantuo.es, como ya vimos en el cap tulo Implantacin. Como ya vimos, el servidor o DNS primario se aloja en la mquina zipi y el secundario en la mquina zape. a a

C.1.1.

Servidor LDAP. Fichero slapd.conf

Listado C.1: Fichero de conguracin /etc/ldap/slapd.conf o

# This is the main slapd configuration file . See slapd . conf (5) for more # info on the configuration options . ####################################################################### # 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 # Read slapd . conf (5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath / usr / lib / ldap moduleload back_bdb
30

25

# The maximum number of entries that is returned for a search o peration sizelimit 500 # 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 > ####################################################################### # 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

35

40

45

50

55

Proyecto Fin de Carrera

xxii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

suffix
60

" 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

65

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

# # # # #

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

100

105

# 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

110

115

access to * by dn = cn = replicator , dc = zipi , dc = escet , dc = urjc , dc = es write 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 * 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

120

125

A. Gutirrez Mayoral e

xxiii

ETSI Informtica a

 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 ####################################################################### # 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 " # 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

165

170

175

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.pantuo.es para zipi

Listado C.2: Fichero de conguracin /etc/bind9/named.conf o

// 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

// // // // // 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 "; }; 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 "; }; zone " ladyr . es " { type slave ; masters { 193.147.71.64; }; file "/ etc / bind9 / db . ladyr . es . slave "; };

20

25

30

35

40

45

50

// 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"; };

55

60

65

70

A. Gutirrez Mayoral e

xxv

ETSI Informtica a

 C.1. MAQUINAS ZIPI Y ZAPE

zone " pantuflo . es " { type master ; file "/ etc / bind9 / db . pantuflo . es "; }; // logging { // category lame - servers { null ; }; //}; 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

75

80

85

95

// 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 ";

100

Listado C.3: Fichero de conguracin /etc/bind9/db.pantuo.es o

; ; ; ;
5

/ var / named / db . gsyc . info datos de la zona pantuflo . es ( @ = gsyc . info . )

10

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

15

pantuflo . es . pantuflo . es . ns0 ns1 @

IN NS IN NS IN A IN A IN A

ns0 . pantuflo . es . ns1 . pantuflo . es . 212.128.4.2 212.128.4.3 212.128.4.4

20

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

IN MX

10 pantuflo . es .

25

30

35

IN IN IN IN IN IN IN IN IN IN IN

A A A A A A A A A A A

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 IN A 212.128.4.12

auditoria . pantuflo . es .

Proyecto Fin de Carrera

xxvi

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

; aliases www ftp webmail pop3 smtp mysql subversion trac

40

45

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 .

50

; Mirrors de Debian y Ubuntu ubuntu IN CNAME debian IN CNAME wiki . pantuflo . es . IN A

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

55

; 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

60

65

70

75

80

85

90

95

100

105

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. Gutirrez Mayoral e

xxvii

ETSI Informtica a

 C.1. MAQUINAS ZIPI Y ZAPE

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

110

115

120

125

130

135

140

145

150

155

160

165

170

175

Proyecto Fin de Carrera

xxviii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

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

180

185

190

195

200

205

210

215

220

225

230

235

240

245

A. Gutirrez Mayoral e

xxix

ETSI Informtica a

 C.1. MAQUINAS ZIPI Y ZAPE

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 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

250

255

260

265

270

275

280

285

290

295

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

300

; seminario 5 de fuenla ( laboratorio SSOO ) 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

305

310

315

Proyecto Fin de Carrera

xxx

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

theta16 theta17 theta18 theta19 theta20 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

320

C.1.3.

Servidor DNS. Fichero named.conf para zape

Listado C.4: Fichero de conguracin /etc/bind9/named.conf o

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

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 "; }; 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"; }; zone " pantuflo . es " { type slave ; file "/ etc / bind9 / db . pantuflo . es "; masters { 212.128.4.2; }; }; logging { category lame - servers { null ; }; };

25

30

35

40

45

50

// zone " com " { type delegation - only ; }; // zone " net " { type delegation - only ; }; // 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

55

A. Gutirrez Mayoral e

xxxi

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

// 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 ";

60

C.2.

Mquina pantuo a

Los servicios ms importantes que se sirven en la mquina pantuo son la pgina web del a a a Laboratorio, las pginas web de los alumnos, el correo de las cuentas @pantuo.escet.urjc.es a y el servicio MySQL (que no ha sido estudiado en este documento).

C.2.1.

Fichero de conguracin de Apache o

Los cheros de conguracin de sitios para Apache en la versin 2, se encuentran situados o o bajo el directorio /etc/apache2/sites-enabled. Listado C.5: Fichero de conguracin /etc/apache2/sites-enabled/pantuo.es o
< 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 > < VirtualHost 212.128.4.4:443 > ServerAdmin agutierr@gsyc . escet . urjc . es ServerName pantuflo . es RewriteRule ^/(.*) https :// pantuflo . escet . urjc . es / $1 [ L , R ] </ VirtualHost >

10

Listado C.6: Fichero de conguracin /etc/apache2/sites-enabled/pantuo.escet.urjc.es o

< 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 > < 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 </ Directory > 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 </ Directory >

10

15

20

25

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

Redirect http :// pantuflo . escet . urjc . es / admin https :// pantuflo . escet . urjc . es / admin / </ VirtualHost > # 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 > < 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 </ Directory > 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 </ Directory > ErrorLog / var / log / apache2 / error . log # Possible values include : debug , info , notice , warn , error , crit , # alert , emerg . LogLevel warn CustomLog / var / log / apache2 / access . log combined ServerSignature On

45

50

55

60

65

70

75

80

85

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

90

< 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 > < Directory / usr / lib / cgi - bin / nagios > Options ExecCGI

95

A. Gutirrez Mayoral e

xxxiii

ETSI Informtica a

 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 > < Directory / usr / share / nagios / htdocs > Options FollowSymLinks

110

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

115

120

</ VirtualHost >

Listado C.7: Fichero de conguracin /etc/apache2/sites-enabled/webmail.pantuo.es o

< 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 > < 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 / </ VirtualHost >

10

Listado C.8: Fichero de conguracin /etc/apache2/sites-enabled/mysql.pantuo.es o

< 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 > < 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 > < Directory / var / www / phpmyadmin / > AllowOverride All </ Directory > < Directory / var / lib / phpmyadmin / >

10

15

20

Proyecto Fin de Carrera

xxxiv

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

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

25

30

35

40

45

C.2.2.

Fichero de conguracin de Postx o

Los cheros de conguracin ms importantes de Postx se encuentran situados en los cheros o a /etc/postx/main.cf y /etc/postx/master.cf. Listado C.9: Fichero de conguracin /etc/postx/main.cf o
# 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 # 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

10

15

20

25

30

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

A. Gutirrez Mayoral e

xxxv

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

# 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

35

40

Listado C.10: Fichero de conguracin /etc/postx/master.cf o

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 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 .

10

15

20

25

30

35

40

45

50

55

Proyecto Fin de Carrera

xxxvi

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# # 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 } # 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

60

65

70

75

80

85

90

95

100

105

110

115

120

300 n

1 -

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

A. Gutirrez Mayoral e

xxxvii

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

tlsmgr scache discard unix unix unix 1000? 1 1 tlsmgr scache discard

125

C.2.3.

Fichero de conguracin de Dovecot o

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

# # 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

10

15

# 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 =

20

25

30

35

40

45

# Disable SSL / TLS support . # ssl_disable = no # 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 .

50

55

Proyecto Fin de Carrera

xxxviii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# ssl_key_password = # 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

60

# 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 # SSL ciphers to use # ssl_cipher_list = ALL :! LOW # 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 =

70

75

80

85

90

# For informational messages , use this logfile instead of the default # info_log_path = # 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 .

95

100

105

110

115

120

125

A. Gutirrez Mayoral e

xxxix

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

# login_process_size = 32 # 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

130

135

140

145

150

# 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

## ## 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

170

175

180

185

# 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 .

190

195

Proyecto Fin de Carrera

xl

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# mail_extra_groups = mail # : 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

200

205

210

215

220

225

230

235

240

245

250

255

260

265

A. Gutirrez Mayoral e

xli

ETSI Informtica a

 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 #}
275

270

280

285

290

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 = # 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 = # 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 # 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 # 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 # 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 # 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 # 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 # Don t use mmap () at all . This is required if you store indexe s to shared # filesystems ( NFS or clustered filesystem ) .

300

305

310

315

320

325

330

335

Proyecto Fin de Carrera

xlii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# mmap_disable = no # 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

340

345

350

355

360

365

370

375

# 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 # 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

395

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 # If mbox size is smaller than this ( in kilobytes ) , don t writ e index files .

405

A. Gutirrez Mayoral e

xliii

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

# If an index file already exists it s still read , just not upd ated . # mbox_min_index_size = 0
410

# 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

415

420

# umask to use for mail files and directories # umask = 0077 # 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

425

430

435

440

445

450

455

460

465

470

475

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 }
500

480

485

490

495

## ## POP3 specific settings ##

505

protocol pop3 { # Login executable location . # login_executable = / usr / lib / dovecot / pop3 - login # POP3 executable location # mail_executable = / usr / lib / dovecot / pop3 # 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 # 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

510

515

520

525

# 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 )

530

535

540

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.3) : %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 .

545

A. Gutirrez Mayoral e

xlv

ETSI Informtica a

 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 # 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 # 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 # 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 = }
580

550

555

560

565

570

575

## ## dovecot - lda specific settings ##

585

# 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 # }

590

595

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

# 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

640

645

650

655

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 # Kerberos keytab to use for the GSSAPI mechanism . Will use the system # default ( usually / etc / krb5 . keytab ) if not specified . # auth_krb5_keytab = 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

670

675

680

685

A. Gutirrez Mayoral e

xlvii

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

# # # # # # # # # # # 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

690

695

700

705

# 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 = #}

710

715

720

725

730

735

740

745

750

755

Proyecto Fin de Carrera

xlviii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

760

# 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 = #} # SQL database # passdb sql { # Path for SQL configuration file , see / etc / dovecot / dovecot - sql . conf # example # args = #}

765

770

for

775

780

# 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 = #} # # # # # # #

785

790

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

795

800

# / 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 = #} # 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

805

810

815

820

825

A. Gutirrez Mayoral e

xlix

ETSI Informtica a

 C.2. MAQUINA PANTUFLO

# example # args = #}
830

835

# LDAP database # userdb ldap { # Path for LDAP configuration file , see / etc / dovecot / dovecot - ldap . conf for # example # args = #} # vpopmail # userdb vpopmail { #} # " 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 { #} # 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 # 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 = # Number of authentication processes to create # count = 1

840

845

850

855

860

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 } # # # # # # 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 .

870

875

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

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# # group = # } # client { # path = / var / run / dovecot - auth - client # mode = 0660 # } # } #} # 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 # 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 # Convert plugin . If set , specifies the source storage path w hich is # converted to destination storage ( default_mail_env ) . # convert_mail = mbox : %h / mail }

900

905

910

915

920

925

930

935

C.3.

Mquina lechuzo a

El unico servicio relevante que se sirve en la mquina lechuzo (servicio cr a tico, por otra parte) son los cheros personales de los usuarios, a travs de NFS. El chero de conguracin ms e o a importante es el chero /etc/exports, que se muestra a continuacin. o Listado C.12: Fichero de conguracin /etc/exports o
# # # # # # # # # # # / 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 )

10

# HOMES

A. Gutirrez Mayoral e

li

ETSI Informtica a

 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.

Mquina peloto a

El servicio ms relevante de esta mquina es el que se ofrece a travs del servidor LDAP. La a a e mquina peloto es el servidor LDAP primario del Laboratorio. El chero de conguracin de este a o servicio se encuentra en /etc/ldap/slapd.conf. Listado C.13: Fichero de conguracin /etc/postx/master.cf o
# This is the main slapd configuration file . See slapd . conf (5) for more # info on the configuration options . ####################################################################### # 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 # Read slapd . conf (5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath / usr / lib / ldap moduleload back_bdb
30

25

# The maximum number of entries that is returned for a search o peration sizelimit -1 # The tool - threads parameter sets the actual amount of cpu s that is used # for indexing . tool - threads 1 threads 64
40

35

45

####################################################################### # 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 :

50

Proyecto Fin de Carrera

lii

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# 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

55

60

# 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 # 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

70

75

80

85

# 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

90

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. Gutirrez Mayoral e

liii

ETSI Informtica a

 C.4. MAQUINA PELOTO

by by by by by by by by by by by 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

120

125

130

135

140

# 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 #######################################################################

145

150

155

160

165

170

175

180

Proyecto Fin de Carrera

liv

Universidad Rey Juan Carlos

 APENDICE C. FICHEROS DE CONFIGURACION

# 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

185

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

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

205

C.5.

Mquina sapientin a

La mquina sapientin nos sirve para realizar copias de seguridad diarias de los directorios a personales de los alumnos (servidos por la mquina lechuzo). Por tanto, la conguracin de NFS a o es muy similar (por no decir idntica) a la de la mquina lechuzo. El chero ms relevante en este e a a caso es el chero /etc/exports, que es idntico al de la mquina lechuzo. e a

C.6.

Mquina minervo a

La mquina minervo aloja las copias de seguridad de los directorios /etc/ y /root/ de a todas las mquinas, de forma incremental. Cada d se comprime este directorio y se sincroniza a a, utilizando rsync a la mquina minervo. En principio, esta mquina no tiene cheros de a a conguracin relevantes. o

C.7.

Mquina espatula a

La mquina espatula hospeda el servicio de monitorizacin Nagios. Debido a que los cheros a o de conguracin de esta aplicacin son excesivamente largos y verbosos, no se listarn en este o o a documento. En el soporte electrnico adjunto se incluyen todos los cheros de conguracin de o o esta herramienta.

C.8.

Mquina bilo a

La mquina bilo aloja para los Laboratorios del Campus de Fuenlabrada los servicios de a pgina web del Laboratorio, servidor de correo electrnico para las cuentas @bilo.cct.urjc.es a o as como servidor de recogida de correo electrnico (al igual que la mquina pantuo.). Adems, o a a esta mquina aloja los cheros personales o directorios HOME servidos para el Campus de a Fuenlabrada. Adems, esta mquina aloja la pgina web para el Laboratorio de Fuenlabrada, el a a a A. Gutirrez Mayoral e lv ETSI Informtica a

 C.9. MAQUINA NANO servicio de transporte de correo (Postx) para el dominio bilo.cct.urjc.es y los respectivos servicios de recogida de correo a travs de los protocolos POP3 e IMAP. Debido a que e estos ultimos son muy similares a los de la mquina pantuo (las aplicaciones que se usan son a exactamente las mismas, con las mismas conguraciones) redirigimos al lector del documento al soporte electrnico si tiene especial inters en la consulta de estos cheros. o e

C.8.1.

Servicio NFS en bilo

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

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

C.9.

Mquina nano a

Por ultimo, la mquina nano, cuya funcin es muy parecida a la mquina sapientin del a o a Campus de Mstoles (aloja copias de seguridad de los directorios personales de los alumnos) sirve o unicamente el servicio NFS de disco en red. Si la mquina bilo deja de funcionar, ser necesario a a que la mquina nano comenzara a servir los directorios de los alumnos a travs de NFS. En este a e sentido, el chero de conguracin de NFS, situado en /etc/exports, es el mismo que el de la o mquina bilo, mostrado en la seccin anterior. a o Adems, la mquina nano sirve de forma secundaria el rbol LDAP en el que se almacenan las a a a cuentas de usuario de los alumnos y profesores del Laboratorio. El chero de conguracin de este o servicio es exactamente el mismo que el de las mquinas zipi o zape mostrado anteriormente (las a cuales sirven el directorio LDAP tambin de forma secundaria). Remitimos al lector al soporte e electrnico adjuntado en caso de mostrar inters en su consulta. o e

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 OReilly, 2003 [3] Hal Stern, Managing NFS and NIS OReilly, 2001 [4] Michael D. Baurer, Seguridad en Servidores Linux OReilly, 2005 [5] Chris McNab, Seguridad de Redes OReilly, 2004 [6] Brian W. Kernighan, El Entorno de programacin UNIX o Pearson Educacin, 1987 o

lvii

BIBLIOGRAF IA

Proyecto Fin de Carrera

lviii

Universidad Rey Juan Carlos