memoria pfc superior

Ingenierıa Informatica

Escuela Tecnica Superior de Ingenierıa Informatica

Curso academico 2007-2008

Proyecto Fin de Carrera

INSTALACION, CONFIGURACION Y ADMINISTRACION

DE AULAS INFORMATICAS MEDIANTE SOFTWARE

LIBRE

Autor: Antonio Gutierrez MayoralTutor: Jose Centeno Gonzalez

Septiembre 2008

A mis padres y mi hermano

Gracias

La finalizacion de un proyecto fin de carrera normalmente lleva asociado el fin de una etapay el comienzo de otra. En particular, este proyecto resume practicamente los ultimos dos anostrabajando en el GSyC en la administracion de sus laboratorios docentes. Un par de anos en losque he trabajado en un entorno de trabajo que creo que puede considerarse privilegiado y quecualquier persona podrıa envidiar.

A traves de este pequeno texto quiero agradecer al Grupo de Sistemas y Comunicaciones elfacilitarme un entorno de trabajo envidiable, y del que me acordare siempre, sobre todo si algundıa ya no estoy aquı. A Jose Centeno y Pedro de las Heras por confiar en mı y creer en mı comoaquel que podrıa realizar el trabajo que intento hacer todos los dıas con la maxima ilusion posible.Gracias tambien a Sergio Arevalo y Jesus Gonzalez Barahona como directores del Departamentoy estar ahı siempre que lo he necesitado, ayudandome siempre que han podido. Gracias tambiena todo el Grupo por el capital humano aportado y por hacerme sentir en uno de los mejoresentornos de trabajo que he estado.

Gracias a mis companeros de Universidad sin los cuales el dıa a dıa serıa mucho mas amargoy aburrido. Gracias a Lorena, Juan Carlos, Carlos, Tamara, Fran, Javi, Marina, Belen y todoslos demas.

Gracias a mi familia, a mis padres y mi hermano, ya que sin su apoyo y confianza nada deesto hubiera sido posible.

A todos, gracias.

v

Resumen

Hoy en dıa la administracion de sistemas se ha convertido en un aspecto fundamentalen cualquier entorno informatico. En la empresa esta responsabilidad es clara, donde la altadisponibilidad de los sistemas es basica para su operabilidad. De la misma manera, en cualquierentorno docente es fundamental la puesta en marcha de todas aquellas tecnologıas necesarias parapermitir a los alumnos realizar sus practicas y a los profesores impartir sus asignaturas. A vecesesta tarea no es tan facil como parece a simple vista: requiere de conocimientos avanzados deredes, sistemas operativos y administracion de sistemas.

Por otro lado, el avance del Software Libre como modelo de desarrollo de software ademasde como alternativa para la docencia hace muy atractivo su uso de cara a las diferentes materiasque pueden ser impartidos en una carrera de Ingenierıa Informatica, ya que su flexibilidad ylos conceptos sobre los que se sustenta el Software Libre hacen que se pueda adaptar muyfacilmente a ellas. En particular, la puesta en marcha de una serie de tecnologıas relacionadascon la administracion del sistema Linux resultan basicas para que se pueda usar este SistemaOperativo en un entorno docente.

En este proyecto se ha llevado a cabo un analisis de las diferentes tecnologıas que sonnecesarias para el funcionamiento de un entorno de estas caracterısticas. Por un lado, es necesarioestablecer un plan o mecanismo que facilite la labor de los administradores de cara a la instalacionde un numero elevado de estaciones de usuario. Para ello, se implementara un mecanismo deinstalaciones automaticas completamente desatendidas que facilite esta labor.

Por otro lado, tambien se hace necesaria la implantacion de un servicio que facilite que losusuarios puedan iniciar una sesion en el entorno a partir de unas credenciales determinadas(normalmente un par formado por el nombre de usuario y contrasena), ası como proporcionar unservicio de disco en red que facilite a los usuarios el poder almacenar sus ficheros personales a lolargo de toda la red local.

Estos dos objetivos principales son basicos para el funcionamiento del entorno, pero no son losunicos. La adicion de servicios adicionales al Laboratorio, como un servicio de correo electronico(entrega y recogida) ası como un sitio web bien documentado y funcional de cara a los alumnos vana hacer que este sea mas agradable al uso diario. Servicios adicionales de cara a la gestion, comoconstruir y documentar polıticas de seguridad eficientes e instaurar un sistema de monitorizaciondel estado de la red (que garantizaran la rapida deteccion de incidencias y por tanto su resolucion),culmina el proyecto.

La realizacion de este proyecto supone la implantacion de un entorno totalmente funcionalapto para la docencia de todas las practicas de las asignaturas pertenecientes al Departamento deSistemas Telematicos y Computacion, al mismo tiempo que consolidan amplios conocimientos enSistemas Operativos de la familia GNU/Linux, ası como en un amplio abanico de aplicaciones deservidor, ampliamente usadas en entornos empresariales. La construccion adicional de aplicacionesweb de gestion de todos los servicios que hemos implementado en este proyecto, ası como tecnicasavanzadas como la virtualizacion de servidores dejan la puerta abierta a trabajos futuros en lamisma lınea de investigacion que el presente proyecto.

vii

Indice general

1. Introduccion 3

1.1. Motivacion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Estructura de este documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Distribuciones de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2. Sistemas de instalacion desatendidos . . . . . . . . . . . . . . . . . . . . . . 10

1.3.3. Sistemas de autenticacion de usuarios . . . . . . . . . . . . . . . . . . . . . 13

1.3.4. Sistemas de ficheros en red . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3.5. Servidores de correo electronico . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3.6. Sistemas de monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2. Objetivos 27

2.1. Sistema de instalaciones masivas y desatentidas . . . . . . . . . . . . . . . . . . . . 28

2.2. Sistema de cuentas de usuario y disco en red . . . . . . . . . . . . . . . . . . . . . 28

2.3. Servicios adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4. Monitorizacion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5. Polıticas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6. Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3. Especificacion y Diseno 33

3.1. Metodologıa empleada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2. Analisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1. Proceso de instalacion desatendido . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.2. Cuentas de usuario en red y disco en red . . . . . . . . . . . . . . . . . . . . 35

3.2.3. Servicios de valor anadido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3. Dedicacion de las maquinas fısicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1. Peloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.2. Zipi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.3. Zape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.4. Lechuzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.5. Sapientin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.6. Pantuflo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.7. Espatula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4. Servidores disponibles en el Campus de Fuenlabrada . . . . . . . . . . . . . . . . . 38

3.4.1. Bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4.2. Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

ix

INDICE GENERAL INDICE GENERAL

4. Implantacion 41

4.1. Herramienta de Instalacion Automatica . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1. Servidor DHCP para configuracion automatica de Red . . . . . . . . . . . . 43

4.1.2. Arranque por PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.3. Arranque por red de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.4. Ficheros de preconfiguracion . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2. Protocolos situados en la capa de aplicacion . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1. Servidor LDAP de cuentas de usuario . . . . . . . . . . . . . . . . . . . . . 52

4.2.2. Servidor NFS de ficheros en red . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.2.3. Servidor Web de los Laboratorios . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2.4. Servidor de correo electronico . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.3. Otros servicios disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.3.1. Listas de correo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.3.2. Mirror de Debian y Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.4. Monitorizacion del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.4.1. Monitorizacion de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.4.2. Monitorizacion de estaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.5.1. Limitar los accesos remotos . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.5.2. Auditorıa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.5.3. Deteccion de intrusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.5.4. Ataques de fuerza bruta vıa SSH . . . . . . . . . . . . . . . . . . . . . . . . 100

4.5.5. Seguridad en las contrasenas de los usuarios . . . . . . . . . . . . . . . . . . 102

5. Conclusiones 105

5.1. Logros alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2. Conocimientos adquiridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

A. Scripts de Instalacion Automatica I

A.1. Fichero de preconfiguracion generico . . . . . . . . . . . . . . . . . . . . . . . . . . ii

A.2. Configuracion Isolinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

A.3. Fichero de configuracion del servidor dhcp . . . . . . . . . . . . . . . . . . . . . . vi

B. Scripts adicionales IX

B.1. Scripts de copias de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

B.1.1. De lechuzo a sapientin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

B.1.2. De bilo a nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

B.1.3. De sapientin al disco USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

B.1.4. De nano al disco USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

B.2. Script de copia de seguridad del directorio LDAP . . . . . . . . . . . . . . . . . . . xii

B.3. Auditorıa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

B.3.1. Creacion de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . xii

B.3.2. Insercion de los datos de auditorıa . . . . . . . . . . . . . . . . . . . . . . . xii

B.4. Scripts ssh-a-todos y scp-a-todos . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

B.4.1. Scripts ssh-a-todos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

B.4.2. Scripts scp-a-todos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.5. Script de debilidad de contrasenas . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

x

C. Ficheros de configuracion XXI

C.1. Maquinas zipi y zape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

C.1.1. Servidor LDAP. Fichero slapd.conf . . . . . . . . . . . . . . . . . . . . . . xxii

C.1.2. Servidor DNS. Fichero named.conf y db.pantuflo.es para zipi . . . . . . xxiv

C.1.3. Servidor DNS. Fichero named.conf para zape . . . . . . . . . . . . . . . . xxxi

C.2. Maquina pantuflo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii

C.2.1. Fichero de configuracion de Apache . . . . . . . . . . . . . . . . . . . . . . xxxii

C.2.2. Fichero de configuracion de Postfix . . . . . . . . . . . . . . . . . . . . . . xxxv

C.2.3. Fichero de configuracion de Dovecot . . . . . . . . . . . . . . . . . . . . . xxxviii

C.3. Maquina lechuzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . li

C.4. Maquina peloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lii

C.5. Maquina sapientin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv

C.6. Maquina minervo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv

C.7. Maquina espatula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv

C.8. Maquina bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lv

C.8.1. Servicio NFS en bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvi

C.9. Maquina nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lvi

xi

INDICE GENERAL INDICE GENERAL

xii

Indice de figuras

1.1. Interfaz web de Zabbix. Fuente: Wikipedia . . . . . . . . . . . . . . . . . . . . . . . 231.2. Representacion del uso de memoria en una maquina a traves de Munin. Fuente:

Wikipedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. El proceso de instalacion en Debian/Ubuntu y la preconfiguracion de paquetes. . . 504.2. La raiz del arbol LDAP contiene dos unidades organizativas principales: alumnos

y profesores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3. La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de

Mostoles y alumnos de Fuenlabrada. . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4. La unidad organizativa de profesores contiene dos unidades organizativas que

almacenan los objetos posixAccount y posixGroup. . . . . . . . . . . . . . . . . 564.5. La aplicacion wireshark muestra como se mandan los datos de autenticacion en

claro entre cliente y servidor, con nuestro esquema actual. . . . . . . . . . . . . . . 604.6. Una vez establecida la conexion segura entre cliente y servidor LDAP resulta mas

difıcil capturar datos de autenticacion de usuarios. . . . . . . . . . . . . . . . . . . 624.7. Reparto de carga entre varios servidores LDAP. . . . . . . . . . . . . . . . . . . . . 634.8. La aplicacion PHPLdapAdmin sobre nuestro esquema de servidores. . . . . . . . . 684.9. Pagina principal del Laboratorio de Mostoles . . . . . . . . . . . . . . . . . . . . . 784.10. Autenticacion en la pagina del Laboratorio mediante el directorio LDAP. . . . . . . 804.11. Webmail de pantuflo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.12. Webmail de bilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.13. Gestion de listas de correo en pantuflo con Mailman. . . . . . . . . . . . . . . . . 874.14. La pagina de resumen de estado de Nagios para el Laboratorio de Mostoles. . . . . 934.15. La pagina de problemas de Nagios muestra los problemas en algunas maquinas. . . 934.16. El parte de guerra de Mostoles muestra el estado de las estaciones. . . . . . . . . . 94

xiii

INDICE DE FIGURAS INDICE DE FIGURAS

xiv

Indice de Listados

4.1. Generacion de un CD personalizado de Ubuntu para instalacion automatica . . . . 434.2. Instalacion del paquete dhcp a traves de apt-get . . . . . . . . . . . . . . . . . . 434.3. Fichero de configuracion dpchd.conf. Configuracion de subred. . . . . . . . . . . . 444.4. Fichero de configuracion dpchd.conf. Configuracion de host. . . . . . . . . . . . . 444.5. Instalacion del servicio tfptd-hpa a traves de apt-get . . . . . . . . . . . . . . . . 454.6. Fichero de configuracion /etc/default/tfptd-hpa. . . . . . . . . . . . . . . . . . 454.7. Reinicio del demonio tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.8. Descarga del kernel de arranque por red de Ubuntu Hardy . . . . . . . . . . . . . . 464.9. Fichero de configuracion de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . . . 464.10. Fichero de configuracion de Isolinux . . . . . . . . . . . . . . . . . . . . . . . . . . 474.11. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 474.12. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 474.13. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 484.14. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 484.15. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 494.16. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 494.17. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 494.18. El fichero de preconfiguracion preseed.cfg. . . . . . . . . . . . . . . . . . . . . . . 504.19. Instalacion del paquete slapd a traves de apt-get . . . . . . . . . . . . . . . . . . 514.20. El fichero de plantilla de debconf para el paquete slapd. . . . . . . . . . . . . . . . 514.21. Preconfigurando el paquete slapd. . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.22. Instalacion del paquete slapd a traves de apt-get . . . . . . . . . . . . . . . . . . 524.23. Instalacion de las bibliotecas necesarias para la autenticacion PAM vıa LDAP . . . 564.24. Contenido del fichero nsswitch.conf para autenticacion vıa LDAP . . . . . . . . . 574.25. Contenido del fichero pam ldap.conf para autenticacion vıa LDAP . . . . . . . . 574.26. Contenido del fichero libnss-ldap.conf para autenticacion vıa LDAP . . . . . . . 574.27. Instalacion del conjunto de herramientas migrationtools a traves de apt-get . . 584.28. Modificando registros en el arbol LDAP usando ldapadd . . . . . . . . . . . . . . 584.29. Instalacion del paquete openssl a traves de apt-get . . . . . . . . . . . . . . . . . 604.30. Creacion de un certificado para nuestro servidor LDAP . . . . . . . . . . . . . . . 604.31. Lıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . . . 614.32. Lıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . . . 614.33. Reinicio del demonio slapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.34. Lıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . . . 634.35. Lıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . . . . . . . 644.36. Instalacion del demonio slurpd con apt-get . . . . . . . . . . . . . . . . . . . . . 654.37. Anadiendo replicacion a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . . . 65

xv

INDICE DE LISTADOS INDICE DE LISTADOS

4.38. Anadiendo replicacion a nuestro servidor LDAP . . . . . . . . . . . . . . . . . . . . 66

4.39. Copia de Seguridad de los datos del servidor LDAP . . . . . . . . . . . . . . . . . . 67

4.40. Lınea de cron para automatizar las copias de seguridad de LDAP . . . . . . . . . . 67

4.41. Modificando la contrasena de un usuario usando ldappasswd . . . . . . . . . . . . 69

4.42. Instalacion del servidor NFS a traves de apt-get . . . . . . . . . . . . . . . . . . . 70

4.43. Instalacion del gestor de raid mdadm usando apt-get . . . . . . . . . . . . . . . . 71

4.44. Automatizacion en la creacion del raid . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.45. Automatizacion en la creacion del RAID . . . . . . . . . . . . . . . . . . . . . . . . 72

4.46. Instalacion de Apache y del modulo PHP5 para el servidor . . . . . . . . . . . . 75

4.47. Instalacion del servidor Apache2 y del modulo WebDav/Subversion para elservidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.48. Creacion de un host virtual en Apache para el host pantuflo.escet.urjc.es . . . . 76

4.49. Descarga e Instalacion de la herramienta MediaWiki . . . . . . . . . . . . . . . . 77

4.50. Configuracion de MediaWiki para autenticar usuarios usando LDAP . . . . . . . 79

4.51. Configuracion de Apache para dar soporte a paginas personales de usuarios . . . . 81

4.52. Instalacion de la herramienta postfix usando apt-get . . . . . . . . . . . . . . . . 82

4.53. Instalacion de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo 83

4.54. Reiniciando el demonio dovecot tras su reconfiguracion . . . . . . . . . . . . . . . 84

4.55. Instalacion de mailman usando apt-get . . . . . . . . . . . . . . . . . . . . . . . 88

4.56. Creacion de una nueva lista de mailman usando el comando newlist . . . . . . . 88

4.57. Instalacion de la herramienta debmirror usando apt-get . . . . . . . . . . . . . . 89

4.58. Descargando la replica de Ubuntu usando el comando debmirror . . . . . . . . . 90

4.59. Descargando la replica de Debian usando el comando debmirror . . . . . . . . . . 90

4.60. Contenido del fichero /etc/apt/sources.list usando la replica del Laboratorio . . 90

4.61. Instalacion de la herramienta Nagios con apt-get . . . . . . . . . . . . . . . . . . . 91

4.62. Instalacion de la herramienta Munin (servidor) con apt-get . . . . . . . . . . . . . 93

4.63. Instalacion de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . 94

4.64. Instalacion de la herramienta Munin (cliente) con apt-get . . . . . . . . . . . . . . 94

4.65. Creacion de una tabla en MySQL para almacenar la informacion relativa aauditorıa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.66. Script basico para registrar informacion de auditorıa de usuarios . . . . . . . . . . 98

4.67. Lınea de cron para la automatizacion de la auditorıa de usuarios en el sistema . . . 99

4.68. Monitor de alerta de conexiones nocturnas en el laboratorio . . . . . . . . . . . . . 99

4.69. Intentos de ataque de SSH mediante fuerza bruta o diccionario . . . . . . . . . . . 100

4.70. Instalacion de la herramienta Denyhosts . . . . . . . . . . . . . . . . . . . . . . . 101

A.1. El fichero de preconfiguracion necesario para la instalacion desatendida. . . . . . . ii

A.2. Fichero de configuracion de Isolinux para el arranque por red. . . . . . . . . . . . . v

A.3. Fichero de configuracion de Isolinux para el arranque por red. . . . . . . . . . . . . vi

B.1. Script backup-sapientin.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

B.2. Script backup-nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

B.3. Script backup-usb.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

B.4. Script backup-usb.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

B.5. Script backup-ldap.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

B.6. Creacion de la base de datos de Auditorıa . . . . . . . . . . . . . . . . . . . . . . . xii

B.7. Script who-mostoles.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

B.8. Script sshatodos-alphas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

B.9. Script sshatodos-betas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

B.10.Script sshatodos-gammas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

B.11.Script sshatodos-deltas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

xvi

B.12.Script sshatodos.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.13.Script scpatodos-alphas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.14.Script scpatodos-betas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.15.Script scpatodos-gammas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.16.Script scpatodos-deltas.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

B.17.Script scpatodos.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

B.18.Script john-laboratorio-mostoles . . . . . . . . . . . . . . . . . . . . . . . . . . xv

B.19.Script john-laboratorio-fuenla . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

C.1. Fichero de configuracion /etc/ldap/slapd.conf . . . . . . . . . . . . . . . . . . . xxii

C.2. Fichero de configuracion /etc/bind9/named.conf . . . . . . . . . . . . . . . . . xxiv

C.3. Fichero de configuracion /etc/bind9/db.pantuflo.es . . . . . . . . . . . . . . . . xxvi

C.4. Fichero de configuracion /etc/bind9/named.conf . . . . . . . . . . . . . . . . . xxxi

C.5. Fichero de configuracion /etc/apache2/sites-enabled/pantuflo.es . . . . . . . xxxii

C.6. Fichero de configuracion /etc/apache2/sites-enabled/pantuflo.escet.urjc.es . xxxii

C.7. Fichero de configuracion /etc/apache2/sites-enabled/webmail.pantuflo.es . . xxxiv

C.8. Fichero de configuracion /etc/apache2/sites-enabled/mysql.pantuflo.es . . . xxxiv

C.9. Fichero de configuracion /etc/postfix/main.cf . . . . . . . . . . . . . . . . . . . xxxv

C.10.Fichero de configuracion /etc/postfix/master.cf . . . . . . . . . . . . . . . . . . xxxvi

C.11.Fichero de configuracion /etc/dovecot/dovecot.conf . . . . . . . . . . . . . . . xxxviii

C.12.Fichero de configuracion /etc/exports . . . . . . . . . . . . . . . . . . . . . . . . li

C.13.Fichero de configuracion /etc/postfix/master.cf . . . . . . . . . . . . . . . . . . lii

C.14.Fichero de configuracion /etc/exports . . . . . . . . . . . . . . . . . . . . . . . . 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 terminospueden 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 creditos de la obra de la manera especificada por elautor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan eluso que hace de su obra).

No comercial. No puede utilizar esta obra para fines comerciales.

Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obraderivada, solo puede distribuir la obra generada bajo una licencia identica a esta.

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

1

INDICE DE LISTADOS

Proyecto Fin de Carrera 2 Universidad Rey Juan Carlos

Capıtulo 1Introduccion

El primer capıtulo de este documento resume la motivacion inicial de la realizacion de esteproyecto (el porque se lleva a cabo), ası como la estructura principal del presente documento.Posteriormente, se procede a enumerar cada una de las tecnologıas que se utilizan en el proyecto,incluyendo todas las alternativas que existıan para cada una de ellas (en el apartado Estado delarte). Este capıtulo es meramente introductorio al proyecto desarrollado, dejando los detalles delos objetivos a desarrollar y la implementacion de los mismos para capıtulos posteriores.

3

1.1. MOTIVACION DEL PROYECTO

1.1. Motivacion del proyecto

El presente documento resume casi toda la actividad realizada en un plazo de un anoaproximadamente como administrador de sistemas de los Laboratorios de Linux de la ETSII1

y la ETSIT2, en los Campus de Mostoles y Fuenlabrada, de la Universidad Rey Juan Carlos.Durante el desarrollo de este trabajo, se han completado una serie de hitos que si bien pertenecenal trabajo diario y normal de cualquier administrador de sistemas, puede adaptarse bastante biena la realizacion de un Proyecto Fin de Carrera de una Ingenierıa Informatica, debido a que eldesarrollo diario del trabajo ha sido dividido en fases, al igual que un proyecto: elaborar una lista yanalizar las diferentes alternativas para cada uno de los objetivos, construir una lista de objetivosa desarrollar en un plazo determinado de tiempo, establecer un diseno conveniente y escalable, ypor ultimo, implementar o implantar poco a poco cada uno de los objetivos propuestos.

Por supuesto, un ano da para mucho, para bastante mas que para los hitos que se documentanen la presente memoria. Sin embargo, debido a limitaciones de espacio, nos vemos obligados adocumentar lo estrictamente necesario y lo mas fundamental.

1.2. Estructura de este documento

En esta seccion se indica la division en capıtulos del presente documento, en los cuales serealizara un analisis de cada una de las fases por las cuales ha avanzado el proyecto. Estedocumento se encuentra dividido en cinco capıtulos, a saber:

El capıtulo de Introduccion, en el cual se presentan cual es la motivacion del proyecto yel estado del arte de cada una de las tecnologıas que se han usado en el proyecto.

El capıtulo de Objetivos, en el cual se presentaran los objetivos principales que se han dedesarrollar en el proyecto.

El capıtulo de Diseno,

El capıtulo de Implantacion, en el cual se implementan cada uno de los requisitos de losque consta el proyecto.

El capıtulo de Conclusiones, en el que se realiza un analisis de todos los hitos alcanzados,los conocimientos adquiridos y todo el trabajo futuro que podrıa realizarse para mejorar oterminar de perfilar el trabajo realizado.

Por ultimo, en los Apendices del presente documento, se incluye el codigo fuente(entiendase por codigo fuente en este proyecto todos aquellos ficheros de configuracion yscripts de shell que se han desarrollado) desarrollado en el proyecto.

Junto con el presente documento se adjunta un soporte electronico en CD en el que puedeencontrarse la presente memoria ası como todo el codigo fuente desarrollado en el proyecto.

1.3. Estado del arte

En este apartado vamos a analizar todas aquellas tecnologıas que vamos a tocar en esteproyecto. En este proyecto de hecho, van a ser muchas las tecnologıas, aplicaciones, servidoresy servicios que se van a facilitar a los usuarios de nuestro sistema. Como serıa practicamente

1Escuela Superior de Ingenierıa Informatica2Escuela Tecnica Superior de Ingenierıa de Telecomunicaciones


CAPITULO 1. INTRODUCCION

imposible realizar un analisis del estado del arte de cada una de ellas, nos vamos a centrarsolamente en realizar un breve analisis de los sistemas de instalaciones desatendidos, porun lado, ya que uno de nuestros objetivos primordiales (el que nos llevara mas tiempo)sera la implementacion de un sistema de instalaciones completamente desatendido que nos hagaolvidarnos 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 sistemasLinux, y no hemos caıdo en la cuenta que hoy en dıa existen multitud de distribuciones que ofreceneste grandioso sistema operativo listo para su instalacion. Aunque son pocas las distribuciones quetienen mas fama hoy en dıa, sera necesario enumerar las bondades y defectos de las mas conocidas(principalmente, Debian GNU/Linux, Ubuntu, Red Hat Linux y SuSE). Por ultimo, y dado quenuestro sistema albergara un gran numero de cuentas de usuario, sera tarea obligada decidiracerca de que sistema de cuentas de usuario en red es mas adecuado para nuestras necesidades,y por supuesto, dotar a este sistema de cuentas de un mecanismo de almacenamiento de ficherosadecuado (obviamente, si tenemos un sistema de cuentas en red, el medio de almacenamiento deinformacion debera estar en red tambien).

Por ultimo, y para no extendernos demasiado, realizaremos un breve analisis de lasaplicaciones que dotan de funcionalidad de correo electronico a nuestro sistema (tanto derecogida como de entrega). De esta manera dotaremos a nuestro entorno con la funcionalidadde que los usuarios sean capaces de recibir correo electronico en sus cuentas, y estos tambiensean capaces de poder descargar este correo en sus ordenadores personales. Una vez quetodos estos sistemas se encuentran perfectamente configurados y funcionando, nuestra labor secentrara en la monitorizacion de todos estos servicios. Para ello, instalaremos una herramientade monitorizacion que de cuenta cuando se produce cualquier tipo de problema o caıda de unservicio concreto, alertando a las personas oportunas. Estos herramientas seran discutidas en elapartado Herramientas de monitorizacion.

1.3.1. Distribuciones de Linux

En primer lugar, vamos a realizar un breve repaso por las distribuciones de Linux mas usadashoy en dıa. Cuando hablamos de Linux, en el sentido mas general de la palabra, nos referimos alkernel o nucleo del Sistema Operativo. El kernel de Linux es el mismo para todas las distribuciones(normalmente, mınimamente modificado por la distribucion) y puede ser descargado de formaindependiente desde Internet3 e instalado en cualquier distribucion sin muchas dificultades.

Cuando hablamos de distribucion de Linux nos referimos al conjunto formado por el kernel, lasaplicaciones (que incluya de forma opcional el equipo desarrollador de la distribucion en concreto)junto con un proceso de instalacion. En este sentido, hoy en dıa hay miles de distribuciones deLinux4 que son usadas por millones de usuarios alrededor del mundo. Sin embargo, hay algunasque merecen especial atencion, y que estan clasificadas como las mas usadas o mas populares hoyen dıa. En esta clasificacion, se encuentran Red Hat Linux, SuSE o Debian GNU/Linux.Segun podemos comprobar en el cuadro 1.1, la distribucion mas usada hoy en dıa es Debian(18.84 %), seguida por Ubuntu (16.43 %), SuSE (9.32 %), Slackware (8.35 %) y gentoo (8.07 %),entre otras. Se omite en este resultado el indicado por otras distribuciones mostrado en la tabla.

Es necesario indicar que las estadısticas de uso por distribuciones mostradas en la tabla 1.1se 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 mas usadas (en el

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

A. Gutierrez Mayoral 5 ETSI Informatica

1.3. ESTADO DEL ARTE

Distribucion Uso

CentOS 0.98 %

Kubuntu 1.50 %

Mandriva 2.01 %

Mandrake 4.27 %

Red Hat 6.70 %

Fedora Core 6.93 %

Gentoo 8.07 %

Slackware 8.35 %

SuSE 9.32 %

Ubuntu 16.43 %

Debian GNU/Linux 18.84 %

Others 18.80 %

Cuadro 1.1: Distribuciones mas usadas en la actualidad. Fuente: LinuxCounter

Distribucion Numero de visitas ultimo mes

Ubuntu 1944

openSUSE 1557

Mint 1351

PCLinuxOS 1053

Fedora 1036

Debian 923

Sabayon 853

Mandriva 776

CentOS 629

Gentoo 611

Cuadro 1.2: Distribuciones mas usadas en la actualidad. Fuente: DistroWatch

ultimo mes), colocando tambien a Ubuntu y Debian entre los primeros puestos. En este caso sehan obtenido los datos del portal DistroWatch5. Como vemos, las distribuciones mayoritarias sonDebian GNU/Linux y Ubuntu, seguidas muy de cerca por SuSE, Gentoo y Fedora, entre otras.La decadencia de Red Hat en los ultimos anos queda presente en la estadıstica. La distribucionque hace anos ocupaba los primeros puestos de uso entre los usuarios ha visto comido su terreno afavor de Ubuntu y SuSE. Quiza los cambios en la organizacion interna de Red Hat (que veremosa continuacion) y la aparicion de Ubuntu tuvo como precio la perdida de un gran numero deusuarios.

En definitiva, existen multitud de distribuciones hoy en dıa, de las cuales solo unas cuantasalcanzan los primeros puestos en numero de usuarios y en popularidad. En concreto, en losLaboratorios de Linux de la Universidad se ha usado Debian GNU/Linux desde que comenzo suandadura, hasta hace poco tiempo, que se tomo la decision de pasar a Ubuntu.

A continuacion vamos a realizar un breve repaso por las distribuciones mas usadas omas populares. En concreto, Debian GNU/Linux, como distribucion que usaremos en aquellasmaquinas que presten su funcion de servidor. A continuacion, Ubuntu, distribucion que usaremosen las estaciones de trabajo de los laboratorios. Por ultimo, detallaremos las razones que nosllevan a descartar otras distribuciones como solucion adoptada tanto en los servidores de loslaboratorios como en las estaciones, haciendo hincapie principalmente en las desventajas, ya que

5http://www.distrowatch.com



son propuestas que en un principio se decide descartar.

Debian GNU/Linux

El proyecto Debian surge aproximadamente en el ano 1993, de la mano de Ian Murdock comolıder del proyecto, y con un objetivo principal: crear una distribucion de Linux que separaraclaramente el software libre del no libre. Ademas, el modelo de desarrollo de la distribucion escompletamente ajeno a objetivos empresariales o comerciales, dejando de la mano de los usuariosde la misma la liberacion de las versiones de la distribucion.

En principio, la adaptacion de Debian mas conocida y mas desarrollada hasta la fecha es laque se basa en el nucleo Linux, comunmente llamada Debian GNU/Linux, aunque existenotras ramas de desarrollo basadas en otros nucleos, como Hurd, NetBSD o FreeBSD. El proyectoDebian se rige por unas directrices muy estrictas en cuanto a la organizacion del mismo: uncontrato social establece cual es la base del proyecto y como sus usuarios deben tratar la mayorıade los asuntos, unas directrices de software establecen que software es adecuado o no para ladistribucion, ası como la Constitucion de Debian establece cual es la jerarquıa interna de laorganizacion y como se llevan a cabo y se toman las decisiones principales. Estas normas establecencuales son los poderes principales del lıder del proyecto (el que este vigente en ese momento) ylas responsabilidades de los desarrolladores en general.

Existe una figura visible dentro de la organizacion, el lıder de la misma. Esta figura es elegidapor los propios integrantes de la comunidad Debian (principalmente, desarrolladores) y aunquetiene unas atribuciones principales mas alla de las de cualquier desarrollador, esta lejos de seruna decision absoluta que tengan que acatar el resto de desarrolladores. El lıder de la comunidadse elige una vez al ano, siendo el primero Ian Murdock (ano 1993-1996) y el ultimo (lıder actual)Steve McIntyre (abril 2008-hoy).

Respecto a los detalles tecnicos, cabe resenar que Debian ha conseguido su fama en los ultimosanos, cuando el numero de arquitecturas soportadas se ha elevado considerablemente en losultimos anos, ası como el numero de paquetes incluido por defecto dentro de la distribucion.Actualmente, son soportadas 11 arquitecturas diferentes de hardware en Debian GNU/Linux, yel numero de paquetes se eleva por encima de 18.000. Actualmente, la distribucion se encuentraen la version 4.0 de manera estable (ultima version estable liberada), cuyo nombre en clave sedenomina Etch. Como curiosidad, los nombres de liberacion de las versiones de Debian hacenalusion a personajes de la trilogıa de Disney/Pixar Toy Story, asignandose un nuevo nombrecuando se crea una nueva version de pruebas.

La organizacion de desarrollo de Debian se divide en tres ramas de desarrollo principales: larama estable, la cual es fruto de la congelacion de una rama en pruebas (llega un momento quela estabilidad alcanzada en la rama en pruebas supone que no se anadan ni nuevos paquetes ninueva funcionalidad a la correspondiente rama, creando una nueva version de la distribucion); larama de pruebas o testing, la cual se compone de todos los paquetes que han ido reduciendo sunumero de fallos provenientes de la rama inestable. Por ultimo, la rama inestable, comprende eldesarrrollo activo y principal de la distribucion. En ella se encuentran los paquetes recien anadidosa la distribucion donde se comprueba su estabilidad, el numero de fallos y la integracion con elresto de paquetes de la distribucion. En particular y respecto a las diferentes ramas de desarrollode la distribucion, siempre se recomienda el uso de la rama estable para uso en produccion (debidoa la estabilidad y al nivel de depuracion que ha alcanzado esta version) y al uso de la rama inestablesi se quiere estar mas al dıa en cuanto a versiones de un paquete en concreto, incluido dentrode la distribucion. Sin embargo, usar la rama inestable puede convertirse en un juego peligroso,ya que de un dıa para otro nuestro ordenador puede dejar de funcionar o puede producirse unproblema grave que puede acabar en una reinstalacion si no se tienen los conocimientos necesariospara solucionar el problema y volver a la situacion original. Los usuarios avanzados de Debian



conocen esta situacion y normalmente, siempre que su distribucion se encuentra situada en larama inestable, suelen tener mucho cuidado con las actualizaciones o instalaciones de paquetesnuevos.

Existe dos ventajas principales de la distribucion Debian GNU/Linux sobre la mayorıa dedistribuciones mas usadas hoy en dıa. La principal, es la estabilidad de la rama estable de ladistribucion. La independencia de Debian frente a intereses comerciales hacen que los tiemposde liberacion de la distribucion sean lo suficientemente grandes como para que de tiempo a quela distribucion sea revisada todo lo necesario como para que tenga un nivel de calidad mas queaceptable. Estos tiempos, de un ano normalmente (como mınimo) son excesivos para usuariosque desean tener su software al dıa: ultima version de escritorio, ultima version del servidorweb Apache, etcetera. Sin embargo, estos usuarios deben saber que la rama de desarrollo deDebian que estan usando no es la mas adecuada para ellos, ya que los tiempos de liberacion tangrandes facilitan que la distribucion sea una de las mas estables y seguras frente a otras masconocidas, en detrimento de usar las versiones mas actuales y novedosas en lo que a softwarese refiere. Es por ello que la rama estable de Debian GNU/Linux ha sido relegada al plano delservidor principalmente, dejando otras ramas para el escritorio y el uso menos profesional delequipo en cuestion. La otra ventaja que nos ocupa es la herramienta de instalacion de software, laherramienta apt6. Esta herramienta, muy conocida entre los usuarios de la distribucion y todasaquellas que se apoyan en esta (Knoppix, Ubuntu y demas) facilita enormemente la instalacion,configuracion y eliminacion de software en Debian (y en todas aquellas distribuciones Linux quelo hayan acogido como herramienta de instalacion de software). En principio, esta herramientafunciona en lınea de comandos, aunque ha medida que ha pasado el tiempo se han disenadointerfaces unicos o front-ends que facilitan el uso de la herramienta para usuarios noveles7.

La herramienta apt es capaz de funcionar con repositorios de software a lo largo de Internet,facilitando ası la labor de localizacion de software adicional. De forma oficial, existen repositoriosoficiales para Debian que contienen los paquetes incluidos en la distribucion en cada una de lasramas. Para que este sistema sea escalable, estos repositorios se encuentran replicados a lo largodel mundo en mirrors o espejos locales distribuidos en cada region del planeta. Es comun quecada Universidad cuente con el suyo propio (como es el caso de la nuestra). Ademas, es posibleque los usuarios construyan o creen sus propios repositorios con aquellos paquetes que hayanconstruido particularmente con las aplicaciones que ellos hayan considerado oportuno. El restode usuarios del planeta puede instalar esas aplicaciones sin mas que indicar a la herramientaapt cual es la localizacion del recurso del correspondiente repositorio (normalmente, a travesde una URL comun). El uso de apt es casi una herramienta fundamental en el uso diario delsistema, facilitando la tarea de instalacion de software enormemente, tanto al administrador comoal usuario de a pie. Tanto, que hoy en dıa, la instalacion de software en sistemas Linux a travesde los fuentes (usando el codigo fuente, compilandolo de forma manual) a quedado relegada a unplano muy lejano y casi ya no es usada por los usuarios, tanto por la incomodidad de este metodocomo por el numero de errores que normalmente se suelen producir.

Es por ello que realizamos la eleccion de Debian GNU/Linux como sistema base para nuestrosservidores: la estabilidad de la distribucion en su rama estable para sistemas en produccion haceque nos decantemos por esta opcion, dejando para el escritorio distribuciones que se apoyen enDebian (principalmente, por la estabilidad y las herramientas de instalacion de software) peroque incluyan software mas actual de cara al usuario.

Con el paso del tiempo han sido muchas las distribuciones que han surgido tomando DebianGNU/Linux como distribucion base. La estabilidad y la organizacion de la distribucion haceque muchas distribuciones adopten o partan de ella para crear nuevas distribuciones. Las mas

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



conocidas, Knoppix o Ubuntu, que comentaremos a continuacion.

Ubuntu

Ubuntu8 es una de las distribuciones cuyo cociente entre tiempo y popularidad ha sido maspronunciado. Basada en Debian GNU/Linux como distribucion base, ha ido desplazando a losusuarios mas confesos y acerrimos a la distribucion base hasta Ubuntu como sistema principal deescritorio basado en Linux. Los pilares ideologicos principales en los que se basa Ubuntu son lafacilidad y usabilidad a la hora de usar el sistema operativo, ası como la regularidad en la liberacionde nuevas versiones (normalmente, cada seis meses, en Abril y en Octubre). Esta desarrolladapor Canonical, apoyada por el empresario sudafricano Mark Shuttleworth.

El proyecto surgio en el ano 2004 aproximadamente, con una financiacion de unos diezmillones de dolares. En la distribucion participan muchos desarrolladores de Debian y de Gnome,estos primeros decepcionados con el modo de funcionamiento interno de la distribucion Debian,por aquel entonces una de las mas usadas, tanto en el escritorio como en el servidor. Estosdesarrolladores buscaron apoyo en el empresario Mark Shuttleworth, que aprecio la idea delproyecto y lo apoyo economicamente. Tras varios meses de trabajo y un breve perıodo de pruebas,la primera version de Ubuntu (Warty Warthog) fue lanzada el 20 de octubre de 2004.

Como detalles tecnicos relevantes, podemos destacar que Ubuntu conserva la mayorıa de lasventajas de Debian GNU/Linux, manteniendo como principal la herramienta de instalacion desoftware apt. Ademas, los periodos de liberacion de Ubuntu son bastante mas cortos, lo quehace que las versiones que se incluyen en la distribucion sean bastante actuales. Normalmente,Ubuntu suele incluir la ultima version de los escritorios Gnome y KDE (sino la ultima, una delas mas actuales) ası como las ultimas versiones de los paquetes de software mas importantes.Ubuntu no soporta tanto arquitecturas como Debian: se incluyen de manera oficial soporte parados arquitecturas: Intel x86 y AMD64, sin embargo ha sido portada a mas plataformas de formaextraoficial, la descontinuada PowerPC, Sparc, o incluso la plataforma de videojuegos PlayStation3 creada por Sony.

Ubuntu es una de las distribuciones que incluye un CD Live!, que facilita que el usuario puedaprobar la distribucion sin necesidad de realizar una instalacion en el disco. Esta funcionalidades bastante interesante para poder introducir nuevos usuarios en Linux sin necesidad de realizarnuevas instalaciones en sus sistemas.

Una de las principales ventajas que hacen que nos decantemos por Ubuntu como sistemausado en las estaciones del Laboratorio es que, aparte de ser una distribucion basada en Debian(incluyendo todas sus ventajas, como apt), se incluyen las versiones mas actuales de softwareen cada liberacion, de forma que de cara a los usuarios disponemos de un sistema totalmenteactual, no como pasaba anteriormente cuando las estaciones del Laboratorio se basaban en DebianGNU/Linux: los periodos de liberacion tan largos hacıan que una vez liberada la version estable,las versiones de escritorio, aplicaciones y demas estuvieran totalmente desactualizadas.

Ubuntu al igual que Debian, ha servido como base para otras distribuciones: xUbuntu,kUbuntu o Edubuntu son distribuciones muy usadas en la actualidad y que estan basadas enUbuntu como distribucion base (al igual que Ubuntu se apoya en Debian). Estas distribucionesnormalmente contienen pocas variaciones con respecto a la original, centrandose normalmente enlas aplicaciones incluidas o en el escritorio por defecto que se usa en cada una de ellas.

8http://www.ubuntulinux.org



SuSE

La distribucion SuSE9 es una de las distribuciones Linux mas conocidas y mas usadas en laactualidad. Esta basada en la distribucion Slackware y entre las principales ventajas o virtudesde esta distribucion esta la facilidad de instalacion de la misma (contaba con un instaladorgrafico hace bastante tiempo, cuando ninguna de las distribuciones Linux lo solıan incluir) y unadministrador grafico del equipo llamado Yast, el cual facilita la labor de instalacion de nuevosoftware y la configuracion del equipo. En la actualidad, SuSE es propiedad de Novell, desde quela absorbio en 2004. En el ano 2005, en la LinuxWorld, Novell, siguiendo los pasos de RedHat Inc.,anuncio la liberacion de la distribucion SuSE Linux para que la comunidad fuera la encargadadel desarrollo de esta distribucion, que ahora se denomina openSUSE.

Como detalles tecnicos, SuSE usa el escritorio KDE por omision, aunque incluye tambienel 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 distribucionRed Hat/Fedora. Sin embargo, los cambios que ha sufrido esta distribucion a lo largo del tiempoası como el sistema de gestion de paquetes que usa (RPM) hace que descartemos esta distribucionpara ser usada en nuestro entorno.

Red Hat/Fedora Core

Por ultimo, realizaremos un breve analisis de otra de las distribuciones mas conocidas en laactualidad. La distribucion Red Hat10, posteriormente Fedora, ha sido una de las distribucionesque mas reconocimiento ha tenido en los ultimos tiempos. En principio, existen dos versionesprincipales de esta distribucion: Red Hat Enterprise Linux, dirigida principalmente al mercadoprofesional, y Fedora Core, que surgio en el ano 2003 cuando Red Hat Linux fue descontinuado.Digamos que esta division es similar a la sufrida por SuSE, que mantiene una version comercialde su distribucion (Novell SuSE Enterprise) y su version gratuita, openSuSE. De forma similar,Red Hat ofrece su version comercial (Red Hat Enterprise Linux) y su version gratuita o libre(Fedora).

Red Hat Software Inc. fue fundada en el ano 1994, y es conocida por aportar numerosascontribuciones y luchar en pro del software libre. En esos anos la distribucion contaba con grannumero de usuarios y gran popularidad. Sin embargo, el paso de los anos y la aparicion denuevas distribuciones con mayor estabilidad, mayor numero de usuarios y de desarrolladores laha relegado a un segundo plano, aunque sigue contando con un gran numero de usuarios en laactualidad.

En cuanto al plano tecnico no hay muchos detalles que comentar. Red Hat Linux al igual queSuSE usa el sistema de paquetes RPM, un sistema de paquetes un tanto antiguo en comparacioncon el sistema de paquetes apt. El sistema de paquetes es algo tan fundamental dentro de unadistribucion que es motivo de descartar esta distribucion para su uso en el laboratorio al igualque SuSE.

1.3.2. Sistemas de instalacion desatendidos

Dado que uno de nuestros objetivos principales es disenar un proceso de instalaciondesatendida y completamente automatizado, vamos a analizar los sistemas de instalaciondesatendidos mas usados hoy en dıa por administradores de un numero muy elevado de maquinas.En concreto y para el caso que nos ocupa, partimos de la base que necesitamos un metodo que nospermita instalar en 300 estaciones de usuario aproximadamente (160 en el Campus de Mostoles

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



y 140 en el de Fuenlabrada) de la forma mas rapida y comoda posible, de cara al administradorde las estaciones y de las instalaciones masivas.

Clonacion de disco duro

La clonacion de una particion del disco o del disco duro completo es hoy en dıa uno delos sistemas mas usados a la hora de realizar instalaciones masivas, bien se trate de entornosdocentes o de entornos empresariales, en los que se debe instalar una maquina replica de unamaquina inicial. Este sistema copia bit a bit todos los datos de una particion en un fichero para elposterior volcado a la inversa en otra particion o disco duro. Dependiendo de la aplicacion con laque estemos realizando la clonacion, este proceso sera mas o menos rapido, y nos permitira unamayor flexibilidad a la hora de realizar la clonacion.

Hoy en dıa, las aplicaciones mas modernas que permiten realizar clonaciones de disco duro,permiten:

Lectura de sistemas de ficheros ext2/ext3 (aspecto fundamental en nuestro caso)

Compresion de los datos para que ocupen menos espacio. Los sistemas de clonacion masantiguos requerıan un espacio en disco igual o mayor al del disco duro que se iba a clonar.

Almacenamiento en red de los datos. La imagen del disco duro clonado podıa almacenarseen un servidor FTP, o en un directorio compartido de Windows. Posteriormente, cuando serealizaba el proceso inverso, los datos podıan ser descargados de estos servicios en red.

Clonacion de todo el disco duro o de una particion en concreto. Los sistemas mas modernospermiten elegir entre clonar el disco duro al completo, o solamente una particion del disco.

Rapidez de la clonacion del disco duro o particion. Los sistemas mas antiguos empleabanuna gran cantidad de tiempo para realizar una clonacion de un disco, con el consiguienteperjuicio para el administrador.

Hoy en dıa, existe un gran abanico de aplicaciones con diferentes licencias pensadas pararealizar clonaciones de discos duros o particiones para realizar copias de seguridad de datos,realizar instalaciones masivas, etcetera. Las aplicaciones comerciales mas conocidas hoy en dıapueden ser Acronis True Image11 o Norton Ghost12. Ambas aplicaciones estan disponibles atraves de los servicios informaticos de Campus, con una licencia totalmente funcional para nuestrasnecesidades. Sin embargo, el balance total entre las ventajas y desventajas entre este metodo y elposteriormente elegido como metodo principal de instalacion, hace que nos decantemos finalmentepor el metodo basado en ficheros de preconfiguracion. Existen otras aplicaciones con licenciaslibres que permiten realizar una clonacion de disco duro. En el caso mas basico, el comando ddpermite leer una particion y guardarla en un fichero. Sin embargo, este metodo tan rudimentarioadolece de ser muy lento, a parte de necesitar como mınimo el tamano en disco de la particionpara almacenar el fichero correspondiente.

Entre los dos aplicaciones comerciales presentadas anteriormente, cabe destacar como ventajasprincipales la rapidez y el poco espacio que ocupa la imagen de un disco duro de cualquiera de losequipos que deseemos clonar. Ademas, la aplicacion Acronis True Image nos permite guardarlas imagenes de los discos duros que deseemos en un servidor FTP, con las ventajas que ello supone:cuando deseemos instalar un equipo a partir de una imagen, solamente debemos arrancarlo con elCD de la aplicacion, y seleccionar el servidor FTP donde se encuentran alojadas las imagenes del

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



equipo en cuestion. Este mecanismo puede resultar muy comodo cuando el numero de equipos quese desea instalar es muy bajo: pongamos, quince o veinte equipos, siendo generosos en la pacienciade la persona que vaya a ocuparse de las instalaciones. A mayor numero de equipos, el proceso deinstalacion, puede resultar tedioso. En nuestro caso, disponiendo de 160 estaciones en el Campusde Mostoles y 140 en el Campus de Fuenlabrada, resulta practicamente no asumible. Ademasde esta desventaja principal, hemos de anadir que las diferencias entre las estaciones principalesdel laboratorio supone que se deba almacenar una imagen por cada modelo de estacion, ya quela clonacion asume que esta se realiza entre equipos identicos. En nuestro caso, disponemos enMostoles de 3 tipos principales de hardware en las estaciones de usuario y de tres tipos en elCampus de Fuenlabrada. Es por ello que decidimos plantearnos otros mecanismos de instalaciondesatendida para realizar nuestro proceso de instalacion automatica.

Sin embargo, el metodo de la clonacion de disco nos vendra muy bien cuando tengamos quearreglar un disco que ha sido reemplazado (por ejemplo, por un problema de hardware) o cuandotengamos que instalar pocas maquinas (una o dos) y el resto ya esten instaladas completamente.La razon de esta eleccion es que el metodo de la clonacion es muy rapido, y no supone la puestaen marcha de infraestructura adicional (como es el caso de los ficheros de preconfiguracion, queestudiaremos posteriormente).

En resumen, podrıamos decir que las ventajas y desventajas que aporta este metodo son:

Como ventajas, el metodo de la clonacion es rapido, sencillo y no requiere maquinariaadicional para ponerlo en marcha.

Como desventajas, podemos afirmar que este metodo puede ser complejo en caso de que elnumero de estaciones sea elevado, exige hardware identico (al menos para una sola clonacion)y que realiza una instalacion no limpia del sistema.

Ficheros de preconfiguracion

Por ultimo, vamos a realizar un analisis del uso de ficheros de preconfiguracion pararealizar instalaciones masivas y completamente desatendidas. El metodo de los ficheros depreconfiguracion (el termino anglosajon es preseeds o ficheros semilla). Este metodo, que seencuentra disponible en Debian (y sus derivados) a partir de la version de Sarge, consiste enincluir en un fichero de texto todas las indicaciones necesarias para la instalacion de o bienun sistema Debian completo (fichero de preconfiguracion para el proceso de instalacion) o bienun paquete en concreto. A traves de este metodo, conseguimos que todas las indicaciones opreguntas que el proceso de instalacion realiza al usuario, sean introducidas automaticamente sinnecesidad de la interaccion del usuario en ningun momento en el proceso de instalacion (siempreque todas las respuestas sean introducidas en el fichero correspondiente). El fichero de semillao fichero preconfiguracion es un fichero de texto legible por humanos, en el que se incluyen lapreconfiguracion de cada pregunta en un formato concreto. Este formato, si bien no es a prioripuede resultar un tanto complejo, es bastante automatico en cuanto a la forma de construirindicaciones para un proceso de instalacion. Cada indicacion se incluye en una lınea del ficherode texto, y contiene una especificacion en la forma clave/valor para cada paquete a instalar,incluido el proceso de instalacion (el proceso debian installer).

Una de las ventajas principales de este metodo radica en que se puede automatizar todo elproceso de instalacion al completo, sin mas que responder o incluir todas las indicaciones en elfichero de preconfiguracion correspondiente. Ademas, estaremos realizando una instalacion limpiade un sistema (a diferencia del procedimiento de la clonacion de una particion o del disco duro).Esta instalacion sin duda es mas conveniente para el sistema que replicar una instalacion yahecha. Por otra parte, los ficheros de preconfiguracion son muy flexibles en el sentido que pueden



estar almacenados en un CD ya prefabricado (un CD de Debian en el que se ha modificado elarranque) o bien se pueden incluir en una memoria USB o incluso en la red, localizadas por unaURL. Este metodo es especialmente potente y flexible, ya que facilita que el sistema pueda serinstalado completamente por la red, sin necesitar tan siquiera un CD de Debian para realizar lainstalacion. Solamente necesitaremos la imagen correspondiente del arranque por red de la versioncorrespondiente que queramos instalar (disponible en cualquiera de los mirrors de Debian) y unaspequenas modificaciones en el arranque para que este use un fichero de preconfiguracion. Unavez hecho esto, tendremos un proceso de instalacion que no necesita soporte de instalacion (unCD, como tradicionalmente se ha instalado el Sistema Operativo) ni ninguna interaccion con elusuario: tan solo sera necesario reiniciar el equipo y seleccionar arranque por red en la placabase para que el proceso comience, se instale correctamente y cuando haya finalizado el proceso,el equipo se reinicie y muestre el nuevo sistema al usuario. Como vemos, la idea es bastanteatractiva: tan solo requiere reiniciar el equipo para realizar una instalacion.

En el capıtulo Implantacion veremos los detalles tecnicos de este proceso, que si bien norequiere tan solo de fichero de preconfiguracion en cuestion (es necesario otras tecnologıasparalelas, como arranque por red de Linux, puesta en marcha de un servidor que despachedirecciones IP, etcetera) no es complicado en exceso. Podemos resumir que el proceso deinstalacion tiene las siguientes ventajas y desventajas principales:

Como ventaja, principalmente es la escasa interaccion con el usuario que necesita (porno decir nula). La unica accion que se requiere por parte del usuario es reiniciar el equipopara que comience la instalacion (y esta accion no pertenece propiamente al proceso deinstalacion). La instalacion del sistema es totalmente limpia (se formatea el disco duro, secrea la tabla de particiones, se instala el sistema completo partiendo de cero, se configurantodos los paquetes una vez este se ha instalado, etcetera), lo cual es una ventaja con respectoal metodo de la clonacion. Por ultimo el poder realizar instalaciones por red es una ventajabastante importante, en los tiempos en los que nos encontramos, en el que el uso de soportesde almacenamiento fısicos cada vez esta menos extendido.

Como desventaja, podemos indicar que si bien este proceso es muy usado hoy en dıa porparte de administradores de sistemas, la documentacion del metodo de preconfiguraciones bastante escasa, por no decir nula. Si bien ya empiezan a existir proyectos deDebian dedicados unicamente a esta labor13, hace un ano aproximadamente resultababastante complicado encontrar recetas de instalaciones desatendidas usando ficheros depreconfiguracion. Tambien cabe resenar que el metodo de ficheros de preconfiguracion suelerequerir la puesta en marcha y configuracion de tecnologıas paralelas que no tienen que vermucho con el proceso de instalacion, como veremos en el capıtulo Implantacion.

1.3.3. Sistemas de autenticacion de usuarios

Otro de los puntos que es necesario debatir es el diseno e implantacion de un sistema deautenticacion de usuarios, necesario para que los alumnos puedan iniciar su sesion en las estacionesdel Laboratorio. En este sentido, sera necesario analizar las tecnologıas actuales que brindan unsistema de usuarios en red que proporcione la infraestructura necesaria para que una persona,en posesion de su nombre de usuario y contrasena pueda iniciar una sesion, independientementedel ordenador en el que se encuentre en ese momento (de ahı que sea un sistema de usuariosen red). En este sentido, vamos a estudiar tres sistemas de autenticacion principales. El primerode ellos, es el mas rudimentario, basandose en el sistema tradicional de ficheros /etc/passwd y/etc/shadow con replicacion ante cambios.

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



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

Mapa de usuarios local con replicacion

La primera solucion que nos planteamos es la implantacion de un mecanismo de autenticacionbasado en un mapa de usuarios locales que se replique a lo largo de todas las maquinas quecomponen el laboratorio. El funcionamiento de este mecanismo por tanto, serıa el funcionamientoclasico basado en los ficheros /etc/shadow y /etc/passwd superponiendo por encima unmecanismo que permita replicar estos ficheros en todas las estaciones que componen nuestroentorno.

Este mecanismo de replicacion se puede llevar a cabo de muy diferentes maneras. Por ejemplo,implementando un monitor que sondee los cambios en ambos ficheros en una maquina concreta(en la que se producen los cambios, por ejemplo) y vaya propagando estos cambios entre aquellasmaquinas interesadas. Esta replicacion se puede llevar a cabo mediante una transmision simplede ficheros usando SSH (usando el comando SCP, por ejemplo).

Otra decision a tomar serıa si los cambios lo solicitan los clientes, o es una unica maquina la quepropaga los cambios cuando estos se produzcan. En cualquier caso, estas decisiones pertenecen almecanismo de propagacion de cambios que este mecanismo incorporarıa. Lo fundamental de estemecanismo es comprender que los mecanismos para anadir y borrar usuarios, ası como cambiaruna contrasena, por ejemplo, son los mismos que en un sistema Linux/Unix tradicional (al basarseen los ficheros tradicionales de usuarios de cualquier sistema Unix).

Sin embargo, este sistema adolece de muchos problemas para ser llevado a la practica. Comodesventaja principal, la escalabilidad del sistema, que se puede convertir en insostenible. Si elnumero de maquinas es relativamente alto, la propagacion de cambios puede convertirse en unverdadero problema, cuando anadamos muchas cuentas en muy poco tiempo, o simplementerealicemos un cambio en los datos de los usuarios, a parte de convertirse en un cuello de botella.

Ademas, si elegimos un diseno en el que solo se pudieran modificar datos en una sola maquina,nos deberıamos preguntar que pasarıa si un usuario decide cambiar su contrasena (una accionbastante frecuente). ¿Deberıa iniciar una sesion en esa maquina y entonces cambiar la contrasena?¿Deberıa poder cambiar la contrasena en la maquina en la que se encuentra, y que esta informaraa la maquina maestra de que se ha producido un cambio? Como vemos, la accion mas simple quepuede darse en un esquema de cuentas en red, como cambiar una contrasena, puede convertirse enalgo bastante complicado usando este esquema. Sin embargo, anadir y borrar cuentas, ası comocambiar una contrasena en la maquina maestra es extremadamente simple, usando directamentecomandos del sistema para realizarlo (eso sı, siempre que sea el administrador el que realice estoscambios). Debido a que el numero de pros es mayor a las ventajas que puede ofrecernos estatecnologıa, en principio decidimos estudiar otras alternativas para nuestro diseno de cuentas enred. Sin embargo y como resena, cabe destacar las ventajas y desventajas de la citada tecnologıa:

Como ventaja, podemos decir que un sistema de usuarios locales con replicacion opropagacion de cambios es bastante simple para anadir y borrar usuarios, ası como paracambiar contrasenas, ya que siempre se usan los comandos estandar del sistema para estalabor (siempre y cuando los realice un administrador o un usuario con privilegios).

Como desventaja podrıamos destacar que se producen un gran problema de escalabilidaden este diseno, ademas de tener que disenar un sistema completo de propagacion de cambiosque sea lo suficientemente bueno como para asumir el volumen de datos de cuentas que nos



proponemos. Ademas, este diseno tiene serios problemas de concurrencia, que pueden darsecuando dos administradores realicen modificaciones en la cuenta de un usuario.

NIS

Las paginas amarillas NIS14, tambien llamadas Sun Yellow Pages es una tecnologıa decuentas de usuario en red (aunque tambien puede ser usado para otros menesteres), desarrolladaprincipalmente por Sun Microsystems en los anos de los 90.

Esta tecnologıa es la que inicialmente se usaba en los Laboratorios de Linux de la Universidadantes de evaluar soluciones mas avanzadas de cara al aumento tanto de estaciones instaladas enlos Laboratorios como de usuarios en posesion de una cuenta.

La tecnologıa NIS se basa en llamadas RPC entre cliente y servidor para el intercambio deinformacion sobre usuarios en sistemas distribuidos, tales como el que nos ocupa. El software queimplementa tal funcionalidad se compone de un servidor, una biblioteca para el lado del cliente yvarias herramientas de administracion. En concreto NIS funciona de tal forma que la informacioncontenida en los ficheros /etc/passwd, /etc/shadow y /etc/group se puede distribuir a lolargo de una LAN de tal forma que el efecto es como si los citados ficheros fueran locales a lamaquina en la que nos encontramos. En cierto modo, el funcionamiento es muy similar a tenerun fichero /etc/passwd, /etc/shadow locales, ya que las herramientas para anadir y borrarusuarios ası como cambiar una contrasena son las estandares de Unix, con la unica excepcionque ha de realizarse en el servidor que proporciona la informacion NIS. En el resto de hosts esnecesario realizar llamadas RPC para realizar consultas sobre los datos de los usuarios.

En particular este esquema es bastante simple, y muy funcional: estuvo funcionandoperfectamente durante aproximadamente 5 anos en los Laboratorios sin muchos problemas. Encuanto a requerimientos tecnicos, solamente se necesita un servidor que almacene la informacionde los usuarios, y conocimientos basicos de administracion de usuarios en sistemas Unix. Conesto, es suficiente para poder construir un sistema de cuentas en red basado en NIS.

Sin embargo, hay dos problemas fundamentales para este esquema, que desarrollamos acontinuacion:

La escalabilidad unicamente hay un servidor NIS de cuentas de usuario con todo lo queello conlleva: proteccion ante fallos, cuellos de botella, etcetera. Sin embargo, cabe destacarque en los anos que esta solucion estuvo implantada en los Laboratorios, no se produjeron enningun momento cuellos de botella significativos, ante un laboratorio de aproximadamente90 estaciones de trabajo, lo que deducimos que se debe a lo ligero del protocolo, entre otrascosas. Por tanto, lo mas preocupante es la proteccion ante fallos y caıdas repentinas delservidor que puedan producirse en cualquier momento.

La seguridad de los datos en la red. Usando esta solucion, los datos de los usuarios viajan enclaro por la red, con todo lo que ello conlleva. La informacion relativa al nombre de usuario,directorio personal de los mismos viaja totalmente en claro, y las contrasenas de las cuentasviajan cifradas con un mecanismo de cifrado simetrico, con lo que el romper este cifradoes bastante sencillo. Hoy en dıa no podemos asumir que esto ocurra. Cualquier usuariomalicioso que pueda ponerse entre medias de un cliente y del servidor NIS podra captardatos de cualquier usuario del sistema. Se hace necesario por tanto anadir un mecanismoque cifre los datos de los usuarios cuando estos viajan entre cliente y servidor, mecanismoque a dıa de hoy no posee la tecnologıa NIS de Sun.

14NIS son las iniciales de Network Information Service



Por tanto, debido a estas principales desventajas y a ser un producto tecnologicamentedesfasado, nos vemos obligados a estudiar otras tecnologıas para llevar a cabo el sistema deusuarios en red.

LDAP

Por ultimo, nos planteamos el estudio de una solucion basada en directorio, usando para elloel estandar LDAP15. LDAP es una tecnologıa de reciente aparicion que gestiona un directorio enuna base de datos que puede servir en principio para dar servicio a muy dispares aplicaciones,aunque sin duda, una de las mas usadas hoy en dıa es la autenticacion de usuarios ya sea ensistemas operativos tipo Unix (como el que nos ocupa) o maquinas Windows (a traves de lacreacion de cuentas Samba).

En nuestro caso, solamente usaremos el directorio LDAP para la autenticacion de usuariosen maquinas Unix. Aunque una vez puesto en marcha el servicio, se puede utilizar para muydiversos fines (aparte del descrito) como por ejemplo, la informacion de hosts en la red, o comoservicio de libreta de direcciones. Como tal, LDAP es un estandar detallado como tal en la RFC16

correspondiente17.

Habitualmente, un servidor LDAP almacena informacion de un usuario de la red, tal como sunombre de usuario y su contrasena, aunque puede incluir informacion adicional como nombre dela persona, ubicacion fısica, foto personal, etcetera. En definitiva, podemos afirmar que LDAP esun protocolo de acceso unificado a un conjunto de informacion sobre una red.

En nuestro caso vamos a utilizar este servicio para almacenar la informacion de las cuentasde usuario del sistema, particularmente y como informacion fundamental, su nombre de usuarioy contrasena. Aunque por supuesto, tambien sera necesario almacenar otro tipo de informacion,como el nombre y apellidos del usuario en cuestion, correo electronico, etcetera. La tecnologıaLDAP como tal y dado a que unicamente describe un protocolo, es implementada por numerosasaplicaciones con muy diferentes licencias. Los gigantes informaticos han querido hacer suya estatecnologıa y han liberado aplicaciones que implementa de forma muy diferente (y con unosnombres muy diferentes) un servicio de directorio basado en LDAP. En concreto, Microsoftdistribuye la aplicacion Active Directory, bajo la cual se almacena informacion de usuarios,recursos de la red, polıticas de seguridad, configuracion, y asignacion de permisos, entre otrascosas, en entornos de redes Windows. Ni que decir tiene que se trata de una solucion comercialy por tanto, de pago, por lo que para nosotros queda descartada automaticamente, debido a lanaturaleza del entorno en el que nos encontramos.

Otro producto muy similar es el liberado por Novell, Novell Directory Services. Esta aplicaciones la implementacion de Novell utilizada para manejar el acceso a recursos en diferentes servidoresy computadoras de una red en la que se representan como objetos los servicios mas usuales en unared, como una impresora, una estacion, un servidor, un servicio, una persona, etcetera. Una vezdefinidos los objetos en la base de datos, se asignan los permisos para el control de acceso. Dadoque esta solucion tambien es una solucion comercial, no nos planteamos abordarla en nuestrosobjetivos.

Por ultimo, la aplicacion OpenLDAP es una implementacion del protocolo LDAP basadaen el concepto de software libre desarrollada por el proyecto OpenLDAP, que comienzaaproximadamente en el ano 1998. Esta implementacion del estandar LDAP, esta incluida en lamayorıa de distribuciones Linux mas usadas hoy en dıa (por supuesto se encuentra en las basadasen Debian GNU/Linux, como Ubuntu). La implementacion incluye un servidor (llamado slapd),

15LDAP son las siglas de Lightweight Directory Access Protocol o Protocolo ligero de acceso a directorio16RFC son las siglas de Request for comments y es un documento tecnico que describe el comportamiento de un

protocolo de red.17http://www.faqs.org/rfcs/rfc2251.html es la RFC de LDAP en su version 3.



un demonio de replicacion de datos (llamado slurpd) y una serie de bibliotecas que implementanel estandar LDAP. Ademas, esta implementacion soporta multiples esquemas de datos, entre losque se encuentran los necesarios para representar una cuenta en un sistema Unix y un grupo, porlo que nos sirve para representar la informacion de cuentas de los usuarios del sistema.

Ademas de todo lo descrito hasta ahora, OpenLDAP dispone de multitud de aspectosavanzados que lo convierten en una solucion bastante factible a la hora de decantarse por unsistema de cuentas en red, particularmente,

La posibilidad de anadir replicacion de datos entre servidores OpenLDAP : Como veremosposteriormente en el capıtulo Implantacion, es posible disenar un esquema de servidoresmaestros-esclavos de tal forma que exista tolerancia ante fallos de red o de suministroelectrico, ademas del consiguiente reparto de carga.

Reparto de carga entre diferentes servidores LDAP: Del lado del cliente, es posible repartirlas peticiones de informacion sobre diferentes servidores LDAP. Esto es especialmenteinteresante en un entorno en el que nos encontramos, en el que existe un gran numerode usuarios y de estaciones que van a realizar peticiones sobre el servidor LDAP. Veremosmas adelante como podemos llevar este diseno a cabo y cuales son las ventajas que nosproporciona.

Cifrado de datos entre cliente y servidor: OpenLDAP nos brinda la posibilidad de asegurarlas conexiones entre el servidor y los diferentes clientes que vayan a realizar peticionesde autenticacion o solicitud de informacion sobre el mismo. Para ello, se utilizaranlas bibliotecas SSL de cifrado de informacion entre ambos extremos, que aseguraranconfidencialidad y privacidad de los datos de los usuarios que viajen en la red. Esteaspecto es fundamental y es un requisito crıtico en el entorno en el que nos encontramos.

Debido a estas razones, LDAP se convierte hoy en dıa en un estandar de facto a la horade implementar un sistema de autenticacion de usuarios en red y sera la opcion elegida para laconstruccion de nuestro servicio de autenticacion de usuarios en red.

1.3.4. Sistemas de ficheros en red

Dado que estamos trabajando con un entorno de red basado en estaciones de trabajo enlas que los usuarios pueden iniciar su sesion y trabajar con un conjunto de ficheros (a los quellamaremos directorio personal de usuario o ficheros de usuario) es necesario implantar un sistemade ficheros en red que sea capaz de dotar al entorno de un servicio de ficheros en red que permitaa los usuarios poder usar sus ficheros independientemente de la estacion en la que se encuentrentrabajando.

En este sentido, no existen muchas alternativas para poder implementar esta funcionalidaddentro de un sistema operativo Linux o Unix. Una de las mas conocidas y la mas usada porexcelencia, es el sistema de ficheros en red NFS18. En los ultimos anos se ha extendido unaalternativa a esta opcion, el sistema de ficheros usado en comparticiones con sistemas operativosWindows. Esta solucion suele ser adoptada en entornos hıbridos en los que se trabaja tanto consistemas Unix/Linux como con sistemas Windows. En principio no es nuestro caso y por tantooptaremos por no implantar tal sistema, aunque su analisis resulta interesante por si en algunmomento es necesario plantear la posibilidad de instalar sistemas Windows en el Laboratorio anteel requerimiento de software docente de alguna asignatura.

Cabe resenar que aunque son sistemas de ficheros en principio muy diferentes, las dos opcionespueden funcionar perfectamente en conjuncion: si un host arranca un sistema operativo Windows,

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



usara el sistema de ficheros en red que facilite el servidor Samba, y si arranca el sistema operativoLinux o cualquier otro basado en Unix, usara el analogo basado en NFS. Por tanto, los directoriosseran lo mismo, simplemente la manera de servirlos sera diferente: en un caso se usara el sistemade ficheros para comparticiones Windows (Samba) y en otro, para sistemas Linux (NFS).

NFS

El sistema de ficheros NFS (Sistema de ficheros en red) es un protocolo a nivel de aplicacionsegun el modelo OSI). Este sistema de ficheros en red es muy usado en entornos de red en el quese trabaja con un modelo distribuido de estaciones de trabajo que necesitan acceder a un mismodirectorio que se encuentra alojado en un servidor (como el caso que nos ocupa). Esto posibilitaque las estaciones de trabajo puedan acceder a este directorio como si de un directorio local setratara.

Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que fueraindependiente del Sistema Operativo, y el protocolo de transporte. Esto fue posible ya que fueimplementando bajo los protocolos XDR y ONC-RPC. El conjunto de aplicaciones que haceposible el uso del protocolo NFS suele estar incluido por defecto en la mayorıa de las distribucionesLinux actuales. El sistema NFS suele estar compuesto de un servidor, y uno o mas clientes. Losclientes acceden de forma remota a los directorios ofrecidos o exportados por el servidor, donde seencuentran almacenados los datos. De esta forma, los usuarios de nuestro sistema no necesitarandisponer de un directorio HOME (el directorio personal de usuario en un sistema Linux) en cadauna de las estaciones Linux en las que inicien su sesion, sino que todos los directorios HOME seencontraran en el servidor de ficheros NFS y los usuarios importaran o montaran (termino muyusado en sistemas Linux que hace suele hacer alusion a empezar a usar un sistema de ficheros)este directorio en la estacion de trabajo en la que se encuentren.

No es objetivo de esta seccion enumerar los aspectos tecnicos del protocolo, ya que estos seencuentran descritos en la RFCs correspondientes19. Las pruebas que se han llevado a cabo enel entorno demuestran que este protocolo resuelve bastante bien la tarea de servir un directorioHOME a todas las estaciones del Laboratorio (unas 160 aproximadamente) sin que se produzcanretardos excesivos en las comunicaciones o cuellos de botella. De hecho, solamente es una solamaquina es la que lleva a cabo esta tarea, sin que sea necesario la division del servicio para suescalabilidad.

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 queconforman nuestra red de area local (y por tanto no es necesario servir a traves de un sistema deficheros de Windows los directorios personales de los usuarios) sera la solucion que adoptemos enel entorno que nos ocupa.

Samba

Samba es una implementacion de software libre del protocolo de archivos compartidos deWindows para sistemas operativos tipo Unix/Linux. Antiguamente recibıa el nombre SMB, perofue renombrado recientemente a CIFS. Gracias a esta implementacion es posible que ordenadorescon Linux, MacOS o cualquier Unix en general sean capaces de servir o ser clientes de ficherosen redes Windows. Samba tambien permite validar usuarios haciendo las labores de ControladorPrincipal de Dominio (PDC), como miembro de dominio o incluso como un dominio de DirectorioActivo (Active Directory) para redes basadas en Windows, aparte de ser capaz de servir colas deimpresion, directorios compartidos y autenticar con su propio archivo de usuarios.

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



Entre los sistemas tipo Unix en los que se puede ejecutar Samba, estan las distribucionesGNU/Linux, Solaris y las diferentes variantes BSD entre las que podemos encontrar el Mac OSX Server de Apple. Dado que en nuestra red no se van a alojar hosts con sistemas operativosWindows, descartamos esta opcion, aunque es interesante analizarla por si en un futuro no muylejano es necesario instalar Windows para la docencia de alguna asignatura del Departamento.

1.3.5. Servidores de correo electronico

Dotar al entorno de un sistema de gestion del correo electronico nos brinda unacantidad enorme de nuevas funcionalidades. Sin entrar aun en cuales pueden ser estas nuevasfuncionalidades, es necesario indicar que bajo el punto de vista de organizacion independientedentro de la Universidad, no se disponen a priori datos de los alumnos, entre ellos, los datosnecesarios para poder contactar con ellos en caso de que sea necesario. A menos que usemos elcorreo electronico que se usa por defecto sobre cualquier maquina Unix. Es por esta razon quedebemos instaurar un mecanismo que nos permita entrar en contacto con los alumnos, para poderindicarles en un momento determinado cualquier incidencia con su cuenta de usuario. Ademas,este mecanismo tambien puede ser usado para otros menesteres, entre ellos, enviar al alumnolas notas de sus examenes parciales, noticias acerca del funcionamiento interno del Laboratorio,etcetera.

Para ello, se decide la implantacion de un sistema de transporte de correo (MTA) que asumalas funciones de recogida de correo electronico bajo los dominios de cada uno de los campus enlos que disponemos de un Laboratorio de Linux (Mostoles y Fuenlabrada) y que facilite de unbuzon de correo electronico a los usuarios. Ademas, como posteriormente veremos en el capıtulode Implantacion, instalaremos un servidor de recogida de correo (para que los usuarios seancapaces de recoger su correo electronico usando un gestor como Outlook, Evolution, Eudora,etcetera) y un webmail, que facilitara que todos aquellos usuarios que no quieran o no puedanrecoger su correo electronico usando un gestor, lo puedan consultar en el web. En el capıtuloImplantacion se detallara mas ampliamente este mecanismo. A continuacion vamos a enumerarlas alternativas mas frecuentes y mas conocidas en lo que a servidores o agentes de correo serefiere. Por un lado, es necesaria la instalacion de un agente de correo o Mail Transport Agente,que se encargue de la recogida de todo el correo que llega a cada uno de los servidores: de este lado,analizaremos los servidores mas comunmente usados en este sentido: Postfix y Sendmail. Unavez completada esta tarea, sera necesaria la instalacion del citado servidor de recogida de correo.Estos servidores, suelen operar bajo los protocolos POP y/o IMAP (siempre bajo conexionesseguras, usando SSL o TLS). En este sentido, hemos citado dos de los servidores mas conocidos yusados en la actualidad: Courier y Dovecot (aunque por supuesto, existen muchos mas). Caberesenar que las pretensiones de estos servidores no van mas alla que la simple entrega y recogidade 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 opcion u otra, nos centraremos basicamente enla facilidad de instalacion de cada herramienta.

Sendmail

Sendmail a dıa de hoy es uno de los proyectos mas conocidos dentro del Software Libre.Sendmail es un Agente de Transporte de correo, o MTA (Mail Transport Agent). Esta aplicacionse encarga de encaminar los mensajes de correo electronico en Internet para que lleguen a sudestino. Se afirma que Sendmail es uno de los principales encaminadores de todo el traficode correo electronico en la Internet mundial, de ahı la importancia de este agente de correoelectronico. Comenzaba su andadura cuando la Internet moderna comenzaba sus pasos, de ahı queuna de las principales dolencias de Sendmail sea uno de los aspectos que en principio no era un



problema cuando Internet comenzaba sus pasos: la seguridad. Segun los principales detractores deesta herramienta adolece de numerosas fallas de seguridad (muchas descubiertas y documentadas,y quien sabe las que tiene por descubrir), aunque normalmente estan son arregladas a las pocashoras de ser notificadas.

Otro de los principales problemas de los que adolece Sendmail es de su configuracion. Mientrasla mayorıa de los servidores de recogida de correo tienen ficheros de configuracion legibles porhumanos (human-readables) los propios desarrolladores de Sendmail afirman que los ficheros deconfiguracion de la herramienta no cumplen esta condicion, y recomiendan al administrador desistemas encargado de configurar esta tediosa herramienta el aprender un lenguaje basado enmacros para la configuracion de la misma (M420).

Ademas de soportar evidentemente el protocolo SMTP de correo electronico, Sendmail dasoporte a una gran variedad de protocolos de correo electronico, como ESMTP, DECnet’s mail11,HylaFax, QuickPage o UUCP. Como vemos, Sendmail es una aplicacion con una funcionalidadbastante extensa para nuestros propositos, que dificulta su configuracion enormemente, por lo queen un principio sera descartada en favor de una aplicacion que aunque con menor funcionalidad,sea mas sencilla y rapida de configurar.

Postfix

Al igual que Sendmail, Postfix21 es un agente de transporte de correo (MTA) que encaminalos mensajes de correo electronico desde el origen hasta el destinatario. Actualmente, Postfixse encuentra en su version estable 2.5, liberada aproximadamente en Enero de 2008. Postfixsurgio como principal alternativa a Sendmail: se buscaba un gestor de correo electronico seguro,facil de administrar y cuya instalacion no supusiera un quebradero de cabeza para muchosadministradores de sistemas a lo largo de toda Internet.

Con este objetivo, Thomas J. Watson desarrollo las primeras versiones de Postfix,antiguamente conocido como VMailer y IBM Secure Mailer. Postfix es el sistema gestor de correopredefinido en muchas distribuciones de Linux (por ejemplo Ubuntu), y en las ultimas versionesdel sistema operativo de Apple (Mac OS Tiger y Leopard).

Respecto a los detalles tecnicos, el codigo fuente de Postfix suele ser citado como ejemplo debuena practica de programacion. Aparte de este detalle, Postfix posee muchas funcionalidadesque hoy en dıa son casi primordiales a la hora de configurar cualquier servidor de correo: soportepara comunicaciones seguras (usando la capa de seguridad TLS), capacidad de filtrar el correomediante listas grises, uso de diferentes bases de datos para obtener fuentes de usuarios, dominiosetcetera (entre ellas, MySQL, PostgreSQL, LDAP, bases de datos Berkeley, etcetera), soporte deformato mbox y Maildir para almacenar los mensajes de correo, etcetera. Como se puede observar,la funcionalidad de este gestor de correo es bastante extensa, lo que puede incitar a pensar que suconfiguracion puede ser incluso mas complicada que la de su principal rival, Sendmail. Nada maslejos de la realidad. La instalacion y configuracion de Postfix se realiza en apenas tres pasos, sinmas que indicar si se desea instalar un gestor de correo que reciba correo de Internet, el dominiopara el que se desea recoger correo y poco mas. Por supuesto, si la configuracion es mas extensa,se deberan personalizar los ficheros de configuracion al gusto, para conseguir la configuraciondeseada segun las necesidades de cada administrador. No obstante, los ficheros de configuracionde Postfix son bastante sencillos de asimilar (principalmente la configuracion se realiza editandoun unico fichero, el fichero /etc/postfix/main.cf) y la configuracion avanzada no resulta muycomplicada, existiendo gran documentacion en Internet y configuraciones estandar ya escritaspara la mayorıa de los supuestos casos que nos podemos encontrar.

20M4 es un procesador de macros de proposito general, desarrollado por Brian Kernighan y Dennis Ritchie.21http://www.postfix.org/



Debido a la rapidez de la instalacion de esta herramienta y su posterior configuracion (paranuestros requerimientos, la configuracion estandar es mas que necesaria) sera el gestor de correoque elijamos como agente de transporte de correo para el Laboratorio, frente a su principalcompetidor (Sendmail). En el capıtulo Implantacion estudiaremos mas en detalle la configuracionque 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 usuariosdeben poder leer su correo de una forma eficiente. En este sentido, sera necesario instalar yconfigurar un servicio de recogida de correo. Estos servicios facilitan a los usuarios la descargadel correo electronico usando un gestor de correo electronico para el escritorio, como por ejemploOutlook (para Windows), Eudora, Mozilla Thunderbird, Evolution, etcetera. A traves de estosgestores los usuarios podran descargar el correo del Laboratorio sin necesidad de tener queconectarse al servidor para leerlo en el terminal, algo engorroso en algunos casos.

Para ello, nos planteamos la instalacion de alguna herramienta que facilite este servicio. Hoyen dıa, los mas usados en la distribuciones Linux que vamos a usar como principales (Debian yUbuntu) son Courier y Dovecot, que repasaremos a continuacion.

Courier Mail Server, o comunmente llamado Courier, tambien es un agente de transportede correo MTA que facilita la operacion de los protocolos POP e IMAP para la recogida decorreo. Estos protocolos son los que facilitan que los gestores de correo e informacion personalespuedan conectarse al servidor y descargar el correo electronico a cada uno de los ordenadores delos usuarios. Ademas, Courier puede funcionar como gestor de correo electronico (como Postfix ySendmail) 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 necesarioinstalar los paquetes courier-pop-ssl, courier-imap-ssl para anadir soporte POP e IMAPusando una conexion segura).

La instalacion de Courier se divide en aquellos elementos que se desea instalar, segun elprotocolo ofrecido al usuario (POP, IMAP, POP bajo SSL, etcetera) existiendo un paquete paracada funcionalidad. La configuracion de Courier es algo compleja para nuestras necesidades, porlo que en principio, nos decantaremos por una opcion mas sencilla de instalar y configurar, comoes Dovecot, un servidor POP e IMAP muy sencillo de configurar.

Dovecot

La labor fundamental de Dovecot22 es la de facilitar el acceso a los buzones de correo mediantelos protocolos POP3 e IMAP (pudiendo usar tambien una conexion segura, es decir, POP3s eIMAPs). Esta aplicacion ha sido escrita principalmente por Timo Sirainen y fue liberada porprimera vez en 2002, por lo que despues de seis anos podemos afirmar que la herramienta seencuentra lo suficientemente madura como para ser usada en produccion (la ultima version es la1.1.2 que fue liberada en Julio de 2008).

La instalacion y posterior configuracion de Postfix es extremadamente sencilla, basandoseunicamente en un fichero de configuracion (el fichero /etc/dovecot/dovecot.conf). En estefichero se indica los protocolos que se desea ofrecer (pop3, pop3, imap o imaps) y algunasotras indicaciones relativas a los certificados (en caso de que ofrezcamos conexiones seguras), losdirectorios de ejecucion, el formato de los mensajes de correo almacenados, etcetera. En realidades muy probable que con tan solo indicar los protocolos ofrecidos la herramienta funcione a laprimera, de ahı la sencillez de su configuracion. Para nuestro caso es mas que suficiente (en unmomento somos capaces de ofrecer un servicio POP/IMAP bajo conexiones seguras a los usuarios

22http://www.dovecot.org/



para que descarguen sus correos) por lo que nos decantamos por esta herramienta en favor decualquier otra.

1.3.6. Sistemas de monitorizacion

Los sistemas de monitorizacion nos permiten conocer en todo momento el estado de la red,formado por un conjunto de maquinas que ofrecen una serie de servicios a disposicion de losusuarios. En este sentido, las herramientas de monitorizacion realizan un sondeo continuo detodas las maquinas que conforman una red, comprobando que todos los servicios que dispone esamaquina estan funcionando adecuadamente. En caso de que alguno de ellos no este funcionandocomo debiera, el sistema enviara una alerta, normalmente en forma de correo electronico aladministrador de la aplicacion. Este correo electronico pondra en aviso al responsable de lamaquina o maquinas en cuestion afectadas por el problema, que tomara las medidas oportunas.

En nuestro caso, estas herramientas nos van a permitir conocer en todo momento el estado delas estaciones del Laboratorio y de los servidores, mostrando en todo momento aquellas maquinasque se encuentren en problemas. Normalmente, la mayorıa de los sistemas de monitorizacionofrecen un interfaz web amigable para el usuario donde se muestran los resultados de lamonitorizacion de la red. Es el caso de las tres herramientas estudiadas en esta seccion: Zabbix,Munin y Nagios.

Zabbix

Zabbix23 es una solucion de monitorizacion de codigo abierto de las mas avanzadas hoy en dıa.Permite la monitorizacion y registro del estado de varios servicios de red, servidores, estaciones,etcetera. Almacena los datos que registra en un sistema gestor de base de datos del tipo MySQL,PostgreSQL, SQLite o Oracle. Ademas dispone de un frontend o interfaz unico escrito en PHP,donde se muestran todos los datos recopilados por cada una de las herramientas que sondeael estado de la red. Aparte de monitorizar el estado de maquinas y servicios (por ejemplo, unapasarela SMTP o un servidor HTTP) Zabbix permite la monitorizacion avanzada de una maquinainstalando un componente llamado agente zabbix (Zabbix Agent) en el host en cuestion. Esteagente permite la obtencion de datos del host como por ejemplo el uso de memoria, procesos,espacio libre en disco, etcetera. Los agentes envıan la informacion al servidor para almacenar losdatos y mostrarlos de una forma amigable para el usuario a traves de un interfaz web.

En la imagen 1.1 podemos observar una de las capturas de pantalla del interfaz web degestion de Zabbix, en el que se muestra el estado particular de un host : uso de memoria, cargade procesador, espacio en disco, carga de red, etcetera. Como se puede ver en la imagen, lasestadısticas resultado de la monitorizacion realizada por Zabbix resultan ser bastante detalladas,quiza mas de lo que en un principio necesitamos. Ademas, la instalacion y posterior configuracionde esta herramienta puede ser demasiado compleja, lo suficiente para que no compense realmentecon respecto a nuestras necesidades. Digamos que los reportes ofrecidos resultan ser bastante masdetallados de lo que en un principio necesitamos: saber que maquinas estan disponibles en cadamomento y si se ha producido cualquier tipo de problema. Es por ello que en principio dejamosaparcada esta herramienta en busca de otra un poco mas simple para nuestros propositos.

No obstante, vamos a destacar las principales ventajas y desventajas de esta herramienta demonitorizacion.

Como ventajas, podemos decir que los reportes obtenidos por esta herramienta son muydetallados, obteniendo graficas en diferentes formatos de toda la informacion acerca delestado de la red y de los hosts que creamos oportuno. Esta informacion nos puede ayudar

23http://www.zabbix.com



Figura 1.1: Interfaz web de Zabbix. Fuente: Wikipedia

a construir informes de disponibilidad muy bien detallados y de una calidad mas queaceptable. Ademas de esto, Zabbix, soporta un gran numero de plataformas (incluidosSolaris, Linux, Mac OS, FreeBSD, HP-UX, etcetera). En la actualidad el nucleo de Zabbixno soporta Windows, pero sı puede monitorizar plataformas Windows, algo muy interesantepara 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 esbastante 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 paranuestros objetivos. La configuracion de la herramienta es bastante compleja y podemosafirmar que su manual de instrucciones tiene muchas paginas, lo que puede echar para atrasa alguien que en principio quiera usar esta herramienta para monitorizar una red de no muygrandes dimensiones.

Nagios

Nagios24 es una aplicacion bastante parecida a Zabbix, en muchos sentidos: permitemonitorizar el estado de un conjunto de maquinas en una red, comprobando disponibilidad tantode las maquinas como de los servicios asociados a ella. Cuando se produce un problema, Nagiosenvıa una alerta a un contacto o grupo de contactos informando del problema producido y sunivel de peligro. La diferencia mas importante de Nagios respecto a Zabbix es que Nagios enprincipio no puede monitorizar el estado interno de una maquina (carga de memoria, procesador,espacio en disco, etcetera), aunque en principio estos datos no son de nuestro interes, ya que para

24http://www.nagios.org



nosotros es mas importante conocer el estado de la red en tanto a maquinas y servicios.

Ademas de la monitorizacion constante que realiza Nagios, este ofrece un portal Web dondemonitorizar todos los resultados. Si en un momento dado queremos ver de una pasada rapida elestado de un host o de un grupo de hosts podemos realizarlo usando para ello su interfaz web.Respecto a la configuracion de Nagios, podemos afirmar que no es demasiado complicada. Existendiversos ficheros de configuracion donde se indican por un lado, las maquinas de las que constanuestra red, por otro lado y por otro los servicios que se desean comprobar sobre estas maquinas.Digamos que la configuracion es mas tediosa que complicada, debido a la verbosidad de los ficherosde configuracion. Aun ası, puede resolverse eficientemente si disponemos de un fichero de textodonde se indique la direccion IP de cada maquina y su nombre correspondiente. Usando un scriptde shell muy sencillo podemos generar el fichero de configuracion de nagios de forma trivial. Unavez que se han declarado todas las maquinas en el fichero de configuracion, se indican los serviciosque se desean comprobar para cada maquina. Como es muy frecuente agrupar las maquinas engrupos (en nuestro caso, las agruparemos por laboratorios y por grupos de servidores) Nagios nospermite declarar grupos de hosts. De esta forma, sera mas sencillo indicar que se desea comprobarun cierto servicio sobre un determinado grupo de hosts.

Una vez que se han declarado maquinas, grupos de maquinas y servicios, solamente deberemosindicarle a Nagios los contactos a los que se desea enviar informacion en caso de problemas. Dela misma forma que antes, Nagios permite declarar contactos y grupo de contactos. Es usual quelos responsables de un conjunto de maquinas sean mas de una persona, de ahı esta funcionalidadmuy acertada en la herramienta.

Una vez se han configurado estos parametros, se lanza Nagios y se pueden consultar a travesde su pagina web el estado de la red, y si se ha configurado para ello, nos llegara mediante correoelectronico los avisos de las alertas correspondientes.

Nagios esta disponible como paquete Debian/Ubuntu en las versiones estables actuales deambas distribuciones, por lo que su instalacion es trivial. No obstante, tambien puede ser instaladomediante fuentes, si queremos tener disponible la ultima version estable de la herramienta. Debidoa la sencillez de la configuracion (generada automaticamente con scripts) nos decantaremos porNagios como herramienta de monitorizacion de nuestro entorno.

Finalmente y para recapitular, podemos decir que, Nagios presenta las siguientes ventajas ydesventajas:

Como ventajas, su configuracion es muy simple y se puede realizar en apenas minutos,partiendo de un fichero con las IPs de todos los equipos de la red y su nombre de host, locual siempre se suele tener a mano. Una vez realizada esta configuracion, la herramientaempieza a obtener todos los reportes sin mas.

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 tambien puede convertirse en una ventaja. En el entorno en el que nos encontramos,estos reportes son mas que suficientes. Otra de sus desventajas es que solamente existeuna version para sistemas operativos de la familia Unix (y por tanto, Linux). No existeactualmente una version para Windows, aunque en principio esto no nos afecta ya que ennuestro entorno no disponemos hasta la fecha de estaciones Windows. Esto ocurrıa tambiencon su principal competidor, Zabbix, con la diferencia de que Zabbix puede obtener lasestadısticas completas de monitorizacion de una maquina Windows, debido a que disponede una version de su agente para este sistema operativo.



Munin

Por ultimo, analizamos la herramienta Munin25. La aplicacion Munin es una herramienta demonitorizacion de red y del sistema en general (mas bien, del sistema). La aplicacion se distribuyeen dos componentes: El servidor Munin, que recoge y procesa los datos que son enviados por losclientes, los nodos de Munin. Estos nodos se encuentran instalados en todas aquellas maquinasque se desea monitorizar o de las que se desea obtener estadısticas. Ademas, dispone de un grannumero de plugins o anadidos para recoger y procesar todo tipo de datos interesantes para eladministrador: carga de procesador (procesos), carga de memoria, espacio en disco, carga de lared, numero de operaciones de entrada/salida, etcetera. Ademas, dependiendo de si el servidordispone de una serie de servicios o no, Munin sera capaz de obtener datos de estos servicios. Porejemplo, para un servidor MySQL, Munin es capaz de obtener el numero de consultas por unidadde 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 representarel numero de paginas servidas por unidad de tiempo. En general, Munin dispone de un amplioabanico de plugins que hace que sea capaz de representar casi todas las estadısticas que puedehaber en un servidor hoy en dıa.

Figura 1.2: Representacion del uso de memoria en una maquina a traves de Munin. Fuente:Wikipedia

La aplicacion esta pensada para visualizar unicamente los datos que son recogidos a traves delos diferentes nodos. Una vez que estos datos son recogidos, se muestran a traves de un interfaz

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



web las diferentes graficas que se corresponden con cada uno de los servicios. En la imagen 1.2podemos ver como se representa el uso de memoria en una maquina a traves de Munin. Muninutiliza la herramienta RRDTool26 para la representacion de sus paginas.

La configuracion de Munin es extremadamente simple, ya que unicamente hay que instalarla aplicacion cliente en cada uno de los nodos que se desea monitorizar y el servidor en aquellamaquina que se desea usar para representar la informacion. En los clientes, se especifica en unfichero de configuracion que maquina es el servidor (para permitirle recoger los datos que el clienterecopila) especificando la direccion IP del mismo. En el servidor, se indica a que clientes se debeacudir para recopilar toda la informacion que se desea monitorizar. Y nada mas. Una vez hechoesto, el servidor Munin se conectara a los clientes periodicamente para representar la informacionque le facilitan los clientes.

Como el uso de esta aplicacion no implica no usar el resto, hemos decidido instalarla enuna maquina para obtener graficas relativas al uso de los diferentes servicios en cada uno delos servidores. Ya que la configuracion es extremadamente simple, no nos llevara mucho tiempodebido a que el numero de servidores en nuestra red no es muy elevado. Finalmente, indicamoslas ventajas y desventajas de esta herramienta:

Como ventaja, podemos afirmar que la configuracion de Munin es extremadamente sencilla,realizandose en apenas minutos para el entorno en el que nos encontramos. Ademas, lasestadısticas obtenidas por Munin son muy detalladas y nos brindan una informacion muyconcisa.

Como desventaja, podemos decir que el sistema de notificacion es algo pobre y algoextrano de configurar. Aunque, como Munin en sı mismo no esta pensado como sistemade notificacion, simplemente podemos usarlo para visualizar las graficas de los diferentesservidores y estaciones y usar Nagios como sistema de notificacion.

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


Capıtulo 2Objetivos

Una vez realizada una introduccion tanto a la motivacion del proyecto como a los objetivosprincipales, vamos a detallar de forma concisa en que consistira cada uno de ellos. Para ello,detallaremos cada uno de los objetivos y como lo afrontaremos. Nos proponemos dos objetivosprincipales, basados en el desarrollo de un sistema de instalacion automatico y desatendido y laimplantacion de un sistema de cuentas de usuario en red. Una vez que ambos objetivos han sidollevados a cabo, se ampliara la funcionalidad del entorno dotandolo de servicios de valor anadidoy ampliando la seguridad del mismo todo lo que podamos. Con esto conseguiremos un entornobastante fiable y reduciremos la probabilidad de que alguien pueda entrar en el sistema con unacuenta de usuario que no le pertenece, con todo lo que ello conlleva.

27

2.1. SISTEMA DE INSTALACIONES MASIVAS Y DESATENTIDAS

Una vez presentado el marco general de desarrollo de este proyecto y las tecnologıas utilizadas,en este capıtulo abordaremos los objetivos que se han perseguido durante la elaboracion delproyecto. 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 anadido (pagina web, correo electronico,etcetera)

Instaurar un servicio de monitorizacion de la red y de los servicios

Aumentar al maximo la seguridad del entorno.

2.1. Sistema de instalaciones masivas y desatentidas

El primer objetivo que abordamos es la implementacion de un mecanismo que permitaautomatizar la instalacion de estaciones de usuario basadas en Ubuntu Linux, de una formalo mas automatica y desatendida posible. Este mecanismo permitira la instalacion masiva delaboratorios de una forma comoda para el administrador de las mismas, y en un corto espacio detiempo.

Hay que tener en cuenta que cada Laboratorio se compone de al menos cuarenta equipos,por lo que el que exista un metodo de instalacion que no sea el tradicional (basado en unmedio extraıble que se instala en un equipo, siguiendo una serie de pasos) resulta practicamenteindispensable. El mecanismo de instalacion que perseguimos construir debe instalar todo elsistema, con todos los requisitos necesarios, sin que sea necesaria la intervencion del usuarioadministrador que lo realiza (unicamente, la iniciacion del proceso). Nuestro objetivo sera siempreque la interaccion entre el administrador y el proceso de instalacion sea mınimo, como veremosposteriormente. A veces, esto no sera posible, como veremos en el capıtulo Implantacion, dondese estudiara detenidamente la construccion de esta herramienta. Sin embargo, y en comparacioncon los metodos estudiados y descartados, la interaccion del administrador con el proceso deinstalacion casi siempre sera mınima. En el metodo estudiado e implementado se ha dotado alsistema de un sistema de instalacion desatendido que solamente requiere que el administradorinicie el proceso. El sistema se instalara sin requerir ninguna accion por parte del usuario y cuandoeste haya sido completado, la estacion se reiniciara automaticamente, iniciando el nuevo sistemarecien instalado.

Para la construccion de este sistema de instalacion automatica nos basaremos en diversastecnologıas, siendo la primordial los ficheros de preconfiguracion de Debian GNU/Linux. Estemecanismo sera estudiado con detalle en el capıtulo de Implantacion del presente documento.

2.2. Sistema de cuentas de usuario y disco en red

Debido a la naturaleza del sistema, es necesario proveer al mismo de un sistema de cuentasde usuario en red, que facilite que los usuarios puedan iniciar una sesion en el sistema usandopara ello una credencial basada en nombre de usuario y una palabra de paso o contrasena. Elsistema debe facilitar que un usuario pueda iniciar siempre una sesion en cualquier estacion delLaboratorio, independientemente de cual sea esta. De la misma forma, debe facilitar la creacionde nuevos usuarios, o el cambio de la palabra de paso de un usuario en concreto. Serıa razonableel marcar como objetivo que un cambio de una contrasena de un usuario, permita que el usuario


CAPITULO 2. OBJETIVOS

inmediatamente vea reflejado que el cambio afecta a todas las estaciones del Laboratorio: no serıarazonable que si el usuario ha efectuado un cambio en su contrasena, la nueva palabra de paso nose viera reflejada inmediatamente al iniciar una sesion en cualquier otra estacion del Laboratorio.

Como objetivo primordial para esta fase tambien nos marcaremos el anadir privacidad alos datos que viajan por la red relativos a las credenciales del usuario que intenta iniciaruna sesion en una estacion del Laboratorio, o que efectua un cambio en la palabra de paso ocontrasena de su cuenta. Esto es muy importante ya que al encontrarnos en un entorno basadoen red de medio compartido, nos podrıamos encontrar con usuarios maliciosos que puedenmonitorizar los datos que viajan por la red en un momento dado, capturando nombres de usuarioy contrasenas pertenecientes a un usuario en concreto. Si no anadimos un mecanismo que permitaocultar estos datos de forma conveniente, nos podemos encontrar con alguna que otra sorpresadesagradable. Veremos posteriormente en el capıtulo Implantacion como este aspecto se solucionaconvenientemente aportando una solucion basada en bibliotecas de cifrado sobre el protocolo quese ocupa de las cuentas de usuario. En principio no aportamos mas detalles tecnicos sobre esteobjetivo, ya que se estudiaran en detalle en el capıtulo oportuno.

Ademas, junto con el sistema de cuentas de usuario en red, serıa conveniente proporcionarun servicio de disco en red. No serıa logico que cada vez que un usuario iniciara una sesionen un equipo, tuviera unos ficheros diferentes a una sesion iniciada previamente en otro equipo(es decir, cada maquina con sus ficheros independientes). Como es logico, el inicio de una sesionen una estacion debe llevar asociado un espacio en disco personal, independiente de la estacionen la que se inicia la sesion y que este siempre disponible. Estudiaremos posteriormente comoimplementar este servicio.

2.3. Servicios adicionales

Construir un sistema de instalacion completamente automatico y desatendido y dotar alentorno con un sistema de cuentas de usuario en red y lo suficientemente seguro y confiableseran nuestros objetivos principales. Una vez completados estos hitos, nos marcamos ampliar lafuncionalidad del entorno con otros aspectos secundarios. En general, estos objetivos seran ensu mayorıa servicios de valor anadido, que haran del sistema un entorno mas funcional y masagradable de cara al usuario final: los alumnos.

En esta seccion, nos planteamos la persecucion de los siguientes hitos:

Dotar al entorno de una pagina web: dotar a los Laboratorios de un sitio web facilitael aprendizaje por parte de los usuarios al funcionamiento del mismo, ası como facilita unaplataforma para la documentacion de preguntas frecuentes de usuarios, anunciar noticiasrelacionadas con el Laboratorio y colgar los horarios de las salas para referencia de profesoresy alumnos.

Sistema de correo de entrada y recogida: dado que el sistema de cuentas de usuariono esta relacionado con las cuentas de dominio unico que se facilitan a los usuarios yprofesores de la Universidad por ser miembros de ella, implementaremos un sistema decorreo unido a las cuentas que entregaran correo en la direccion compuesta por el nombrede usuario propietario de la cuenta seguido del dominio del servidor que recoja el correoen ese momento. Una vez que los usuarios disponen de esta cuenta de correo, podranleer los mensajes que en ella se almacenen o bien redirigirlos a una cuenta de correo quelean asiduamente. Esta caracterıstica es fundamental, puesto que no disponemos de otromecanismo de comunicacion con los usuarios del sistema que no sea el correo electronico.

Sistema de resolucion de nombres local: de cara a anadir funcionalidad y toleranciade fallos, es interesante el anadir un sistema de resolucion de nombres local interno a los


2.4. MONITORIZACION DEL SISTEMA

Laboratorios. Esto permitira la resolucion de nombres de dominio mas rapidamente quesi se usara un servidor de resolucion de nombres ajeno al mismo, ademas de aumentar latolerancia a fallos de cara a caıdas de red. En cualquier caso, siempre podrıamos usar losservidores DNS que facilita la Universidad de cara a los usuarios de la red de la Organizacion.

Listas de correo: la utilizacion de listas de correo tiene dos objetivos principales. Porun lado, la comunicacion entre los administradores del Laboratorio y los usuarios, pormedio de una unica lista de correo. A traves de esta lista de correo se mandan avisos,noticias, recomendaciones de uso sobre el Laboratorio y en general cualquier nota quesea de interes para los usuarios del sistema. Los avisos que se mandan a esta lista sonrecibidos automaticamente por los usuarios del mismo solamente por el mero hecho dedisponer de una cuenta en los Laboratorios. Por otro lado, la creacion de un sistema delistas de correo nos va a permitir el gestionar determinados avisos y alertas que lleguen adeterminados grupos de personas encargadas de la gestion de los Laboratorios (profesores,administradores, etcetera). Por ejemplo, alertas sobre caıdas en los servicios (fallos electricos,de red, etcetera) o incidencias que se producen en el entorno (enviadas por los propiosusuarios). La creacion de listas permite que los mensajes sean enviados a varias personascon facilidad ademas de ser almacenados para su posterior consulta.

Replicas locales de Debian y Ubuntu: Dado que la instalacion de software (paquetes,como se denomina usualmente en las distribuciones Debian GNU/Linux y Ubuntu) esmuy frecuente, y normalmente se repite en tantas estaciones haya en el Laboratorio, eldisponer de una replica local o espejo de un servidor de software de Debian GNU/Linuxo de Ubuntu resulta realmente interesante. Si esto no fuera ası, cada paquete de softwareque se deseara instalar en una estacion o servidor deberıa ser descargado desde la replicacorrespondiente. Esta replica, aun no estando muy lejos (podemos disponer de una replicade Debian GNU/Linux o de Ubuntu en los servidores de RedIris) ya supone el dar un saltofuera de la red institucional de la propia Universidad, con todo lo que ello conlleva. Por estarazon, la instalacion de una replica local siempre sera un punto muy a favor para disminuirel trafico externo y aumentar la velocidad a la hora de instalar software en los Laboratorios.

Copias de seguridad de directorios de usuario: con el fin de que un problema dehardware no afecte a los datos personales de los usuarios del sistema, llevaremos a cabo unplan de copias de seguridad que garantice que al menos si se produce un fallo de hardwareen alguno de los discos del sistema tengamos una copia de respaldo de la que disponer pararestaurar los ficheros personales de los usuarios.

Posteriormente en el capıtulo Implantacion estudiaremos como se han llevado a cabo cadauno de estos requisitos que acabamos de definir.

2.4. Monitorizacion del sistema

En este tipo de entornos, parece que el trabajo queda finalizado cuando todos los hitos quenos planteabamos se han completado y todos los sistemas se encuentran funcionando en fase deproduccion. Nada mas lejos: una vez que el sistema esta en marcha, la monitorizacion del sistemase convierte en el aspecto fundamental para el correcto funcionamiento del mismo. En nuestrocaso, y dado el elevado numero de estaciones existentes y servidores que hacen que el entornofuncione correctamente, la evaluacion de un sistema de monitorizacion de servicios sera algofundamental y completamente necesario si no queremos encontrarnos una manana con que unservicio ha dejado de funcionar y no nos hayamos enterado hasta pasadas unas horas.


CAPITULO 2. OBJETIVOS

Para solucionar este aspecto, se pondra en marcha un sistema de monitorizacion de todoslos servicios existentes en el Laboratorio: por un lado, se vigilara que no haya caıda masiva deestaciones (las cuales son producidas normalmente por interrupciones del fluido electrico). Eneste sentido, es importante saber en todo momento cuando se ha producido una caıda masivade estaciones: es significado de que algo no va bien. Sin embargo, no sera necesario conocercuando un ordenador ha dejado de estar disponible (se encuentra apagado), ya que puede ser pormuy diversos motivos y en principio, que una estacion deje de funcionar (una o un numero muypequeno) no debe ser motivo de distraccion. Por otro lado, sera muy importante vigilar que todasaquellas maquinas que proporcionen servicios basicos para el funcionamiento del Laboratorio(esto es, servidores) se encuentren disponibles siempre, en todo momento. Al contrario que en lasestaciones, la caıda de una sola de estas maquinas debe requerir nuestra atencion inmediatamentey debe ser resuelta lo mas rapido posible. Normalmente, estos avisos son enviados por correoelectronico, o son notificados mediante avisos sonoros. En cualquier caso, la notificacion inmediatade problemas en el entorno debe ser fundamental.

Estos mensajes son interesantes para los administradores del Laboratorio, si bien para losalumnos siempre resulta util conocer cuantas estaciones estan disponibles en un momento dado,para poder iniciar una sesion en una de ellas. Si bien esta informacion no es fundamental, esbastante interesante de cara a encontrar una estacion disponible en un momento dado parapoder iniciar una sesion remota. En este sentido, llamaremos partes de guerra a los informes deestaciones disponibles existentes en el Laboratorio, y podran ser consultados desde la pagina webdel Laboratorio.

En resumen, sera condicion indispensable para este proyecto la implantacion de un sistemaque permita monitorizar en todo momento el estado de todos los servicios del Laboratorio:estaciones (si estan funcionando, cuantas en cada momento, etcetera) y servidores (que estentodos 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 siempreun entorno lo mas seguro posible. Cabe destacar que nos encontramos en un entorno con lassiguientes caracterısticas:

Aproximadamente 3000 cuentas de usuario

160 estaciones de trabajo en el Campus de Mostoles y 100 en el Campus de Fuenlabrada

Todas las estaciones de trabajo y servidores disponen de IPs publicas.

Un entorno de estas caracterısticas, en el que todas las estaciones disponen de un servicioSSH en el que realizar peticiones, y con tantas cuentas de usuario y ademas con IPs publicas(accesibles desde cualquier punto de Internet) puede ocasionarnos verdaderos quebraderos decabeza si no tomamos una serie de medidas que garanticen que si alguien accede al sistema deforma fraudulenta (normalmente, usando una cuenta de usuario que no le pertenece), este seainterceptado inmediatamente.

Es comunmente sabido que no hay mayor defensa que un buen ataque. Pues bien, en estesentido, 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.


2.6. DOCUMENTACION

Monitorizar y denegar conexiones a aquellas IPs que son detectadas como posiblesorıgenes o causantes de intentos de fuerza bruta a traves de SSH.

Desarrollar un sistema de auditorıa que nos permita almacenar un historico de aquellosusuarios que han iniciado una sesion en alguna estacion del laboratorio.

Utilizar herramientas que nos ayuden en la deteccion de intrusos (o desarrollarlasnosotros mismos).

Vigilar constantemente la fortaleza de las contrasenas de los usuarios del sistema.

Siguiendo estrictamente y regularmente esta serie de medidas, seguramente no eliminemos laprobabilidad de que alguien ajeno al sistema pueda penetrar en el utilizando o bien una cuentade usuario o bien un agujero de seguridad en alguna aplicacion; pero con toda seguridad, estaprobabilidad sera bastante mas baja a no realizar estos chequeos.

2.6. Documentacion

Por ultimo, un aspecto deseable de nuestro proyecto serıa generar la maxima documentacionposible de todos aquellos hitos realizados. Implementaciones, ficheros de configuracion, decisionestomadas, etcetera. Todo aquello que podamos dejar por escrito siempre sera bienvenido parapoder ser consultado en un futuro bien por nosotros mismos o por la persona que se tenga queencargar de la administracion de los Laboratorios en un momento dado.

Dado que vamos a disponer de una pagina web para los Laboratorios, no sera mala ideautilizar esa misma pagina web para poder almacenar toda la documentacion que se ha idogenerando a medida que los hitos se han ido completando. Una buena idea para almacenar estainformacion podrıa ser la utilizacion de un sitio web tipo wiki1 que se pudiera editar usando elpropio navegador, incluso por otros usuarios. Ası, diversos usuarios encargados de la gestion delLaboratorio podrıan visualizar y editar los contenidos en caso que lo creyeran oportuno.

1Un wiki, o una wiki, es un sitio web cuyas paginas web pueden ser editadas por multiples voluntarios a travesdel navegador web.


Capıtulo 3Especificacion y Diseno

Una vez puestas sobre la mesa todas las tecnologıas, habiendo enumerado las posiblesalternativas a cada una de ellas y establecido los objetivos que nos proponemos como base enel presente proyecto, en este capıtulo vamos a enumerar todos los requisitos de una maneramas formal. Debido a que este proyecto no se centra en el desarrollo de ningun productosoftware en particular, no se seguira ninguna metodologıa de desarrollo en concreto, basandonosunicamente en la implementacion y puesta en marcha de todos los servicios requeridos. En estecapıtulo enumeraremos los requisitos de cada una de las tres partes diferenciadas desarrolladasanteriormente.

33

3.1. METODOLOGIA EMPLEADA

3.1. Metodologıa empleada

El desarrollo de cualquier producto software se realiza siguiendo una determinada metodologıao modelo de desarrollo, de manera que se realizan una serie de tareas entre la idea inicial y elresultado obtenido. El modelo de desarrollo escogido establece el orden en el que se han de afrontarlas tareas en el desarrollo del proyecto, y nos provee de requisitos de entrada y salida para cadauna de las actividades.

Sin embargo, en este proyecto, al no desarrollarse ningun producto software en concreto(esta centrado basicamente en la administracion de sistemas) en este capıtulo nos vamos acentrar en enumerar todos los requisitos funcionales y no funcionales de los que constaba nuestrodesarrollo.

3.2. Analisis de requisitos

El analisis de los servicios necesarios que deben estar funcionando en cada uno de los servidores(necesarios para el correcto funcionamiento del Laboratorio) se llevara a cabo mediante unalista de requisitos funcionales. Debido a que el proyecto se subdivide basicamente en tres partesclaramente diferenciadas (construccion del proceso de instalacion desatendido, implementacionde un sistema de cuentas de usuario en red y creacion de servicios de valor anadido para losusuarios) vamos a ver la lista de requisitos funcionales para cada una de estas tres partes porseparado. Los requisitos se obtienen normalmente de los casos de uso, que a su vez describenla interaccion del usuario y el sistema. En nuestro caso, vamos a establecer que el usuario es elusuario administrador (que puede considerarse como un nivel mas elevado de usuario) y que elsistema es en cada caso cada una de las partes que nos proponemos desarrollar.

Debido a que la interaccion en cada caso es mınima, no vamos a describir los casos de uso(ni los diagramas ni la descripcion del flujo de eventos en cada caso) cinendonos unicamente a lacaptura de requisitos.

3.2.1. Proceso de instalacion desatendido

A continuacion vamos a enumerar la lista de requisitos que debe cumplir el proceso deinstalacion desatendido. En cuanto a los requisitos funcionales, cabrıa destacar:

1. RF1: El proceso debe facilitar la instalacion de un sistema completo Ubuntu Linux,preferiblemente, en la version Hardy (numerada como 8.04).

2. RF2: La interaccion con el usuario en este proceso debe ser nula. El proceso de instalaciondebe ser completamente desatendido.

En cuanto a los requisitos no funcionales (basados principalmente en las propiedades delsistema) podemos observar las siguientes:

1. RNF1: El sistema de instalacion automatica debe funcionar en plataformas Linux (tantoel sistema instalado, el cliente, como el sistema que provee la instalacion, el servidor).

2. RNF2: Sera necesario que el cliente posea la capacidad de realizar arranque por red en laplaca base (comunmente llamado PXE).

3. RNF3: El sistema debe cumplir unas condiciones mınimas de velocidad. Dado que el numerode estaciones a instalar sera elevado, es conveniente que se provea de algun espejo local deinstalacion, para que las latencias sean lo mas pequenas posibles y por tanto, el proceso deinstalacion no lleve mucho tiempo.


CAPITULO 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 requisitosfuncionales:

1. RF1: El sistema de cuentas de usuario en red debe facilitar la autenticacion de usuarios delsistema, en todas aquellas maquinas que conformen nuestro sistema, a traves de un nombrede usuario y una contrasena, o palabra de paso.

2. RF2: El sistema debe autenticar a los usuarios independientemente de la maquina en laque se encuentren y de forma independiente, es decir, un usuario puede iniciar su sesion almismo tiempo en tantas maquinas como desee.

3. RF3: El sistema debe permitir la creacion de nuevas cuentas de usuario (por parte de unadministrador o una cuenta privilegiada).

4. RF4: El sistema debe permitir que un usuario pueda cambiar su palabra de paso (nosera posible cambiar su nombre de usuario).

5. RF5: El sistema debe proveer un directorio personal para el usuario donde poder almacenarsus ficheros personales, una vez que haya iniciado su sesion. Este espacio permitira que losalumnos puedan almacenar sus practicas en el servidor, y que puedan ver estos ficheros ydirectorios independientemente de la maquina en la que hayan iniciado su sesion.

En cuanto a los requisitos no funcionales de este elemento del sistema, podemos destacar lossiguientes:

1. RNF1: En cuanto al Sistema Operativo usado para implementar el sistema deautenticacion, este debe ser un Sistema Operativo Debian GNU/Linux, a ser posible, en laultima version estable.

2. RNF2: En cuanto al sistema de cuentas de usuario en red, este debe estar basado en undirectorio LDAP, que estara implementado por el software OpenLDAP, en su ultima versionestable tambien a ser posible.

3. RNF3: En cuanto a requisitos de seguridad, debemos procurar en la medida de lo posibleque siempre que los datos de usuario viajen por la red, estos deben encontrarse cifradosutilizando tecnicas avanzadas de criptografıa, que haga muy difıcil que un usuario noautorizado 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, replicacion, division de cargay demas, se debe procurar en la medida de lo posible que el sistema sea tolerante a fallos(deben duplicarse aquellos recursos que sean necesarios), el sistema sea escalable (se deberealizar un reparto de carga adecuado) y se pueda realizar una recuperacion rapida antecualquier tipo de desastre (se deben realizar copias de seguridad diarias de los datos deautenticacion de los usuarios).

3.2.3. Servicios de valor anadido

Por ultimo vamos a poner en marcha una serie de servicios de valor anadido que van aayudar a que el entorno sea mas agradable y funcional de cara a los usuarios. Dado que estosservicios son opcionales, de cara a que el uso del entorno por parte de los usuarios sea masagradable y sencillo, plantearemos en su mayorıa requisitos funcionales, que seran normalmenterequisitos recomendados y que no esten del todo definidos, dejando al administrador la eleccionde la plataforma, sistema en concreto, etcetera.


3.3. DEDICACION DE LAS MAQUINAS FISICAS

1. RF1: Se debe poner en marcha un sistema de correo que permita que los usuariospropietarios de una cuenta en el sistema puedan recibir correo (posean un buzon de correoen el servidor donde recibir mensajes). Este sistema permitira que podamos comunicarnoscon los usuarios del sistema para indicarles cualquier asunto relacionado con su cuenta.

2. RF2: El entorno debe contar con una pagina web, donde se indique el nombre delos Laboratorios, y a ser posible se documente la mayor informacion posible acercadel funcionamiento interno de los mismos (horarios, normas internas de funcionamiento,recomendaciones, preguntas de uso frecuente sobre el uso del sistema, donde acudir si existealgun problema, etcetera). Tambien debe facilitar que los alumnos puedan colgar sus propiaspaginas web, mediante la inclusion de algun directorio en su espacio de disco personal. Estopermitira que puedan generar documentacion sobre las asignaturas y puedan compartirlaen Internet.

3. RF3: Es recomendable que se implemente algun mecanismo de listas de correo quepermita la gestion de anuncios a los usuarios del sistema, ası como la comunicacion internade los responsables del Laboratorio. Ademas, las listas de correo pueden ser usadas paraenviar notificaciones relativas al funcionamiento interno del sistema (alertas sobre caıdas enservicio, por ejemplo).

4. RF4: Debe implantarse un sistema de monitorizacion y notificacion de todos aquellosservicios que sean vitales para el correcto funcionamiento del Laboratorio. Este serviciodebe alertar inmediatamente de cualquier caıda en cualquiera de los servicios que impidaque el Laboratorio pueda funcionar adecuadamente. Es recomendable que este servicio poseauna interfaz web de cara al administrador y a los usuarios, que permita visualizar el estadode las estaciones y de los servidores.

Como requisitos no funcionales, unicamente vamos a resenar lo siguiente:

1. RNF1: se debe intentar en la medida de lo posible garantizar la seguridad en el entorno.Esto incluye la instalacion de todas aquellas herramientas de deteccion de intrusos, seguridady toma de decisiones relativas a la instauracion de polıticas de seguridad que impidan almaximo que un usuario pueda obtener una cuenta de usuario de forma ilegıtima o penetraren alguno de los servidores crıticos para el funcionamiento del Laboratorio.

3.3. Dedicacion de las maquinas fısicas

Una vez establecidos los requisitos de manera semiformal, vamos a establecer la division decada uno de los subsistemas principales entre las maquinas que tenemos disponibles. En principioen el Campus de Mostoles contamos con aproximadamente siete maquinas que pueden actuarcomo servidores en los cuales se instalaran los servicios mas importantes que daran servicio alLaboratorio. En el Campus de Fuenlabrada contamos solamente con dos servidores. La razon deesta diferencia en cuanto a numero de servidores se debe a que inicialmente los Laboratorios deLinux comenzaron su andada en el Campus de Mostoles, mientras que el Campus de Fuenlabrada(que presta servicio principalmente a asignaturas que se imparten en la titulacion de Ingenierıade Telecomunicaciones) ha comenzado hace poco, y continua ampliandose actualmente.

En el Campus de Mostoles contamos con las maquinas peloto, zipi, zape, lechuzo, sapientin,pantuflo y espatula. Como se puede observar, los nombres de los servidores de este campuspertenecen a personajes del comic Zipi y Zape, de Escobar. Como vimos en el capıtuloIntroduccion, el Sistema Operativo elegido para los servidores sera el Sistema Operativo DebianGNU/Linux, en su version 4.0 (la ultima version estable, codigo Etch).



3.3.1. Peloto

La maquina peloto poseera la direccion IP 212.128.4.7, y albergara el servidor LDAP decuentas de usuario de forma primaria (esto es, el servidor LDAP alojado en esta maquinasera el encargado de realizar escrituras en el directorio LDAP (en caso de que se produjeran).Ademas, albergara un mirror o espejo de los repositorios de Debian y de Ubuntu, para que lasinstalaciones de software en el Laboratorio sean mas rapidas.

3.3.2. Zipi

La maquina zipi poseera la direccion IP 212.128.4.2 y albergara el servidor LDAP en formasecundaria. Es uno de los servidores secundarios del directorio LDAP en el Laboratorio, ademasde otros servicios. En concreto la maquina zipi albergara el servidor DNS del laboratorio de formaprimaria, aunque en este documento no ha quedado detallado este servicio.

3.3.3. Zape

La maquina zape posee la direccion IP 212.128.4.3 y es el segundo de los servidoressecundarios de LDAP en el Campus de Mostoles. Junto con los otros dos servidores LDAPexistentes en el Campus de Mostoles conforman el conjunto de los servidores de autenticacionpara este Campus. Como veremos posteriormente en el capıtulo Implantacion, la division delservicio de autenticacion en diferentes maquinas nos va a garantizar la fiabilidad, escalabilidady tolerancia a fallos del servicio.

En concreto esta maquina, tambien alberga otro servicio no detallado en este documento, quees el de resolucion de nombres DNS (la maquina zape alberga de forma secundaria el servicioDNS para el Laboratorio).

3.3.4. Lechuzo

La maquina lechuzo posee la direccion IP 212.128.4.8 y es una maquina crıtica para elcorrecto funcionamiento del Laboratorio, ya que alberga el servicio de almacenamiento de ficherosen red para los usuarios. A traves de este servicio los usuarios al iniciar la sesion disponen de unespacio personal en el que almacenar sus ficheros personales (practicas, documentos, etcetera).Por supuesto, se trata de un servicio distribuido y en el que independientemente de la estacionen la que inicien la sesion, dispondran de los mismos ficheros.

Como vimos en el capıtulo Introduccion, la solucion adoptada para implementar este serviciose basa en el sistema de ficheros NFS de Linux. Aunque este servicio se encuentra duplicado (enla maquina sapientin) el cese en el funcionamiento de esta maquina provocarıa que los usuarios,aun pudiendo iniciar su sesion en cualquier estacion del Laboratorio, no pudieran acceder a susficheros personales (la autenticacion y el disco en red son servicios en principio independientes eluno del otro).

Es por ello que el funcionamiento de esta maquina es crıtico para el funcionamiento delLaboratorio, y debe ser monitorizada constantemente para ser alertados en el preciso instante enel que se produzca cualquier problema.

3.3.5. Sapientin

La maquina sapientin posee la direccion IP 212.128.4.6 y en cuanto a servicios, podemosdecir que es una replica exacta a la maquina lechuzo. Esta maquina dispone de un servicio dedisco en red (usando para ello el sistema de ficheros NFS de Linux) y posee una copia exacta de


3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA

los ficheros personales de los usuarios que se encuentran alojados en la maquina lechuzo. Paraello, todas las noches se sincronizan ambos directorios desde lechuzo hasta sapientin.

Si se produce cualquier tipo de problema en la maquina lechuzo que no sea recuperable enun periodo corto de tiempo (imaginemos que se rompe un disco en la maquina lechuzo pero elLaboratorio debe seguir prestando servicio), esta maquina comenzara a prestar servicio de discoen red como lo estaba haciendo lechuzo.

En principio, las probabilidades de que esta maquina llegue a usarse son realmente bajas.Para que se deje de usar la maquina lechuzo han de estropearse al menos dos discos en lechuzo,debido a que el espacio en disco se implementara usando una solucion basada en RAID, comoveremos posteriormente en el capıtulo de Implantacion. En cualquier caso, siempre es necesariodisponer de una maquina de recambio para que el servicio pueda seguir funcionando en cualquiercaso ante cualquier tipo de desastre.

3.3.6. Pantuflo

La maquina pantuflo posee la direccion IP 212.128.4.4 y tradicionalmente ha sido la maquinavisible de los Laboratorios de Linux de la Escuela. Antiguamente (en los primeros anos deexistencia de la Escuela, alla por el ano 1999) era el unico servidor que existıa: prestaba servicio deautenticacion, disco en red, pagina web, correo, servıa para que los usuarios (alumnos y profesores)se conectaran e hicieran las practicas, etcetera. Afortunadamente, los tiempos han cambiado y conla adquisicion de nuevos servidores dedicados en exclusiva a servicios crıticos para el Laboratorio(autenticacion, disco en red, etcetera) la maquina pantuflo ha sido relegada a ser unicamente lamaquina visible o buque insignia de los Laboratorios de Linux.

Esta maquina, solamente prestara servicio de pagina web para los Laboratorios, web personalesde los alumnos, y albergara el sistema de correo para los usuarios. La razon de albergar el sistemade correo y pagina web en esta maquina, es que los alumnos ya asocian la maquina pantuflo conlos Laboratorios de Linux, de forma que para ellos es muy facil recordar (o averiguar) que lapagina web se encuentra en la direccion http://pantuflo.escet.urjc.es o que las cuentas decorreo del servidor terminan por @pantuflo.escet.urjc.es. Ademas, vamos a aprovechar estamaquina para albergar las listas de correo del servidor, lo que nos va a permitir crear un canaldirecto de comunicacion entre todos los usuarios de los Laboratorios (para enviar notificaciones,noticias y notas de regimen interno sobre el funcionamiento de los Laboratorios).

3.3.7. Espatula

Por ultimo, la maquina espatula, con direccion IP 212.128.4.12 servira para albergar losdiferentes ficheros de preconfiguracion de las instalaciones desatendidas que desarrollaremosposteriormente en el capıtulo Implantacion. Ademas, en esta maquina instalaremos el serviciode monitorizacion que nos servira para comprobar el estado de la red en todo momento, y queenviara alertas en forma de correo electronico cuando se produzca algun problema en cualquierade los servidores o de los servicios crıticos para el funcionamiento del Laboratorio. En principioen esta maquina no alojaremos ningun servicio mas.

3.4. Servidores disponibles en el Campus de Fuenlabrada

A diferencia del Campus de Mostoles, en el Campus de Fuenlabrada unicamente se dispone dedos servidores principales, que asumen las labores de autenticacion de usuarios y de disco en red.Bien es cierto que el numero de estaciones en este campus es bastante menor que el de Mostoles(160 estaciones en el Campus de Mostoles frente a unas 100 aproximadamente en el Campus deFuenlabrada), aunque debido a que este numero esta aumentando considerablemente, se prevee



que el numero de servidores en el Campus de Fuenlabrada tambien aumente. De momento, losdos servidores de los que se dispone son bilo y nano. Estos nombres estan inspirados en la tirade comic del mismo nombre, Bilo y Nano, personajes creados por Javier Malonda. Debido a queel numero de servidores en este campus es menor, sera inevitable reunir servicios en una mismamaquina.

3.4.1. Bilo

La maquina bilo, posee la direccion IP 193.147.73.54. Es la maquina analoga a pantuflopara el Campus de Fuenlabrada, es decir, albergara el servicio de pagina web para ese laboratorio,ası como las paginas personales de los usuarios, el servicio de correo y la lista de correo de usuariospara este Campus. Ademas, albergara el servicio de disco en red para los laboratorios de esteCampus (debido a que solamente poseemos dos servidores, es inevitable que una sea la que sirvael disco en red y la otra la tengamos de repuesto ante posibles catastrofes).

3.4.2. Nano

La maquina nano posee la direccion IP 193.147.73.55 y tiene asociados dos servicios crıticos.Por un lado, es un servidor secundario para el servicio de directorio LDAP (el servicio de cuentasde usuario en red) y por otro lado, sirve de maquina de repuesto ante cualquier caıda en el serviciode disco en red que provee la maquina bilo (al igual que la maquina sapientin en el Campus deMostoles).

Como se puede apreciar, disponemos de un unico servicio de directorio LDAP que da servicioa ambos campus, el de Mostoles y el de Fuenlabrada. Por motivos de operacion, el servidorprimario para este servicio se encuentra alojado en el Campus de Mostoles (debido a quenuestra localizacion fısica en la Universidad se encuentra en el Campus de Mostoles, resulta mascomodo tenerlo en este campus). Por el contrario, el servicio de disco en red se ofrece de formaindependiente entre ambos campus, cada uno dispone de su disco particular y de sus ficheros.

Evaluados en este capıtulo los requisitos funcionales y no funcionales de cada una de las trespartes en las que se divide este proyecto, y disenados y divididos por servidores todos los serviciosque nos proponemos construir e implementar, en el siguiente capıtulo detallaremos todos losdetalles tecnicos que son necesarios para la puesta en marcha de todos los servicios.


3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA


Capıtulo 4Implantacion

Una vez llegados a este punto, nos ponemos manos a la obra para llevar a cabo uno poruno cada uno de los objetivos que nos propusimos en los capıtulos Objetivos y y Diseno. Enprimer lugar, arrancaremos formalizando e implementando un proceso completo de instalaciondesatendida. Este proceso, nos facilitara la tarea de realizar instalaciones masivas en poco tiempoy con muy poco esfuerzo. Una vez completada esta tarea, pasaremos a implementar cada uno de losservicios de los que se compone el entorno. En primer lugar, y como servicios indispensables, unmecanismo de autenticacion que permita a los usuarios poder usar tanto los terminales comolos servidores oportunos. De forma paralela, un servicio de disco en red que permita tenerdisponible almacenar sus ficheros en el entorno distribuido. A continuacion, iremos completando laimplementacion con mas servicios, que sin ser del todo indispensables, son necesarios para que elentorno funcione adecuadamente. Estos servicios (Web, correo electronico, resolucion de nombres,listas de correo, etcetera) quedaran totalmente implantados y funcionando correctamente a lafinalizacion del presente capıtulo.

41

4.1. HERRAMIENTA DE INSTALACION AUTOMATICA

4.1. Herramienta de Instalacion Automatica

Cuando se dispone de un numero muy elevado de estaciones o terminales se hace necesarioel disponer de un metodo de instalacion desatendida para que tanto la instalacion del SistemaOperativo como de todo el software se haga de la forma mas automatica posible.

Para llevar a cabo esta tarea, se va a utilizar el metodo de los ficheros de preconfiguracion deDebian, como se estudio en el capıtulo Introduccion. Esta tecnica no es nueva, y viene introducidadesde la version 3.0 de Debian GNU/Linux. Como vimos en la seccion Estado del arte, esta tecnicase basa en la inclusion de las respuestas a todas las preguntas del proceso de instalacion de DebianGNU/Linux o de Ubuntu, en nuestro caso.

Si dejamos alguna cuestion sin especificar, el instalador nos preguntara de forma interactivasobre ella. Como es obvio, cuantas mas preguntas queden respondidas en este fichero, masautomatizado y por tanto desatendido sera el proceso. Las preguntas respondidas en este fichero,pueden o deben ser las siguientes, por ejemplo:

Configuracion de la red (direccion IP, puerta de enlace predeterminada, servidores denombres DNS.

Configuracion de la version de Ubuntu a ser instalada (por ejemplo, la actual 8.04, UbuntuHardy).

Sitio replica que debe usarse para instalar la distribucion a traves de la red (nuestro mirrorlocal).

Disco duro donde sera instalado el Sistema Operativo.

Particionado especıfico (novato, experto, usual).

Configuracion de la zona horaria.

Configuracion de la herramienta de gestion de software (apt-get).

Contrasena del superusuario (root) y creacion de un usuario sin privilegios.

Por ultimo, ejecucion de un script de postinstalacion para personalizar la estacion a nuestrogusto.

Como es frecuente en las instalaciones de las ultimas versiones de Ubuntu, la mayorıa de laspreguntas de la lista anterior son las correspondientes a las del proceso de instalacion, y quedejandolas todas resueltas, el proceso de instalacion se realizara completamente en silencio, sinrealizar ninguna cuestion al usuario y de forma totalmente desatendida.

Este fichero de preconfiguracion debe ser incluido en el CDROM de Ubuntu con el que sepretenda instalar el sistema1. Bastara con colocar el fichero de texto en el raız del sistema deficheros del CDROM y modificar algunas lıneas del fichero isolinux para poder en marcha nuestrasolucion. Para ello, podemos descargar la version actual de Ubuntu, montar la imagen ISO comoun sistema de ficheros de loopback, copiar y modificar los ficheros correspondientes y volver agenerar la ISO. Una vez hecho esto, podemos grabar nuestro CD personalizado de Ubuntu yproceder a realizar el proceso de instalacion de Ubuntu.

1Recomendamos la consulta del apendice o los ficheros incluidos en el CDROM adjunto para leer un fichero depreconfiguracion de ejemplo basico.


CAPITULO 4. IMPLANTACION

Listado 4.1: Generacion de un CD personalizado de Ubuntu para instalacion automatica

1 # Descargamos una imagen mınima de Debian o Ubuntu

2 $ wget http ://.../ debian -40r0 -i386 -netinst.iso

3 # Montamos el CD de Ubuntu

4 $ mkdir /mnt/nueva_imagen

5 # copiamos el preseed

6 $ mount -o loop -t iso9660 $imagen_base /mnt/nueva_imagen

7 # Creamos un directorio para la nueva imagen

8 $ mkdir /copia_imagen

9 # Copiamos todo el contenido

10 $ cp -aRv /mnt/$nueva_iso /copia_imagen

11 # Se modifica el fichero Isolinux , situado en

12 # /copia imagen/nueva iso/isolinux/isolinux.cfg

13 # Copiamos el fichero de preconfiguracion creado previamente

14 $ cp preseed.cfg /copia_imagen/$nueva_iso /.

15 # Se regenera la ISO y se graba mediante Cdrecord , por ejemplo

16 $ mkisofs -v -J -R -T -V nueva_imagen -b isolinux/isolinux.bin -c boot.cat

17 -no -emul -boot -boot -load -size 4 -boot -info -table

18 -o nueva_imagen.iso /copia_imagen/nueva_imagen

Pero, ¿tenemos que insertar nuestro CDROM 160 veces, y expulsarlo otras 160? ¿No existealgun proceso mas corto? Efectivamente, lo hay. Si nuestro hardware es relativamente moderno,y nos permite realizar arranque por red, podemos realizar una instalacion completa a travesde la red, sin tan siquiera tener que insertar nuestro CD en el equipo correspondiente. De estaforma, incluso podemos indicar que nuestro fichero de preconfiguracion, se encuentra en una URLconcreta. Esto nos abre la puerta a un mundo de posibilidades: podemos tener un repositorio depreconfiguraciones en un servidor concreto, siempre disponible para poder servir instalaciones deequipos.

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 traves de red(usualmente llamado PXE2. Hablaremos de ello en adelante. De forma implıcita, necesitamos undespachador de direcciones IP automaticas, esto es, un servidor DHCP3.

4.1.1. Servidor DHCP para configuracion automatica de Red

Como hemos visto anteriormente, si queremos que nuestras instalaciones automaticas serealicen a traves de la red, sin tan siquiera introducir un CDROM de instalacion, necesitamosla puesta a punto de un servidor DHCP. Este servidor configurara automaticamente la red dela estacion que lo solicite, habilitandola para poder descargar tanto el Sistema Operativo comotodas aquellas herramientas o ficheros de configuracion que consideremos oportunos.

Nuestro servidor DHCP se puede encontrar en cualquier servidor que tengamos en nuestraIntranet. No es necesario que se encuentre en el mismo servidor donde se encuentre el sitio replicade la distribucion de Linux a instalar ni tampoco en el servidor donde se encuentre el fichero PXEque se descargara para comenzar la instalacion del Sistema Operativo.

Un servidor DHCP: dhcpd

Si estamos usando Ubuntu o en su defecto Debian, una llamada al instalador de softwareapt-get sera suficiente para instalar rapidamente un servidor DHCP.

Listado 4.2: Instalacion del paquete dhcp a traves de apt-get

$ apt -get install dhcp

2PXE son las siglas de Preboot Execution Environment, o Entorno de preejecucion.3DHCP son las siglas de Dynamic Host Configuration Protocol, o Protocolo de Configuracion dinamica de

huesped.



Es probable que la herramienta de configuracion e instalacion de paquetes dpkg soliciteconfiguracion para el citado paquete (por ejemplo el rango de direcciones IP que se va a despacharautomaticamente). En nuestro caso, procedemos a configurar manualmente editando el fichero deconfiguracion que encontramos en /etc/dhcpd.conf.

Es necesario especificar algunos parametros correspondientes a la configuracion de la subredque estemos usando en ese momento.

Listado 4.3: Fichero de configuracion dpchd.conf. Configuracion de subred.

1 subnet 212.128.4.0 netmask 255.255.255.0 {

2 range 212.128.4.20 212.128.4.20;

3 option broadcast -address 212.128.4.255;

4 option routers 212.128.4.1;

5 }

Ademas, vamos a incluir una entrada para que el host beta01.pantuflo.es arranqueautomaticamente a traves de la red:

Listado 4.4: Fichero de configuracion dpchd.conf. Configuracion de host.

1 host beta01 {

2 hardware ethernet 00:0f:1f:e4:a9:20;

3 filename "pxelinux .0";

4 next -server 212.128.4.4;

5 fixed -address 212.128.4.131;

6 }

Vemos como a traves de la direccion MAC4, asignamos automaticamente la direccion IP delequipo especificando ademas que busque el fichero de arranque PXE en el servidor 212.128.4.4.El fichero, se llama ademas pxelinux.0.

Se recomienda que si el numero de estaciones a instalar es muy elevado, se programe unpequeno script de shell (por ejemplo, en bash o sh) para automatizar la tarea de crear el ficherode configuracion de DHCP. Bastarıa solamente anadir la salida de este pequeno script al ficherode configuracion de DHCP y reiniciar su demonio correspondiente.

4.1.2. Arranque por PXE

El protocolo PXE (Entorno de preejecucion) es un protocolo que permite el arranque deestaciones usando un interfaz de red, independientemente de los dispositivos de almacenamientolocales que se encuentren en el mismo.

PXE fue introducido por Intel y esta descrito en su especificacion correspondiente5 publicadopor la propia Intel y Systemsoft, el 20 de Septiembre de 1999. Este protocolo hace uso de otrostantos protocolos de red (como IP) transporte (como UDP) y aplicacion (como hemos visto,hace necesario el uso de DHCP para el arranque). A continuacion veremos como es necesarioque se use otro protocolo de la capa de aplicacion, TFTP para poder descargar la imagen linuxcorrespondiente que sera arrancada para la instalacion del Sistema Operativo.

Como dijimos anteriormente, es necesario que nuestro hardware (tarjeta de red y placa base)incluya el uso de esta tecnologıa para poder hacer uso de ella. Normalmente a traves de laherramienta de configuracion de nuestra placa base podremos ver si se dispone de ella.

4Es recomendable que si usa DHCP en su red, se asegure que solamente responde a aquellas estaciones que lonecesitan. El uso indiscriminado de DHCP puede producirle problemas a otros usuarios de su misma subred.

5Actualmente en la version 2.1



Normalmente, para poder arrancar usando este protocolo, es necesario que durante el arranquede la estacion correspondiente, se pulse una combinacion de teclas (normalmente F12 o alguna otratecla funcion) que llame a la ejecucion del protocolo. Una vez arrancado, la tarjeta solicitara unapeticion DHCP a la subred para que esta se autoconfigure.

Configuracion del servicio TFTPPor ultimo, y para poder comenzar con la instalacion del Sistema Operativo en cuestion,

necesitamos una imagen del mismo y que de alguna forma, se pueda descargar de la red desde unservidor hacia la estacion que se este instalando en ese momento. Para ello, se hace uso de otroprotocolo de la capa de aplicacion, TFTP6.

TFTP es un protocolo de transferencia de ficheros muy similar a su familiar mas cercanoFTP7. Este protocolo es muy usado cuando se quiere transferir archivos de pequeno tamanoentre estaciones de una misma subred. Notese que el que este protocolo use el protocolo detransporte UDP no es una simple eleccion trivial: se asume que no se va a usar TFTP paratransferir ficheros muy pesados o para realizar una trasnferencia entre subredes muy alejadas.Algunos detalles de TFTP son los siguientes:

Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza elpuerto 21 TCP).

No puede listar el contenido de los directorios.

No existen mecanismos de autentificacion o cifrado.

Se utiliza para leer o escribir archivos de un servidor remoto.

Soporta tres modos diferentes de transferencia, netascii, octet y mail, de los que los dosprimeros corresponden a los modos ascii e imagen (binario) del protocolo FTP.

Podemos instalar un servidor TFTP en Debian GNU/Linux o Ubuntu a traves del siguientecomando:

Listado 4.5: Instalacion del servicio tfptd-hpa a traves de apt-get$ apt -get install tftpd -hpa

Al igual que antes, el paquete solicitara configuracion. Lo vamos a configurar como demonio,ejecutandose de forma independiente de inetd. Para ello, el fichero de configuracion situado en/etc/default/tftpd-hpa contendra las siguientes lıneas:

Listado 4.6: Fichero de configuracion /etc/default/tfptd-hpa.1 RUN_DAEMON ="yes"

2 OPTIONS ="-l -s /var/lib/tftpboot"

Vemos como en el fichero de configuracion se indica que se serviran los ficheros situados pordebajo del directorio /var/lib/tftboot. Esto nos servira para incluir en este directorio la imagende la distribucion de Linux que vamos a instalar posteriormente.

Para aplicar los nuevos cambios, basta con reiniciar el demonio correspondiente, tal y comomuestra el listado de ordenes 4.7.

Listado 4.7: Reinicio del demonio tftp/etc/init.d/tftpd -hpa restart

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



4.1.3. Arranque por red de Linux

Una vez que todas las herramientas anteriores se encuentran perfectamente configuradas yse encuentran funcionando, necesitamos una imagen concreta de la distribucion de Linux quequeremos instalar. En nuestro caso, necesitaremos una version de Ubuntu de arranque porred. Esta imagen contendra una imagen mınima del kernel de Linux que permitira iniciar losdispositivos necesarios y comenzara el proceso de instalacion.

Podemos descargar una imagen mınima de arranque por red desde la pagina de UbuntuLinux8. En concreto, usaremos la version de arranque por red de Ubuntu Hardy (8.04) que es laversion que instalaremos en el Laboratorio.

Una vez que hemos descargado el fichero correspondiente, procedemos a descomprimirlo en eldirectorio raız que sirve nuestro servidor TFTP, tal y como queda indicado en el listado 4.8.

Listado 4.8: Descarga del kernel de arranque por red de Ubuntu Hardy$ wget http :// archive.ubuntu.com/ubuntu/dists/hardy/

main/installer -i386/current/images/netboot/netboot.tar.gz

$ tar -xvzf pxeboot.tar.gz -C /var/lib/tftpboot/

Si todo va bien (nuestro servidor DHCP esta funcionando correctamente y el servidor TFTPesta sirviendo ficheros) al solicitar arranque por red en la pantalla de arranque de nuestra estacion,deberıa auto configurarse la tarjeta segun su IP correspondiente, y justo a continuacion, ver lapantalla principal de Ubuntu.

4.1.4. Ficheros de preconfiguracion

A continuacion, vamos a ver de que manera podemos automatizar todo el proceso deinstalacion. A partir de un fichero de preconfiguracion, que contiene todas las respuestas alproceso de instalacion, podemos evitar que el programa de instalacion de Ubuntu nos realiceninguna pregunta sobre la configuracion del Sistema Operativo.

IsolinuxIsolinux9 es un cargador de de arranque para Linux (arquitectura i386). Necesitamos editar

el fichero de configuracion de Isolinux para poder indicar que queremos cargar un fichero depreconfiguracion. Esto lo podemos hacer de la siguiente forma:

Listado 4.9: Fichero de configuracion de Isolinux1 LABEL instalacionAutomatica

kernel ubuntu -installer/i386/linux

3 append vga=normal initrd=ubuntu -installer/i386/initrd.gz

netcfg/choose_interface=eth1 locale=es_ES

5 console -setup/ask_detect=false console -setup/layoutcode=es

languagechooser /language -name=Spanish countrychooser /shortlist=ES

7 console -keymaps -at/keymap=es netcfg/get_hostname=unassigned -hostname

preseed/url=http :// minervo.escet.urjc.es/preseed --

Notese el uso de la directiva preseed/url indicando que el fichero de preconfiguracion esun recurso HTTP situado en la direccion indicada por la URL. Si quisieramos haber incluidoel fichero de preconfiguracion directamente en la imagen mınima del kernel que se arranca conel proceso de instalacion, deberıamos hacer uso de la directiva preseed/file, indicando la rutaabsoluta hacia el fichero de semilla.

El fichero de configuracion de isolinux puede contener numerosas opciones de arranque (cadauna forma una etiqueta LABEL). Podemos tener por tanto numerosas opciones de arranque,

8https://help.ubuntu.com/community/Installation/Netboot9http://syslinux.zytor.com/iso.php



cada una dependiendo por ejemplo de un hardware especıfico, o de unas opciones de instalacionesconcretas.

Si queremos que en cada momento se arranque siempre una instalacion en concreto (unaetiqueta LABEL) lo podemos hacer incluyendo las siguientes lıneas:

Listado 4.10: Fichero de configuracion de Isolinux

8 DEFAULT instalacionAutomatica

9 PROMPT 0

10 TIMEOUT 0

Donde indicamos que se debe arrancar por defecto la etiqueta instalacionAutomatica, conun timeout de 0 segundos, y sin indicador de arranque.

Fichero de preconfiguracion

Por ultimo, unicamente nos queda empezar a definir el fichero de preconfiguracion queutilizara el sistema de instalacion automatica para realizar el proceso de instalacion en un modono interactivo. Este fichero es un fichero de texto, visible y modificable por cualquier editorde textos. Podemos usar nuestro editor de textos favorito para poder editar nuestro fichero depreconfiguracion personalizado.

El fichero de preconfiguracion contiene todas las respuestas a cada una de las secciones delproceso de instalacion. Ası, en vez de solicitar al usuario la entrada por teclado, la leera deeste fichero. Las opciones mas importantes son las relacionadas con la red, el particionadodel disco duro, la configuracion de la herramienta de gestion de software, y la creacion deusuarios. Mencionaremos las opciones mas importantes, dejando la posibilidad de leer el ficherode preconfiguracion completo en el apendice de este documento.

En primer lugar, debemos indicar las opciones necesarias para preconfigurar la red. En nuestrocaso, nos es particularmente interesante que la preconfiguracion se realice a traves del protocoloDHCP. Esto nos facilitara que cada estacion asuma la direccion de red que le pertenece. Unavez finalizado el proceso, podemos cambiar esta configuracion de dinamica a estatica, si ası nossentimos mas seguros ante la caıda del servidor DHCP y por ende el cese del funcionamiento detodas las estaciones. Esto lo podemos conseguir con las siguientes lıneas:

Listado 4.11: El fichero de preconfiguracion preseed.cfg.

10 d-i netcfg/choose_interface select eth1

11 d-i netcfg/disable_dhcp boolean false

12 d-i netcfg/confirm_static boolean true

Una vez hemos configurado la red, procedemos a indicar el sitio replica de donde sedescargara la imagen del sistema base a ser instalada. Es preciso indicar tambien que sistemadeseamos instalar (version concreta). Lo podemos indicar con el codename o nombre en clave decada una de las versiones. En nuestro caso, vamos a instalar la vesion Hardy (numerada 8.04) dela distribucion Ubuntu:


12 d-i mirror/country string enter information manually

13 d-i mirror/http/hostname string peloto.escet.urjc.es

14 d-i mirror/http/directory string /ubuntu/

15 d-i mirror/suite string hardy

16 d-i mirror/security -host peloto.escet.urjc.es



Tenga en cuenta que es interesante tener un mirror o espejo local en la Intranet para acelerarnotablemente el proceso de instalacion. Si por motivos de espacio no le es posible instalar un mirrorcompleto de toda la distribucion, puede usar la herramienta apt-proxy para evitar descargar unmismo paquete repetidas veces (una por estacion). Notara una mejorıa notable en el proceso deinstalacion.

Una parte importante del proceso de instalacion reside en la configuracion del particionadodel disco donde se ha de instalar el Sistema Operativo. Esto requiere de numerosas lıneas depreconfiguracion que indican entre otras cosas, que disco ha de usarse en la instalacion (usando lanomeclatura clasica de sistemas Unix), que esquema de particionado se va a usar (para novatos,experto o con receta) y el esquema concreto que va a usarse.

En nuestro caso, vamos a usar una receta10 de partman (el programa que se encarga delparticionado del disco para la instalacion). Para ello, indicamos las siguientes lıneas:


16 d-i mirror/security -host peloto.escet.urjc.es

17 d-i partman -auto partman -auto/select_disk string /dev/sda

18 d-i partman -auto/disk string /dev/sda

19 d-i partman -auto/method string regular

20 d-i partman -auto/expert_recipe string

21 boot -root :: 300 5500 30000 ext3

22 $primary{ } $bootable{ }

23 method{ format } format{ }

24 use_filesystem { } filesystem{ ext3 }

25 mountpoint{ / } .

26 64 512 300 % linux -swap

27 method{ swap } format{ } .

28 100 10000 1000000000 ext3

29 method{ format } format{ }

30 use_filesystem { } filesystem{ ext3 }

31 mountpoint{ /data } .

32 d-i partman/choose_partition select Finish

33 partitioning and write changes to disk

34 d-i partman/confirm boolean true

En la etiqueta se indica una receta de partman. Como vemos, en ella se indica que se crearantres particiones, todas ellas deberan ser formateadas, y el sistema de ficheros de todas ellas sera (elsistema de ficheros mas usado en particiones Linux). Se indican ademas los puntos de montajede cada una de ellas, ademas como el tamano (indicando el cilindro de comienzo y el de final). Serecomienda la lectura de las reglas de sintaxis para la formacion de recetas para el particionadorpartman.

Es necesario configurar el lenguaje predefinido del Sistema. Ademas, tenemos que configurarapt-get, la herramienta de gestion de paquetes de Ubuntu. Tambien nos interesara que se usenuestro mirror local (situado en el servidor peloto.escet.urjc.es) y que ademas, se usen todas lassecciones de las distribuciones11. Esto lo conseguimos con las siguientes lıneas:


34 d-i languagechooser/language -name -fb select Spanish

35 d-i debian -installer/locale select es_ES.UTF -8

10Receta viene del termino anglosajon recipe, muy usado en la comunidad Open source.11Usualmente, 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.



36 d-i apt -setup/uri_type select http

37 d-i apt -setup/country select enter information manually

38 d-i apt -setup/hostname string peloto.escet.urjc.es

39 d-i apt -setup/directory string /ubuntu/

40 d-i apt -setup/another boolean false

41 d-i apt -setup/security -updates boolean false

42 d-i apt -setup/security_host string peloto.escet.urjc.es

43 d-i apt -setup/main boolean true

44 d-i apt -setup/universe boolean true

45 d-i apt -setup/multiverse boolean true

46 d-i apt -setup/restricted boolean true

47 d-i apt -setup/backports boolean true

Tambien nos interesa configurar la zona horaria del Sistema y su localizacion. Lo conseguimoscon las lıneas siguientes:


47 d-i tzconfig/gmt boolean false

48 d-i tzconfig/choose_country_zone /Europe select Madrid

49 d-i tzconfig/choose_country_zone_single boolean true

Las cuales dependeran evidentemente de la localizacion de la estacion que se instale en esemomento. A continuacion, vamos a configurar el usuario generico del sistema, que dispondra deprivilegios especiales por medio de la herramienta sudo para convertirse en superusuario:


49 d-i passwd/user -fullname string agutierr

50 d-i passwd/username string agutierr

51 d-i passwd/user -password -crypted

52 d-i

passwd $1$ascCqW.t$bfUOFHDQLpBmpr9dOrP.a0

La contrasena, como se puede observar, se introduce en claro (cifrada con un pequeno hash.Recomendamos la inclusion de una contrasena generica y que una vez terminado el proceso, sesustituyan lo mas rapido posible los ficheros /etc/passwd y /etc/shadow.

En las lıneas finales, indicaremos que, como ultima tarea, deseamos ejecutar un scriptdescargado de Internet. A traves de este script, realizaremos todas aquellas tareas que no noes posible configurar a traves de esta herramienta de preconfiguracion. En este script podremosinstalar paquetes, retocar ficheros de configuracion, tener en cuenta algunas particularidadesespecıficas de hardware, etcetera. Esta aplicacion es muy interesante, ya que nos permite dejar elsistema al gusto del administrador. Lo conseguimos con las lıneas:


52 d-i preseed/late_command string wget http :// minervo.escet.urjc.es/

53 instalacion/ajusta -linux -mostoles;

54 chmod +x ajusta -linux -mostoles; sh ajusta -linux -mostoles

Por ultimo, indicamos donde se instalara el gestor de arranque. El gestor de arranque esnecesario para poder iniciar el sistema una vez instalado. El gestor de arranque que se usa hoyen dıa es Grub, en detrimento de Lilo (LinuxLoader) que se usaba hasta hace muy poco en lamayorıa de las distribuciones. Lo conseguimos con las siguientes lıneas:




54 d-i finish -install/reboot_in_progress note

55 d-i grub -installer/only_debian boolean true

56 d-i grub -installer/with_other_os boolean true

Preconfiguracion generica de paquetes

El fichero de configuracion mostrado anteriormente es valido para todas aquellas instalacionesbasadas en la version Hardy (8.04) de Ubuntu. Sin embargo, si se quiere usar este metodo enfuturas versiones, es muy probable que la notacion de la preconfiguracion haya cambiado. Elobjetivo de este apartado es la de entender como funciona internamente la preconfiguracion deun paquete, y poder usar este metodo para preconfigurar cualquier paquete en la instalacion, sinnecesidad de guiarnos por un metodo generico (el fichero mostrado anteriormente).

Es muy probable que si usamos este metodo en versiones posteriores a la usada en elpresente documento, se introduzcan en la instalacion nuevos paquetes (con su correspondienteconfiguracion) que hagan que si este no se encuentra preconfigurado (entiendase porpreconfigurado el que se indique en el fichero de preconfiguracion todas las preguntas a suconfiguracion) se muestre el dialogo del proceso de instalacion instando a la persona que realizael proceso de instalacion a responder a las preguntas que sean necesarias. Comentabamos en elcapıtulo Introduccion que sin duda una de las ventajas principales del metodo de instalaciondesatentida basada en ficheros de preconfiguracion es que el proceso se realiza automaticamente,sin necesidad de realizar ninguna accion entre el administrador que instala el sistema y el procesode instalacion. Si bien responder a una pregunta o dos en el proceso de instalacion no representamayor molestia, si el numero de instalaciones es elevado, el proceso puede llegar a convertirse entedioso.

Figura 4.1: El proceso de instalacion en Debian/Ubuntu y la preconfiguracion de paquetes.

Si nos vemos en el papel de realizar una instalacion desatendida basada en ficheros depreconfiguracion y tenemos la mala suerte de que el fichero incluido en el apendice de estedocumento no resulta completo frente a la preconfiguracion de todos los paquetes que se instalanen el proceso de instalacion del sistema, no tenemos que asustarnos, puesto que el metodo esmuy simple. En primer lugar, debemos fijarnos en que paquete esta solicitando configuracion



adicional. Para ello, podemos observar el tıtulo de la ventana de debconf, donde indica el paqueteen cuestion. Por ejemplo, en la imagen 4.1 se muestra como el paquete slapd esta solicitandoconfiguracion adicional.

Una vez que hemos identificado el paquete molesto, debemos obtener sus fuentes parainspeccionar la plantilla de configuracion. Para realizar este paso, podemos optar por diversassoluciones. Si se tiene configurada una lınea de fuentes en el fichero /etc/apt/sources.list,simplemente una llamada a apt-src puede ser mas que suficiente. En el listado 4.19 se muestra lallamada a este comando. Notese que la llamada a apt-src no requiere privilegios especiales, y quela instalacion resolvera todos aquellos paquetes necesarios, de los que depende el que se quiereinstalar. Nuestro objetivo solamente sera el paquete indicado en la llamada a apt-src, pudiendoobviar el resto.

Listado 4.19: Instalacion del paquete slapd a traves de apt-get

$ apt -src install slapd

Una vez que las fuentes han sido descargadas, es necesario descomprimir el codigofuente del paquete en busca del fichero templates. Este fichero en la mayorıa de lasocasiones suele encontrarse en el directorio debian/ de las fuentes del paquete. En elcaso del paquete slapd, el fichero mencionado se encontrarıa en el directorio openldap2.3-2.4.7/debian/slapd.templates12. Una vez que hemos localizado el fichero, podemos abrirlocon nuestro editor de texto favorito. Un parrafo del fichero puede ser el siguiente:

Listado 4.20: El fichero de plantilla de debconf para el paquete slapd.

56 Template: slapd/no_configuration

57 Type: boolean

58 Default: false

59 _Description: Omit OpenLDAP server configuration?

60 If you enable this option , no initial configuration or database will be

61 created for you.

La lectura de este fichero es muy sencilla: en el se incluyen todas las preguntas que debenser respondidas cuando se instala el paquete por primera vez, a traves de la herramientadebconf. En el caso del fragmento del fichero anterior, se indica que se realiza una preguntaque solamente puede tener dos respuestas (de ahı el tipo booleano), que de forma predeterminadase respondera que No y que tiene la descripcion indicada en las lıneas siguientes. Si estuvieramosinteresados en preconfigurar este paquete, deberıamos incluir una lınea por cada pregunta quefuera incluida en la configuracion del mismo. Para el caso de la pregunta anterior, serıa suficienteque incluyeramos la siguiente lınea:

Listado 4.21: Preconfigurando el paquete slapd.

61 slapd slapd/no_configuration boolean false

Con esto conseguirıamos que la pregunta anterior no se llevara a cabo, ya que se encuentrapreconfigurada. Si realizamos este mecanismo para todas aquellas preguntas que interfieren enel proceso de instalacion no dejando que sea un proceso desatendido al cien por cien, habremosconseguido que no sea necesario realizar ninguna accion para instalar el paquete en cuestion.

Como vemos, la preconfiguracion de paquetes es un metodo muy potente y flexible, que nosbrinda la posibilidad de realizar procesos de instalacion completamente desatendidos sin mas

12Fuentes del paquete slapd en la distribucion Ubuntu Hardy.


4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACION

que inspeccionar los ficheros de plantilla que requieren los paquetes que estemos interesados eninstalar.

4.2. Protocolos situados en la capa de aplicacion

En esta seccion se detallara como se ha llevado a cabo la implementacion todos los protocolosque son necesarios para el correcto funcionamiento del entorno. Sin duda, los dos mas importantesson el servicio de cuentas de usuario, y el servicio de disco en red. A traves de estos dos protocoloslos usuarios podran iniciar su sesion en cada una de las estaciones y poder acceder a sus ficheros,independientemente de la estacion en la que se encuentren.

4.2.1. Servidor LDAP de cuentas de usuario

Un punto muy importante en cualquier sistema que se precie, es la gestion de los usuarios enred. Teniendo en cuenta que se trata de un sistema que va a soportar un numero muy elevado deusuarios en lınea, son muchos los factores a tener en cuenta.

La implementacion del servicio de cuentas de usuario se llevara a cabo mediante la gestion deun directorio de tipo LDAP, tal y como estudiamos en el capıtulo Introduccion, donde realizamosuna comparativa de las diferentes tecnologıas para llevar a cabo una implementacion de cuentasde usuario en red.

Instalacion del servicio LDAP

Una vez comentadas las motivaciones principales que nos convencieron a proceder al cambio delos protocolos NIS a LDAP, vamos a proceder a meternos en harina detallando cuales son los pasosnecesarios para poder implementar un entorno de autenticacion segura basado en el protocoloLDAP. En primer lugar, necesitamos por supuesto uno o mas servidores LDAP. Cabe resenaren cuanto a la nomenclatura usada, que el termino LDAP hace referencia al protocolo, descritopor la RFC13 correspondiente14; mientras que existen aplicaciones con diferentes licencias queimplementan el citado protocolo. Una de las mas usadas hoy en dıa en la mayorıa de servidoresUnix y Linux (ademas de otros Sistemas Operativos de la familia Unix) es OpenLDAP, unsoftware que proporciona un servidor basado en el protocolo LDAP. En nuestro caso, sera el queusemos.

Como comentamos en el capıtulo de diseno, en los servidores del entorno se usara ladistribucion Debian GNU/Linux, en version estable (actualmente, la 4.0 con codigo Etch). Lainstalacion de la aplicacion OpenLDAP en una distribucion Debian es realmente sencilla, y sebasa en una llamada muy simple a su herramienta de instalacion de Software, como queda reflejadoen el listado 4.22.

Listado 4.22: Instalacion del paquete slapd a traves de apt-get

$ apt -get install slapd

En Debian, y en la mayorıa de distribuciones Linux, la aplicacion OpenLDAP se proveea traves del paquete slapd. La instalacion del paquete resolvera aquellas dependencias que seconsideren oportunas para que el servidor pueda funcionar adecuadamente.

En el proceso de instalacion del paquete, es necesario responder a algunas preguntas relativasa la configuracion del paquete en el entorno en el que va a ser instalado. Algunas de ellas son cual

13RFC son las siglas de Request for comments, documentos que describen detalladamente el comportamiento deun protocolo.

14http://www.faqs.org/rfcs/rfc2251.html



sera la raız del directorio LDAP, la contrasena del administrador, la eleccion del sistema gestorde base de datos que almacenara los datos del directorio y poco mas. En nuestro caso, hemosdecidido que:

La raız del arbol LDAP se identifique mediantela cadena siguiente: dc=zipi,dc=escet,dc=urjc,dc=es. Este nombre se debe a la notacionde los nombres de las maquinas usado en la Universidad.

El tipo de base de datos que almacenaran los datos del directorio sera DBD.

La contrasena de administrador de LDAP es un dato que queda privado de cara aladministrador del sistema.

Una vez que hemos decidido estos parametros, el servidor queda instalado, y se inicia enel puerto estandar de LDAP: el puerto 389. Este puerto recibira las peticiones de los clientessobre consultas al directorio LDAP: en texto claro. Cualquier usuario que tenga acceso a la redpodra escuchar estas peticiones y averiguar datos sensibles (muy sensibles, como la contrasenade su cuenta, por ejemplo) de los usuarios. Es por tanto, que nuestra primera tarea avanzadasera securizar el servidor de cara a crear conexiones seguras entre los clientes y el servidor LDAP.

El protocolo LDAP: conceptos basicos

Hasta el momento hemos detallado como se lleva a cabo la instalacion basica de un servidorLDAP. Sin embargo, no sabemos hasta el momento como funciona realmente este protocolo.Vamos a realizar una descripcion tecnica muy breve de como se organizan los datos en unservidor LDAP y como funciona este realmente (a grandes rasgos). Sin duda, estas explicacionesson fundamentales de cara a mejorar la funcionalidad del servidor, poder agrupar los datos enorganizaciones o subarboles, y dotar al servidor de aspectos avanzados como son la replicacion yel reparto de carga.

Como hemos dicho, LDAP proporciona servicios de directorio: una base de datos centralizadade informacion esencial sobre personas, usuarios, grupos de usuarios, etcetera. Puesto que cadaorganizacion se estructura de una forma y su definicion de informacion esencial puede ser muydistinta, un servicio de directorio debe ser muy flexible y personalizable.

El eje fundamental de un servicio de directorio es proporcionar un mapa de distribucion deuna companıa, en este caso, de una organizacion de los usuarios de una Universidad. Una de lascaracterısticas mas visibles de una estructura de base de datos LDAP es la convencion en losnombres que se usa: es fundamental llevar a cabo una convencion de nombres que identifique laestructura organizativa de la empresa u organizacion que se quiere representar antes de configurarel servidor. Este sistema, puede resultar muy parecido y similar al Sistema de Resolucion denombres DNS, en el que cada companıa debe encajar en un unico nombre de dominio de primernivel, pudiendo crear por debajo multitud de nombres dependiendo de la estructura de serviciosde la empresa. En este sentido la organizacion de los nombres en una base de datos LDAP esmuy similar.

En una base de datos LDAP, la organizacion se estructura en forma de arbol, en el que existeuna raız o elemento superior que se crea en el momento de la instalacion (este parametro secorresponde cuando la configuracion del servidor nos preguntaba acerca de la raız del arbol). Pordebajo, se encuentran los elementos de informacion llamados nodos, los cuales deben pertenecera un tipo concreto. Este tipo, es llamado el elemento estructural del nodo, que en principio, notiene porque ser uno solamente, sino que pueden ser varios. Existen varios tipos predefinidos quepueden ser usados para representar elementos de informacion comunmente usados hoy en dıa:para almacenar la informacion de una persona, podemos usar el tipo person, para almacenar la



informacion de una cuenta de usuario en un sistema Unix, podemos usar el tipo posixAccount,mientras que para poder representar la informacion de un grupo en un sistema Unix, se facilitael tipo posixGroup. Una vez que el tipo de un nodo queda establecido, podemos asignar valoresa los atributos que nos facilita ese tipo estructural. Parece razonable que si un elementoposee el tipo posixAccount, se pueda saber el nombre de usuario, su UID, el grupo al quepertenece, su gecos, y seguramente algunos campos mas. Sin embargo, si un objeto posee laestructura posixGroup, seguramente nos baste con saber el nombre del grupo y su identificadornumerico.

Podemos decir que cada objeto que exista en el directorio LDAP va a constar de una serie detipos estructurales a los que pertenece, ademas de un nombre o identificador que va a posicionaral elemento en un punto concreto del directorio. Este nombre se denomina nombre distinguidoo distinguished name. Dependiendo del punto en el que se encuentre el objeto dentro del arbol,este tendra un dn diferente a otro. Normalmente, el dn se construye concatenando la sucesion denodos por los que es necesario pasar para poder llegar al objeto, de forma muy similar al serviciode nombres DNS.

Existen tipos predefinidos que se facilitan para poder agrupar elementos, y poder ası crearorganizaciones dentro del arbol. Normalmente, estos tipos reciben el nombre de unidadorganizativa o organizational unit. A traves de estos elementos estructurales, podremos agruparelementos finales (como cuentas de usuario, por ejemplo) en diferentes subarboles, como veremosa continuacion.

La jerarquıa de nuestro directorio LDAP

Una vez llegados a este punto, es necesario decidir como estara estructurado el directorioLDAP donde se encontraran las cuentas de los usuarios de nuestro sistema. Para empezar,debemos decidir cuales son las diferencias entre los tipos de usuario que vamos a almacenaren nuestro directorio, que se detallan a continuacion:

En primer lugar, necesitamos almacenar cuentas de usuario de dos tipos, fundamentalmente:estudiantes que cursan asignaturas (normalmente, pertenecientes a titulaciones de grado ypostgrado) y profesores que imparten estas asignaturas.

Los estudiantes pueden pertenecer al Campus de Mostoles (Escuelas de CienciasTecnologicas e Informatica) o al Campus de Fuenlabrada (Escuelas de Telecomunicaciony Facultad de Comunicacion Audiovisual).

Sin embargo, los profesores que imparten las asignaturas, suelen pertenecer al Campus deMostoles (al menos, su localizacion geografica se encuentra en Mostoles) y pueden impartirasignaturas en un campus, o en ambos.

Ademas, es preciso saber de cada alumno, el ano en el que obtuvo la cuenta, sin importar enprincipio la asignatura para la que la usa (ya que en cada carrera, suele usarse en diferentesasignaturas).

Con estas premisas, se ve claramente que los profesores, deben poder usar su cuenta en amboscampus (no se hace distincion entre los profesores de Fuenlabrada y los profesores de Mostoles)y que las cuentas de los alumnos de cada campus deben estar organizadas o separadas por elcampus al que pertenecen. Ademas, es muy probable que un profesor pueda acceder a recursos oa maquinas a las que no pueden acceder los alumnos estudiantes. Es por ello que una vez mas,deberemos separar muy bien esta organizacion en el esquema del arbol LDAP. Podemos ver unaprimera version de esta jerarquıa en la imagen 4.2. En ella vemos como la raız del arbol LDAP



contiene dos nodos principales, en los que se crean dos unidades organizativas: los alumnos porun 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 yprofesores.

Si nos centramos en la unidad organizativa de alumnos, debemos tener en cuenta que estospueden pertenecer a dos campus: al campus de Mostoles, o al campus de Fuenlabrada. Es porello, que decidimos de la misma forma representar esta division en el arbol LDAP en forma dedos 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 deMostoles y alumnos de Fuenlabrada.

Por el contrario, en el grupo de profesores, no es necesario realizar ninguna distincion adicional:podemos decir que todos los profesores se deben encontrar en el mismo nivel del arbol LDAP. Espor ello, que directamente agrupamos sus usuarios y grupos (objetos de las clases PosixAccounty PosixGroup) en el nivel de la unidad organizativa profesores que veıamos en la imagen 4.2.



Esta representacion se puede observar en la imagen 4.4.

ou=profesores,

dc=zipi,dc=escet,

dc=urjc,dc=es

ou=usuarios

(...)

ou=grupos

(...)

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

Configuracion de los clientes

Una vez que se ha configurado los servidores, es necesario pasar a configurar los clientespara que estos puedan autenticar a sus usarios mediante un directorio LDAP. Usando Ubuntu,solamente es necesario instalar un par de paquetes para disponer de las herramientas adecuadas.Estos paquetes son libnss-ldap y libpam-ldap, los cuales proveen de las bibliotecas oportunaspara poder autenticar a usuarios a traves de un directorio LDAP. La instalacion de estos paquetesen Ubuntu es inmediata y bastante simple, realizando una llamada al instalador de paquetes apt,como queda reflejado en el listado 4.23.

Listado 4.23: Instalacion de las bibliotecas necesarias para la autenticacion PAM vıa LDAP

$ apt -get install --assume -yes libnss -ldap libpam -ldap

Es posible que los paquetes instalados anteriormente requieran configuracion adicional, comopor ejemplo, la raız del arbol LDAP a partir del cual se buscaran los usuarios a autenticar. Ennuestro caso, vamos a responder a todas las preguntas por omision y a configurar estos datos deforma manual. En principio, para poder autenticar a los usuarios de un sistema Ubuntu medianteLDAP, es necesario configurar al menos los siguientes ficheros:

El fichero /etc/nsswitch.conf en el que se indicara que los datos de los usuarios y losgrupos proceden de una base de datos LDAP.

El fichero /etc/ldap/ldap.conf en el que se deben introducir los datos de conexion a losservidores LDAP (URIs de los servidores) y algun otro parametro, como por ejemplo si esnecesario establecer una conexion segura al servidor.

Los ficheros /etc/pam ldap.conf y /etc/libnss-ldap.conf, en los que es necesarioconfigurar entre otras cosas, los datos de conexion a los servidores LDAP, la raız del arbolLDAP a partir de la cual se deben buscar a los usuarios, y muchos otros parametros quepara nosotros seran transparentes.



Los ficheros de los modulos de autenticacion PAM, situados bajo el directorio /etc/pam.d/.En este directorio se situan los ficheros de configuracion de los modulos de autenticacion deusuario, en los que sera necesario indicar que la autenticacion se llevara a cabo medianteLDAP.

Vamos a ver de forma mas detallada los ficheros de configuracion mas importantes.

Fichero /etc/nsswitch.confEn este fichero se indica de donde provienen las bases de datos de los servicios mas importantes

del sistema, como los usuarios y los grupos. En nuestro caso, sera necesario anteponer la palabraLDAP para indicar que los datos de los usuarios y los grupos provienen de una base de datosLDAP, tal y como muestra el fichero 4.24.

Listado 4.24: Contenido del fichero nsswitch.conf para autenticacion vıa LDAP

passwd: files ldap

group: files ldap

shadow: files ldap

Fichero /etc/pam ldap.confEste fichero contiene la configuracion de PAM que accede a servicios de directorio LDAP. En

este fichero, los datos de configuracion mas importantes son las cadenas de conexion al servidorLDAP y la raiz del arbol a partir de la cual se empiezan a buscar usuarios. Podemos ver estaconfiguracion en el siguiente fragmento del fichero de configuracion mostrado en el listado delfichero 4.25.

Listado 4.25: Contenido del fichero pam ldap.conf para autenticacion vıa LDAP

uri ldaps :// peloto.escet.urjc.es

base dc=zipi ,dc=escet ,dc=urjc ,dc=es

ldap_version 3

bind_policy soft

fichero /etc/libnss-ldap.confEste fichero es bastante parecido al anterior, y contiene la informacion para poder acceder

a un servidor LDAP en el caso en el que se usen bases de datos LDAP en la base de datos delos servicios del sistema (Fichero nsswitch.conf). Las lıneas mas significativas de este fichero sonbastante parecidas al anterior, y se muestran en el listado del fichero 4.26.

Listado 4.26: Contenido del fichero libnss-ldap.conf para autenticacion vıa LDAP

uri ldaps :// peloto.escet.urjc.es

base dc=zipi ,dc=escet ,dc=urjc ,dc=es

ldap_version 3

bind_policy soft

Modulos de PAM bajo /etc/pam.d/Por ultimo, es necesario configurar todos los ficheros de autenticacion de PAM para que usen

la autenticacion bajo un directorio LDAP. Este directorio, contiene los ficheros necesarios para laautenticacion, ademas de un fichero por cada servicio que requiere autenticacion en el sistema (ssh,screensaver, gdm, etcetera). Debemos ser cuidadosos en el sentido de que si tenemos un servicioque requiere autenticacion pero no anadimos su fichero correspondiente en este directorio, eseservicio no podra autenticar vıa LDAP con nuestro servicio de autenticacion. Por ejemplo, si nose crea el servicio de autenticacion screensaver, cuando un usuario lance el salvapantallas en unasesion X y deje la pantalla bloqueada (es necesario introducir el nombre de usuario y la contrasena



para volver a retomar su sesion) no podra desbloquearla, puesto que el servicio salvapantallasno podra autenticar contra el servicio de autenticacion LDAP.

Migracion de cuentas NIS a LDAP

Un aspecto importante de la decision de implantacion de un servidor LDAP para laadministracion de cuentas de usuario es la seguridad de poder migrar la base de datos actualde usuarios (ahora mismo en NIS) a la base de datos LDAP. En el momento en el que se realiza lamigracion, el numero de usuarios en el sistema es aproximadamente de dos mil usuarios (solamenteen el Campus de Mostoles, que es el primero en el que se propone la migracion). Sin duda, nonos podemos plantear la migracion a la tecnologıa LDAP si no tenemos una herramienta queautomatice todo el proceso de migracion de cuentas (es impensable migrar dos mil cuentas deusuario a mano). Por eso, lo primero que debemos hacer es localizar una herramienta que puedatraducir el fichero actual de usuarios (recordamos que la una base de datos NIS es equivalentea los ficheros de usuarios /etc/passwd y /etc/shadow tradicionales) a una base de datos ofichero de importacion de datos de LDAP, un fichero LDIF15 que contendra todos los usuariosactuales y que unicamente tendremos que volcar en la base de datos LDAP.

Para esta tarea, se provee de unas herramientas muy utiles que nos ayudaran en la tarea dela migracion de un formato a otro. Una vez mas, este paquete se encuentra en la mayorıa de lasdistribuciones usadas hoy en dıa, y como no, en Debian GNU/Linux:

Listado 4.27: Instalacion del conjunto de herramientas migrationtools a traves de apt-get

$ apt -get install migrationtools

El uso de estas herramientas es realmente simple y muy potente. Las aplicaciones quedaninstaladas bajo el directorio /usr/share/migrationtools/. En este directorio podemos localizarel script migrate passwd.pl, el cual se encarga de transformar los ficheros /etc/passwd y/etc/shadow de la maquina donde ejecuta el script en el formato adecuado de una base dedatos LDAP: la salida, mostrada por pantalla, es un fichero LDIF que contiene los usuarios deestos ficheros transformados al formato correspondiente.

Con un poco de mano, podemos transformar este pequeno script escrito en Perl para quetome como argumentos ficheros pasados al invocar al programa, aumentando ası la versatibilidaddel mismo. Ademas, como vimos en el apartado anterior (Jerarquıa de nuestro servidor LDAP),podemos separar las cuentas entre los profesores y los alumnos, haciendo que para cada uno deellos, se muestre un nombre distinguido diferente. Estas operaciones auxiliares, se pueden realizarhaciendo uso de comandos estandar de Unix, como sed, awk, grep y cut.

Una vez que tenemos los datos de los usuarios almacenados en un fichero de intercambiode informacion LDAP (simplemente, redirigiendo la salida de la herramienta de migracion a unfichero) procedemos a la carga de este fichero en el servidor LDAP. Esta operacion, se realiza atraves de la herramienta ldapadd16, de la siguiente forma:

Listado 4.28: Modificando registros en el arbol LDAP usando ldapadd

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

En el comando, que sirve para anadir informacion a un servidor LDAP, se especifican lossiguientes parametros:

1. El modificador -x asume que la autenticacion es simple, en vez de usar el protocolo SASL.

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



2. La localizacion del servidor LDAP, especificado mediante una URI (identificador de recursouniversal).

3. Se pasa como parametro (-D) el nombre distinguido del usuario administrador, que es enese momento el que permite realizar escrituras en el arbol LDAP. En general el modificador-D sirve para atarse al servidor con un nombre de usuario concreto.

4. El modificador -W para que el comando pregunte de forma interactiva al usuario por sucontrasena o palabra de paso.

5. Y por ultimo, se pasa con el modificador -f, el nombre de fichero con los datos en formatoLDIF que se pretenden anadir al servidor.

La llamada al comando provocara que se muestre por la salida estandar un pequeno mensajepor cada nodo o entrada que se va anadiendo al arbol LDAP. En caso de error, este tambien semostrara, y dependera de como se haya invocado al comando la interrupcion inmediata o asumirla continua carga del fichero en el servidor para continuar o no la ejecucion.

Una vez concluido este paso, podemos decir que tenemos completamente migrada nuestrabase de datos de usuarios anterior (en formato NIS) a un servidor de directorio LDAP, por loque los clientes, ya seran capaces de autenticar con los usuarios actuales del sistema, a traves deun servidor de autenticacion LDAP. A partir de este momento, vamos a centrar nuestra tarea endotar al servidor de aspectos avanzados muy interesantes (y muchos de ellos indispensables) comoimplementar una conexion segura entre el servidor y los clientes (recordamos que ahora mismoel intercambio de informacion se realiza en texto claro), ademas de implementar la funcionalidadde reparto de carga y replicacion para aumentar la fiabilidad y seguridad del servicio.

Aspectos avanzados: Aumentando la seguridad

Ahora mismo, tenemos un entorno de autenticacion de usuarios bajo un directorio LDAPtotalmente funcional. Los usuarios podrıan autenticarse sin problemas en las estaciones clientes,con la misma contrasena que tuvieran antes (ya que hemos migrado la base de datos de usuariosy para el usuario final, la autenticacion es completamente transparente). Sin embargo, sinorealizamos ningun ajuste adicional, podrıamos tener problemas con usuarios maliciosos quetuvieran acceso a herramientas de escaneo de trafico en una interfaz de red determinada. Sinduda, esto en un entorno real empresarial, serıa difıcil que ocurriera. Sin embargo, en un entornouniversitario, en el que muchas de las practicas que se realizan tienen que ver con el analisisdel trafico de red de determinados protocolos, esto es completamente normal. En la figura 4.5se muestran los paquetes capturados en el momento en el que un usuario inicia una sesion enuna maquina. Vemos como bajo el protocolo LDAP, en el campo de datos del paquete TCPse muestran claramente el nombre de usuario y la contrasena del usuario en cuestion, lo quedemuestra que el esquema que nos hemos planteado hasta el momento adolece de problemas deseguridad bastante evidentes.

Por eso, no podemos poner en funcionamiento nuestro sistema todavıa sin antes estableceruna conexion segura entre los clientes y el servidor de autenticacion. Para poder completar estatarea, nos vemos obligados a la realizacion de los siguientes pasos:

Del lado del servidor, sera necesario la creacion de un certificado para poder establecer lacomunicacion usando los protocolos de seguridad SSL/TLS. Podemos crear el certificadode dos formas: la mas sencilla (en principio sera la que se usara en nuestro entorno, porsimplicidad) contempla la creacion de un certificado auto firmado. La forma mas complejacontempla el caso de que nuestro certificado sea firmado por una entidad certificadora (unaCA). Podemos usar este metodo tambien, siguiendo los siguientes pasos:



Figura 4.5: La aplicacion wireshark muestra como se mandan los datos de autenticacion en claroentre cliente y servidor, con nuestro esquema actual.

1. Creamos la entidad certificadora

2. Creamos el certificado

3. Firmamos el certificado mediante la entidad certificadora.

Sin embargo, por simplicidad (en principio, no dependemos de ninguna entidadcertificadora) usaremos un certificado auto firmado.

De cara a los clientes, deberemos modificar los parametros de conexion para que esta serealice a traves de otro puerto (el protocolo LDAP sobre SSL usa el puerto 636). En principioestas modificaciones en los clientes serıan mas que suficientes.

Creacion de un certificado auto firmadoPara llevar a cabo la creacion de un certificado auto firmado hemos de seguir los siguientes

pasos. En primer lugar, hemos de tener instaladas en nuestro sistema las herramientas relacionadascon la creacion de certificados SSL, provistas en su mayorıa por el paquete openssl. Lo instalamosde la forma habitual:

Listado 4.29: Instalacion del paquete openssl a traves de apt-get

$ apt -get install openssl

Una vez instalado el paquete, bajo el directorio /usr/lib/ssl/misc/ tenemos los scriptsnecesarios para nuestra tarea. El comando que deberemos lanzar para crear el certificado, es elsiguiente:

Listado 4.30: Creacion de un certificado para nuestro servidor LDAP

$ openssl req -newkey rsa :1024 -x509 -nodes -out server.pem -keyout server.pem -days 365

Entre los modificadores mas importantes de este comando, se encuentran donde se guardara elcertificado de salida (fichero server.pem), la duracion antes de que el certificado expire (365 dıas),



y el tamano de la clave (1024 bits). Una vez que invocamos el comando, este nos preguntara acercade la informacion que contendra el certificado. Es muy importante que cuando nos pregunte acercadel nombre comun o Common Name del certificado, escribamos exactamente el elemento raizdel arbol LDAP: en nuestro caso, recordamos que era dc=zipi,dc=escet,dc=urjc,dc=es. Si noescribimos literalmente esto, la conexion desde los clientes fallara. El resto de preguntas tienenque ver con la organizacion donde se usara, el correo de la persona responsable, etcetera.

Configuracion de OpenLDAP para el uso del certificadoUna vez que hemos creado el certificado (este se encuentra en el fichero server.pem)

debemos modificar la configuracion del servidor OpenLDAP para el uso del certificado, y queeste atienda peticiones a traves de un canal de comunicacion seguro (basado en SSL/TLS). Paraello, editamos el fichero /etc/ldap/slapd.conf, que es el fichero de configuracion del servidorLDAP, y anadimos al final del fichero las siguientes lıneas:

Listado 4.31: Lıneas necesarias para proporcionar soporte SSL al servidor LDAP

1 TLSCipherSuite HIGH:MEDIUM:-SSLv2

2 TLSCACertificateFile /etc/ldap/ssl/server.pem

3 TLSCertificateFile /etc/ldap/ssl/server.pem

4 TLSCertificateKeyFile /etc/ldap/ssl/server.pem

Hemos copiado el certificado del servidor a la localizacion /etc/ldap/ssl/. Por ultimo, esnecesario modificar las opciones de arranque del demonio LDAP para que cambie el puerto enel que atendera peticiones a partir de ahora. Este paso es muy simple, y se consigue editando elfichero /etc/default/slapd y anadiendo la lınea

Listado 4.32: Lıneas necesarias para proporcionar soporte SSL al servidor LDAP

1 SLAPD_SERVICES ="ldaps ://"

Donde la cadena ldaps:// indica que el protocolo de comunicacion usado se basara a partirde ahora en SSL/TLS. Si quisieramos tener ambos metodos de conexion disponibles (tanto segurocomo 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 usandoun canal seguro, dejaremos la opcion indicada como predeterminada. Una vez efectuados todosestos cambios, bastarıa reiniciar el servidor LDAP para que fueran aplicados:

Listado 4.33: Reinicio del demonio slapd

/etc/init.d/slapd restart

Podemos comprobar con ayuda de la herramienta nmap que el servidor LDAP se ha iniciadocorrectamente en el puerto SSL:

636/ tcp open ldapssl

Configuracion de los clientesLos cambios que se deben efectuar en los clientes para que efectuen una conexion al servidor

LDAP son realmente simples, y se basaran en la sustitucion de la cadena de conexion que especificala localizacion del servidor LDAP. Ası, debemos editar los siguientes ficheros:

En el fichero /etc/ldap/ldap.conf, sustituimos la cadena ldap:// por ldaps://

En los ficheros /etc/libpam ldap.conf y /etc/libnss-ldap.conf se realiza la mismamodificacion.



Ademas, en el fichero /etc/ldap/ldap.conf se anade la linea tls reqcert never para queno se compruebe el certificado del lado de los clientes. Si no anadimos esto, la conexionprobablemente fallarıa del lado del servidor, puesto que el cliente no le va a ofrecer ninguncertificado.

Figura 4.6: Una vez establecida la conexion segura entre cliente y servidor LDAP resulta masdifıcil capturar datos de autenticacion de usuarios.

Una vez realizadas todas las modificaciones, procedemos a realizar la misma prueba querealizamos antes. Apoyandonos en la herramienta wireshark, procedemos a autenticarnos enel sistema. Vemos como ahora el protocolo que se identifica es SSL/TLS, y que resultapracticamente imposible identificar cualquier campo del mensaje puesto que ahora se encuentrancifrados. Se puede observar en la imagen 4.6 como ahora resulta imposible identificar datos deusuarios analizando el trafico que pasa por el interfaz de red.

Aspectos avanzados: Reparto de carga

Vimos como en el capıtulo de diseno ıbamos a dedicar tres maquinas en el Campus de Mostolespara que dispusieran de servidor de directorio LDAP. Evidentemente, en esta configuracion, unade las maquinas servira la base de datos LDAP de forma primaria (lectura y escritura de datos) yel resto de las maquinas lo serviran de forma secundaria (solamente lectura). Esta configuracionnos permitira separar la carga de todos los laboratorios por maquinas (160 maquinas en un campusy 140 en otro es mucha carga para un unico servidor LDAP por campus), ademas de poder realizarreplicacion del servidor primario a los secundarios y disponer de la misma base de datos LDAPen diferentes localizaciones (de cara a que pudiera ocurrir una tragedia y necesitaramos accedera los datos de las cuentas).

La maquina principal en este esquema, tal y como vimos en el capitulo de Diseno, sera lamaquina peloto (con direccion IP 212.128.4.7) la cual se va a encargar de servir el directorioLDAP de forma primaria. Esto significa que siempre que se necesite realizar una escritura en eldirectorio (creacion de una cuenta o cambio de una contrasena) se debera realizar en el servidorLDAP de peloto. Por el contrario, las lecturas de datos (autenticacion de un usuario frente aldirectorio) se podran realizar en cualquiera de los servidores secundarios.



Las operaciones mas frecuentes en un directorio LDAP suelen ser de lectura, frente a lasoperaciones de escritura. Las creaciones de cuenta se suelen llevar a cabo una unica vez en todo elano (comienzo de curso) y los cambios de contrasena, aun siendo mas usuales que las operacionesde creacion de cuenta, representan un porcentaje totalmente despreciable frente al numero delecturas para autenticacion que se realizan.

peloto.escet.urjc.es212.128.4.7

Servidor LDAP Primario

zipi.escet.urjc.es212.128.4.2

Servidor LDAP Secundario (1)

zape.escet.urjc.es212.128.4.3

Servidor LDAPSecunario (2)

nano.cct.urjc.es193.147.73.55Servidor LDAPSecunario

(ETSIT Fuenlabrada)

Figura 4.7: Reparto de carga entre varios servidores LDAP.

El resto de maquinas que se disponen para servir el directorio LDAP de forma secundariason zipi (con direccion IP 212.128.4.2) y zape (con direccion IP 212.128.4.3), situadas estas dosmaquinas en el campus de Mostoles. En el campus de Fuenlabrada, disponemos de una solamaquina para la autenticacion, la maquina nano (con direccion IP 193.147.73.57). El numero deestaciones en cada campus (160 en Mostoles frente a 140 en Fuenlabrada) nos hace en principiodisponer de mas servidores de autenticacion en Mostoles que en Fuenlabrada, aunque se preveeque se instalen mas en el futuro en el campus de Fuenlabrada dado que el numero de estaciones enese campus esta aumentando considerablemente. La figura 4.7 muestra una imagen representativade la division en maquinas de los servidores que dispondran de servicio de autenticacion LDAP.

Cabe recordar en este punto, que las cuentas de usuario son las mismas para ambos campus(Mostoles y Fuenlabrada), por lo que si en principio el servidor de LDAP de Fuenlabrada deja deestar disponible por cualquier razon, las estaciones de este campus intentaran autenticar contracualquiera de los servidores de autenticacion instalados en el campus de Mostoles, sin ningun tipode problema.

Configuracion de los clientes para el reparto de carga

La configuracion de los clientes para que puedan conectarse a diferentes servidores LDAP encaso de que encuentren un fallo en alguno es realmente simple, y basta con anadir en los ficheros/etc/ldap/ldap.conf, /etc/libpam ldap.conf, y /etc/libnss-ldap.conf tantas cadenas deconexion como servidores tengamos disponibles. En nuestro caso, vamos a tener disponibles cuatroservidores que ofrezcan servicio de autenticacion vıa LDAP, que se identifican por su nombre dehost. Por tanto, las cadenas de conexion serıan las siguientes:



Listado 4.34: Lıneas necesarias para proporcionar soporte SSL al servidor LDAP1 ldaps :// peloto.escet.urjc.es

2 ldaps :// zipi.escet.urjc.es

3 ldaps :// zape.escet.urjc.es

4 ldaps :// nano.cct.urjc.es

Por tanto, bastarıa con anadir a estos ficheros la cadena

Listado 4.35: Lıneas necesarias para proporcionar soporte SSL al servidor LDAP1 ldaps :// peloto.escet.urjc.es ldaps :// zipi.escet.urjc.es

2 ldaps :// zape.escet.urjc.es ldaps :// nano.cct.urjc.es

Los clientes, cuando tuvieran que resolver una peticion de autenticacion, acudirıan al primerservidor en la lista de servidores disponibles, en este caso, a la maquina peloto. Si esta no seencontrara disponible, acudirıan al segundo recurso disponible, en este caso, la maquina zipi.Ası consecutivamente, hasta que lograran encontrar un servidor que no produjera fallo.

Evidentemente, esta configuracion no produce ningun reparto de carga (tal y como se hanescrito las direcciones de los servidores LDAP) puesto que todos los clientes, intentarıan siempreconectarse al servidor LDAP de peloto, posteriormente al de zipi, etcetera. Para que el repartode carga sea real, es necesario escribir los identificadores de las localizaciones de los servidores encada cliente en un orden determinado: ası conseguiremos realmente que cada laboratorio, porejemplo, intente autenticar siempre contra un servidor determinado, otro laboratorio contra otro,etcetera. Para ello, podemos realizar la siguiente configuracion. En Mostoles, decidimos que:

Las estaciones del laboratorio 108 intenten autenticarse siempre contra la maquina peloto,luego contra zipi, posteriormente contra zape y por ultimo contra nano.

Las estaciones del laboratorio 106 intentaran autenticarse en primer lugar contra zipi, luegocontra zape, a continuacion contra peloto y por ultimo contra nano.

Las estaciones del laboratorio 109 intentaran autenticarse en primer lugar contra zape, luegocontra zipi, posteriormente contra peloto, y por ultimo contra nano.

Por ultimo, las estaciones del laboratorio 111 intentaran autenticarse en primer lugar contrazipi, luego contra peloto, posteriormente contra zape y por ultimo contra nano.

Esta claro que nos interesa que el ultimo recurso a explorar en caso de que fallen los anteriores,es el servidor LDAP situado en el Campus de Fuenlabrada, debido a que geograficamente seencuentra mas lejos y provoca mas latencia en las conexiones y por tanto en el servicio deautenticacion. La configuracion para las estaciones del campus de Fuenlabrada podrıa ser muysimilar, y en este sentido:

Las estaciones del Laboratorio 004 intentaran autenticarse primero contra nano, luegocontra peloto, a continuacion contra zipi y por ultimo contra zape.

Las estaciones del Laboratorio 005 intentaran autenticarse primero contra nano, luegocontra zipi, posteriormente contra zape y por ultimo contra peloto.

Las estaciones del Laboratorio del Seminario 5 intentaran autenticarse primero contra nano,luego contra zape, posteriormente contra zipi y por ultimo contra peloto.

Esta claro que en este Campus primero se intente la conexion contra el servidor mas cercano,en este caso, la maquina nano. A continuacion, se plantean diversos ordenes de conexion a losservidores adicionales, en caso de que falle el principal, para poder repartir adecuadamente lacarga entre todos los posibles servidores disponibles.



Aspectos avanzados: Replicacion

No sirve de nada tener varios servidores disponibles para realizar reparto de carga en laautenticacion si no existe coherencia entre ellos. La decision de dividir la carga en variosservidores, supone ademas, que debemos establecer un mecanismo que permita que cuando serealice un cambio en el servidor primario (el de la maquina peloto) este cambio se vea reflejadoautomaticamente en todos los servidores secundarios. No tendrıa ningun sentido que existieranvarios servidores para la autenticacion pero que los datos no estuvieran exactamente replicadosdesde el servidor primario hasta los secundarios.

Afortunadamente, la aplicacion OpenLDAP provee de un mecanismo para que esto sea posible.La utilidad slurpd establece un mecanismo para replicar todos los cambios que se efectuen en unservidor LDAP primario. Para ello, y en primer lugar, debemos instalar esta aplicacion en todoslos servidores LDAP de los que disponemos actualmente. Para ello, hacemos uso de la herramientade instalacion de software en Debian:

Listado 4.36: Instalacion del demonio slurpd con apt-get

$ apt -get install slurpd

Debemos instalar esta utilidad en las maquinas peloto, zipi y zape. Una vez realizado estepaso, debemos aplicar algunos cambios a la configuracion inicial que tenemos en este momento,que contemple las siguientes acciones:

Solamente se podran realizar cambios en la maquina peloto, que es la que alberga el servidorLDAP primario.

Cuando se intente realizar algun cambio en el directorio LDAP de las maquinas zipi, zapeo nano, esta modificacion se redireccionara a la maquina peloto, que es la que atendera esapeticion.

Un cambio en el directorio LDAP de la maquina peloto produce una reaccion en cadenade cambios sobre las maquinas zipi, zape y nano, de forma que su directorio LDAP quedeautomaticamente sincronizado con el de la maquina peloto.

Esta configuracion se lleva a cabo siguiendo los siguientes pasos.Cambios necesarios en el servidor LDAP primarioEn primer lugar, en la maquina peloto es necesario indicar donde esta el fichero de log de

replicacion, para a continuacion indicar cada una de las replicas en las que vamos a propagar loscambios que se efectuen en nuestro directorio LDAP. Para ello, es necesario incluir las siguienteslıneas:

Listado 4.37: Anadiendo replicacion a nuestro servidor LDAP

1 replogfile /var/lib/ldap/replog

2

3 replica uri=ldaps :// zipi.escet.urjc.es

4 binddn ="cn=replicator ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

5 bindmethod=simple credentials=replicator

6

7 replica uri=ldaps :// zape.escet.urjc.es



10

11 replica uri=ldaps :// nano.cct.urjc.es





Como vemos, por cada servidor LDAP secundario es necesario indicar una directiva replicacon los parametros de conexion necesarios. Como se puede apreciar, se especifica la localizaciondel servidor mediante la directiva uri y el usuario al que se debe atar para propagar el cambio, eneste caso, el usuario replicator. Previamente, debemos haber creado este usuario en el servidorLDAP primario.

Cambios necesarios en los servidores LDAP secundarios

En cada una de las maquinas que albergan un servidor LDAP secundario (esto es, las maquinaszipi, zape y nano, debemos aplicar estos cambios. Estos cambios quedan descritos aplicando estaslıneas en cada uno de los ficheros de configuracion del servidor LDAP de la maquina (fichero/etc/ldap/slapd.conf :

Listado 4.38: Anadiendo replicacion a nuestro servidor LDAP

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

14 by * read

15

16 updatedn "cn=replicator ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

17 updateref ldaps :// peloto.escet.urjc.es

Como vemos, se especifica que el usuario propietario del nombre distinguidodn=cn=replicator,dc=zipi,dc=escet,dc=urjc,dc=es tendra acceso para escribir. El restode usuarios, solamente tendran acceso de lectura. Ademas, las dos ultimas lıneas indican quesolamente se pueden realizar actualizaciones de datos mediante el nombre distinguido anterior, yque cualquier otra modificacion por cualquier otro usuario debe devolver un error (indicando queno se puede escribir en el directorio) remitiendo a la direccion del servidor LDAP primario quesı admite modificaciones de escritura en el directorio. Esta lınea es muy interesante, sobre todocon respecto a los clientes. Vimos en el apartado anterior, Reparto de carga, que se especificabanlas cadenas de conexion a los diferentes servidores en diferente orden para poder ası repartir lacarga entre todos los servidores disponibles. Bien, ¿que ocurrirıa si un cliente tiene como primerservidor disponible un servidor LDAP secundario, que no admite modificaciones y recibe unapeticion para un cambio de contrasena? Podrıa pensarse que se remitirıa a un error, debido aque ese servidor LDAP no admite ninguna operacion de escritura en su directorio (a no ser queprovengan de un servidor LDAP primario). Pues bien, realmente cuando ocurre esta situacion,el servidor LDAP secundario devueve la cadena de conexion al servidor LDAP primario, y esahı entonces donde se realiza la modificacion. Evidentemente, si este no estuviera disponible,sı que se producirıa un error y la operacion de cambio de contrasena no podrıa llevarse a cabo.

Llegados a este punto, hemos conseguido completar una compleja configuracion de servidoresde autenticacion bastante fiable, con reparto de carga (no saturaremos a un servidor con todaslas peticiones de todas las estaciones) y en las que el fallo de una maquina no supone la caida delservicio de autenticacion.

Copias de seguridad

Un aspecto muy importante de cara a la recuperacion del servicio en caso de error, es lacontinua gestion de copias de seguridad de los datos del directorio. En en el diseno que nosocupa, en el que manejamos cuatro servidores LDAP diferentes, resulta bastante interesante querealicemos copias de seguridad de nuestros datos en cada uno de ellos, y que esas copias sesincronicen finalmente en otro servidor diferente. Para ello, podemos hacer uso de la utilidadslapcat, la cual ejecutada en cada uno de los servidores LDAP provocara que se vuelque enformato texto el directorio LDAP por la salida estandar. Simplemente redirigiendolo a un fichero,tendrıamos suficiente. Podrıamos escribir un script de este estilo, para realizar esta tarea, tal ycomo se muestra en el script mostrado en el listado 4.39.



Listado 4.39: Copia de Seguridad de los datos del servidor LDAP

1 #!/ bin/bash

2

3 DATE=‘date + %F‘

4

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

Siempre es conveniente que cuando hagamos uso de la herramienta slapcat, se detenga elservicio LDAP para evitar inconsistencias en la base de datos cuando se realiza el volcado. Elanterior script se encuentra escrito en bash, y unicamente invoca al comando slapd para guardarsu resultado en un fichero comprimido, con la fecha (ano, mes y dıa) de la copia de seguridad.Este script, al que denominaremos backup ldap.py, se ejecutara en todas aquellas maquinasque dispongan de un servidor LDAP, de forma diaria. Para ello, podemos incluir la siguiente lıneade cron en las maquinas peloto, zipi, zape y nano:

Listado 4.40: Lınea de cron para automatizar las copias de seguridad de LDAP

00 00 * * * /root/bin/backup -ldap.sh

A traves de la cual ejecutara todos los dıas a las 00:00h la utilidad de copia de seguridaddel directorio LDAP. Podemos combinar este script con otras tecnicas, como por ejemplo, cada15 dıas guardar los datos en un soporte magnetico, como cinta, o CD, etcetera. Sin duda serecomienda cada cierto tiempo volcar todos los datos a un soporte de forma que se encuentrenfuera de cada uno de los servidores, por lo que pudiera pasar.

Herramientas de Gestion del directorio LDAP

Una vez puesto en marcha todo el sistema, es necesario disponer de herramientas adecuadaspara poder administrar facilmente el directorio LDAP. En nuestro caso, como solamente va aser usado para autenticacion de usuarios, hemos de disponer de las herramientas necesarias quenos permitan anadir, eliminar y modificar usuarios existentes en la base de datos. Normalmente,cuando se instala un servidor de directorio LDAP, resulta casi fundamental instalar junto a el lasherramientas ldap-utils, que proveen de utilidades para gestionar adecuadamente el directorio.En concreto, son herramientas que permiten anadir (ldapadd), modificar datos del directorio(ldapmodify) y poder borrar (ldapdelete). Sin embargo, usar estas herramientas en lınea decomandos directamente, sin usar por encima scripts que se apoyen en estas herramientas, puederesultar un poco tosco. Por eso, aparte de haber desarrollado una aplicacion propia para lagestion de los usuarios del sistema, hemos instalado una aplicacion web para poder administrarel directorio facilmente. No obstante, usaremos utilidades en lınea de comandos si nuestro fin espoder realizar un pequeno cambio (por ejemplo, cambiar una contrasena) en el sistema de formarapida y simple. Vamos a ver cada una de ellas de forma breve.

PHPLdapAdmin

La aplicacion PHPLdapAdmin17 es una aplicacion libre y gratuita que permite gestionar atraves de un interfaz web un conjunto de servidores LDAP. Ademas de eso, obviamente, permiteanadir, borrar y modificar datos del directorio LDAP. Esta herramienta es muy comoda desdeel punto de vista que permite ver de una pasada rapida cual es el estado de los servidoresLDAP en un momento determinado, ademas de poder ver en forma de arbol la estructura delmismo. Ademas, permite anadir usuarios con estructura posixAccount (muy util para cambiarcontrasenas) y permite localizar a un usuario rapidamente. En la imagen 4.8 se puede ver esta

17http://phpldapadmin.sourceforge.net/



Figura 4.8: La aplicacion PHPLdapAdmin sobre nuestro esquema de servidores.

aplicacion funcionando en nuestro entorno de servidores LDAP18. Esta aplicacion la usaremospara localizar rapidamente un objeto en el LDAP y poder realizar una modificacion sobre el, noobstante, esta pensada para ser usada solamente sobre los usuarios administradores del entorno,ya que desde el punto de vista de su gestion puede resultar un poco tecnica. En principio, serecomienda que los profesores, que muy a menudo se ven obligados a cambiar contrasenas y crearcuentas para sus alumnos, usen la herramienta propia de gestion de usuarios del Laboratorio19

La instalacion de configuracion de PHPLdapAdmin es bastante simple, estando disponiblecomo paquete en la mayorıa de las distribuciones mas usadas hoy en dıa. Posteriormente, despuesde instalar la herramienta, se debe configurar con los parametros de los servidores a los cuales sedesea poder acceder desde la administracion web. En este documento no se describira la instalaciony posterior configuracion de la herramienta por existir multitud de documentos que se encargande ello20 .

Aplicaciones en lınea de comandos

Aparte de las herramientas graficas de gestion del directorio y de los servidores LDAP, siempreviene bien tener disponibles herramientas en lınea de comandos para la gestion del directorio deforma eficiente y simple. Estas herramientas, estan provistas por el paquete ldap-utils, comose ha comentado antes. Normalmente, las herramientas ldapadd y ldapdelete se suelen usara traves de herramientas de nivel superior, ya que tanto los parametros que requieren como losformatos de ficheros que usan para intercambiar datos con el servidor LDAP (formato LDIF)suele ser bastante complejo.

En nuestro caso, solamente usaremos la herramienta ldappassword para poder cambiar lacontrasena de un usuario en lınea de comandos rapidamente. La sintaxis de este comando esbien sencilla, mostrandose un ejemplo a continuacion. Supongamos que queremos cambiar lacontrasena a un usuario cuyo nombre de usuario es agutierr, sabiendo que su cuenta se encuentra

18Se puede acceder a la gestion del LDAP desde la URL https://minervo.escet.urjc.es/ldapadmin desde la Intranetde la Universidad.

19Esta aplicacion se encuentra en la URL https://pantuflo.escet.urjc.es/admin20En la pagina web del proyecto (http://phpldapadmin.wiki.sourceforge.net/Documentation) se puede encontrar

abundante informacion sobre la instalacion y personalizacion de la herramienta.



situada en el subarbol de profesores del directorio LDAP. Sencillamente, escribirıamos lo siguiente:

Listado 4.41: Modificando la contrasena de un usuario usando ldappasswd

$ ldappasswd -x -H ldaps :// peloto.escet.urjc.es -D ’cn=admin ,dc=zipi ,dc=escet ,dc=urjc ,dc=es ’

-W ’uid=agutierr ,ou=usuarios ,ou=profesores ,dc=zipi ,dc=escet ,dc=urjc ,dc=es ’

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

4.2.2. Servidor NFS de ficheros en red

En este punto, podemos decir que uno de los hitos fundamentales que querıamos conseguiren nuestro sistema, ya lo hemos logrado: dar el salto a una tecnologıa punta como es hoy en dıaLDAP, aumentar la seguridad de la autenticacion de los usuarios en el sistema, como ha quedadodemostrado, ademas de dotar al entorno de una fiabilidad y rendimiento optimos. A continuacion,se nos presenta como reto dotar al sistema de un servicio de ficheros en red capaz de soportartoda la carga del entorno, ademas de disponga de espacio suficiente para poder almacenar deforma amplia un numero aproximado de tres mil cuentas de usuario, con sus correspondientescarpetas personales.

La opcion unica clara que se presenta es el uso del sistema de ficheros NFS21, un sistemade ficheros en entornos Unix que permite acceder a ficheros y diretorios remotos como si fueranficheros locales. En Unix/Linux esto es posible gracias a una mezcla de funcionalidad en el mismokernel de Linux en la maquina cliente y un demonio en el servidor, mezclado todo con llamadasRPC22 entre el cliente y el servidor (NIS tambien funciona con RPC).

El servidor de NFS, exporta un conjunto de directorios (uno o mas) de forma remota a todosaquellos clientes que deseen montar ese directorio. Por otro lado, los clientes montan ese directoriovıa NFS en su sistema de ficheros local. La sintaxis para montar un directorio vıa NFS no es muydiferente a la que que se usa para montar directorios locales, mas que anadiendo la maquina quealberga el servidor NFS y el directorio que se desea montar. Como vimos en el capıtulo de diseno,la maquina que albergara el servidor NFS para el Campus de Mostoles, sera la maquina lechuzo(con direccion IP 212.128.4.8), y exportara el directorio /disks/raid/homes.mostoles de caraa los clientes, las estaciones del Laboratorio. Ası, para poder montar remotamente los directoriospersonales de los alumnos en una estacion cliente, tendrıamos que introducir:

$ mount -t nfs lechuzo.escet.urjc.es:/ disks/raid/homes. mostoles /home

De forma que en el directorio /home de los clientes, quedarıa montado el directorioremoto /disks/raid/homes.mostoles/ del servidor. El uso de este directorio, serıa totalmentetransparente para los usuarios de las estaciones, que lo usarıan como si de un directorio local setratara. Evidentemente, la tarea de montar el servidor de homes esta automatizada en el arranquede las estaciones del laboratorio. Esto se consigue anadiendo una lınea al fichero /etc/fstab quecontiene los montajes remotos que se desea iniciar en el inicio del sistema:

lechuzo.escet.urjc.es:/disks/raid/homes.mostoles/ /home nfs rw

,rsize =8192, wsize =8192, udp

Esta lınea contiene algo mas de informacion que la anterior. Las opciones mas interesantesson las opciones rw, y la opcion udp, que monta el directorio del servidor usando el protocolo de

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



transporte udp. Resulta razonable en una red local como la que nos ocupa usar este protocolo,ya que suponemos que se producen pocas perdidas y los tiempos de respuesta son en su mayorıabajos.

Por otro lado, en el servidor, deberıamos tener disponible el demonio de NFS, provisto por elpaquete nfs-kernel-server:

Listado 4.42: Instalacion del servidor NFS a traves de apt-get

$ apt -get install nfs -kernel -server

Configuracion del servidorLa configuracion del servidor de NFS unicamente contempla el seleccionar el directorio que se

desea exportar de cara a los clientes. Esta configuracion se lleva a cabo en el fichero /etc/exports.Para cada directorio exportado, se debe seleccionar el rango de direcciones IP a los que se lespermite usar o montar ese recurso. En este momento, NFS no dispone de ningun mecanismo deautenticacion que no sea permitir o denegar el montaje del recurso ateniendo a la direccion IPdel cliente. Vemos un fragmento del fichero de configuracion a continuacion:

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

En efecto, esto supone muchos problemas de seguridad de cara a los clientes a los quepermitimos montar el recurso, y en los que confiamos. En principio, cualquier persona que usarauna direccion IP del laboratorio (con su ordenador portatil, por ejemplo) serıa capaz de montarel recurso NFS sin mayor dificultad. Las operaciones que pueda realizar en ese momento con esedirectorio dependen unicamente de las opciones que se hayan marcado en el directorio exportadoen el servidor:

Si el recurso se ha exportado con la opcion no root squash, las operaciones a nombre delusuario root en la maquina local se traduciran como operaciones con el usuario root en lamaquina servidor.

Por el contrario, si se ha exportado el directorio con la opcion root squash, las operacionesa nombre del usuario root en la maquina local se traduciran como operaciones anombre del usuario nobody en la maquina remota, y por tanto, este usuario solamentetendra privilegios sobre aquellos ficheros que tenga a su nombre.

Aun ası, estando el recurso exportado con la opcion root squash, un usuario root local notendrıa privilegios sobre nada que no este a su nombre, pero nada impide que intercambiandosu id de usuario acceda a todos los ficheros para los que no tenga privilegios. Vemos por tanto,que las opciones son bastante poco esperanzadoras, en cuanto a seguridad se refiere. Ademas deno poder autenticar a los clientes, excepto confiar en ellos a traves de su direccion IP, es posibleacceder en modo lectura y escritura con privilegios desde cualquier cliente y modificar los ficherosde cualquier usuario al antojo del atacante, sin mas que escribir unos cuantos comandos de shell.

Como se puede deducir, NFS hoy en dıa adolece de graves problemas de seguridad que demomento, y debido a la estructura del kernel de Linux, no esta a la vista ser corregidos, pero hoyen dıa representa la unica opcion medianamente usable en cuanto a rendimiento y fiabilidad.

RAID de disco

En un sistema en el que se tienen aproximadamente tres mil cuentas de usuario, resultaimprescindible disponer de una tecnologıa que permita aunar gran cantidad de espacio en disco



como si se tratara de un solo dispositivo. Como vimos en el capıtulo de diseno, vamos a haceruso de la maquinas lechuzo y sapientin en el Campus de Mostoles para albergar por un ladolos directorios personales de los usuarios (directorios HOMES) y por otro lado, una copia deseguridad exacta de estos directorios, para que en caso de fallo de algun disco de la primera, sepueda sustituir esta rapidamente (sin mas que cambiar su direccion IP) y no dejar sin servicio alos laboratorios.

Discos disponibles

En principio, la configuracion de hardware de las maquinas lechuzo y sapientin no tienenporque ser similares, siendo recomendable unicamente que la segunda tenga al menos el mismotamano de espacio en disco que la primera. Incluso, la configuracion del RAID puede variar, noteniendo porque estar configuradas en el mismo nivel.

En la maquina lechuzo, disponemos de cinco discos duros disponibles, de diferentes tamanos,tal y como muestra la tabla 4.1. El espacio total sumado entre todos los discos alcanza los 830GB, aproximadamente.

Disco duro Tamano Particion principal

/dev/hdb 400 GB /dev/hdb1

/dev/hde 163 GB /dev/hde1

/dev/hdi 163 GB /dev/hdi1

/dev/hdm 163 GB /dev/hdm1

Cuadro 4.1: Discos duros de la maquina lechuzo

Analogamente, en la maquina sapientin, destinada a albergar las copias de seguridad de losdirectorios personales de los usuarios, disponemos de seis discos duros (sin contar el dedicado ala particion del sistema) de 120 GB de tamano cada uno. El tamano total es aproximadamentede 500 GB, para copias de seguridad.

Configuracion del raid en Linux

Dispuestos los discos duros que van a ser dedicados en cada maquina a albergar los directoriospersonales de los usuarios (maquina principal y copias de seguridad) debemos configurar un raidpor software bajo Linux, para poder acceder a todos los discos como si de unico dispositivose tratara. Las herramientas adecuadas que disponen de esta funcionalidad bajo Linux vienenprovistas por el paquete mdadm, cuya instalacion se puede completar usando el gestor depaquetes de Debian (recordamos que en el capıtulo de Diseno establecimos que la distribucion ausar en los servidores, iba a ser Debian GNU/Linux):

Listado 4.43: Instalacion del gestor de raid mdadm usando apt-get

$ apt -get install mdadm

La herramienta mdadm es una utilidad para Linux que permite administrar (anadir, borrary modificar) raids de disco que funcionen por software (en ausencia de una controladora hardwarededicada). El nombre de la aplicacion mdadm viene de multiple disks. La herramienta mdadmse distribuye bajo la licencia GNU/GPL.

Lo primero que debemos hacer para configurar el RAID de disco, es formatear los discosusando el sistema de ficheros ext3. Si previamente, los discos no tenıan ninguna particion creada,debemos crearla haciendo uso de las herramientas fdisk o cfdisk. Una vez que hemos creado lasparticiones correspondientes, podemos formatearlas usando el sistema de ficheros ext3 invocandoel programa mkfs.ext3:



Listado 4.44: Automatizacion en la creacion del raid

$ for i in ‘echo b e i m‘; do mfks.ext3 /dev/hd$i1; done

De esta forma, formateamos las cuatro particiones en lechuzo de forma totalmente automatica.Lo mismo podemos hacer en la maquina sapientin:

Listado 4.45: Automatizacion en la creacion del RAID

$ for i in ‘echo e g i k m‘; do mkfs.ext3 /dev/hd$i1; done

Concluida esta operacion, podemos crear el RAID de disco deseado.

Niveles de RAID usados

Un dispositivo RAID puede ser configurado en diferentes niveles, dependiendo de laconfiguracion mas optima para el entorno. Para ilustrar diferentes configuraciones de RAID,vamos a usar el nivel cero (tambien llamada configuracion en tiras) en la maquina lechuzo y laconfiguracion de nivel cinco (disco en redundancia o disco spare) en la maquina sapientin. Desdeel punto de vista del espacio en disco, la configuracion mas optima es la configuracion en tiras,que aprovecha al maximo el uso de cada disco: el tamano total del RAID es la resultante demultiplicar el espacio disponible en cada uno de los discos por el numero de discos. Sin embargo,si se produce un error en uno de los discos, el RAID quedara totalmente inutilizable, y sera precisohacer uso de la copia de seguridad.

La configuracion en nivel cinco, o con redundancia, hace uso de un disco para almacenarredundancias entre la informacion, de forma que si se produce un error en alguno de los discos,nos podremos recuperar de la informacion en caliente, sin mas que cambiar el disco defectuoso.Como en principio, disponemos de dos maquinas, vamos a hacer uso de ambas configuracionespara poder disponer de cada las dos ventajas por el mismo precio.

Para la creacion del RAID hacemos uso de la herramienta mdadm de la siguiente forma:

$ mdadm --create /dev/md0 --level -raid 0 --raid -devices 4 /dev/hd[beim]1

En la maquina lechuzo. El dispositivo final /dev/md0 en esta maquina albergara el raid dedisco que podra ser considerado como si de un solo disco se tratara. En el comando expuesto, seindica que se desea aplicar un nivel de raid cero, con cuatro discos, indicando por supuesto quediscos se desea anadir al raid. De la misma forma, en la maquina sapientin,

$ mdadm --create /dev/md0 --level -raid 5 --raid -devices 5 /dev/hd[egikm ]1 --spare -devices /dev/hdo1

En este caso, se desea aplicar una configuracion de RAID con redundancia, y por tanto esnecesario indicar mediante el parametro –spare-devices que disco se desea usar para almacenaresta redundancia. Despues de aplicar estas operaciones, debemos tener en ambas maquinas ybajo el directorio /dev/md0 los respectivos dispositivos raid. Usando la propia herramienta dediagnostico del paquete podemos comprobar el estado de cada uno de los raids:

lechuzo :~# mdadm -D /dev/md0

/dev/md0:

Version : 00.90.03

Creation Time : Sun Jun 24 21:24:00 2007

Raid Level : raid0

Array Size : 870947392 (830.60 GiB 891.85 GB)

Raid Devices : 4

Total Devices : 4

Preferred Minor : 0

Persistence : Superblock is persistent



Update Time : Sun Jun 24 21:24:00 2007

State : clean

Active Devices : 4

Working Devices : 4

Failed Devices : 0

Spare Devices : 0

Chunk Size : 64K

UUID : 4838047a:31901 cef :88217 ab2 :99168 cf3

Events : 0.1

Number Major Minor RaidDevice State

0 3 65 0 active sync /dev/hdb1

1 33 1 1 active sync /dev/hde1

2 56 1 2 active sync /dev/hdi1

3 88 1 3 active sync /dev/hdm1

Que nos indica que el estado es correcto (clean), que existen cuatro dispositivos activos yfuncionando, el tamano total del dispositivo raid, ademas de las fechas de creacion, actualizaciony de los dispositivos fısicos de los que se compone el raid. De la misma forma en la maquinasapientin, podemos observar la misma informacion:

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 : Mon Feb 25 07:52:35 2008

State : clean

Active Devices : 5

Working Devices : 6

Failed Devices : 0

Spare Devices : 1

Layout : left -symmetric

Chunk Size : 64K

UUID : c8a8661f :758 a1942 :83 ba8395:dd3064ca

Events : 0.7129708

Number Major Minor RaidDevice State

0 33 1 0 active sync /dev/hde1

1 34 1 1 active sync /dev/hdg1

2 56 1 2 active sync /dev/hdi1

3 57 1 3 active sync /dev/hdk1

4 88 1 4 active sync /dev/hdm1

5 89 0 - spare /dev/hdo

Ahora podemos tratar todos estos discos como si de un unico se tratara, por lo que (aunqueno es obligatorio) se recomienda formatear esta nueva particion en el formato de ficheros elegido,en nuestro caso, el sistema de ficheros ext3:

$ mkfs.ext3 /dev/md0

Ejecutado en ambas maquinas, formateara los dispositivos para que puedan ser montados apartir de ese momento en el sistema. Unicamente nos queda montar los directorios bajo el punto



de montaje elegido: /disks/raid/homes.mostoles/:

$ mount /dev/md0 /disks/raid/homes.mostoles/

Y por ultimo, reiniciar el demonio NFS en ambas maquinas para que los recursos estendisponibles a todas las estaciones del Laboratorio:

$ /etc/init.d/nfs -kernel -server restart

Configuracion del RAID en los servidores del Campus de Fuenlabrada

La configuracion del RAID para los servidores del Campus de Fuenlabrada (bilo y nano) esmuy similar a la creacion del RAID para los servidores de disco del Campus de Mostoles. Enconcreto, usaremos nivel de raid cero (configuracion en tiras) en ambas maquinas. Como vimosen el capıtulo de diseno, la maquina bilo albergara el RAID que contendra los ficheros personalesde los usuarios de ese campus (como servidor principal) y la maqina nano albergara las copias deseguridad de dichos ficheros.

4.2.3. Servidor Web de los Laboratorios

Como vimos en el capıtulo de Diseno, en los Laboratorios (tanto de los Campus de Mostolescomo de Fuenlabrada) instalaremos un servidor web en una de las maquinas, que cubrira dosfuncionalidades principalmente:

Instalar una pagina principal que sirva para informar a los alumnos de las instalaciones, losprocedimientos principales (apertura de cuenta, cambio de contrasena, etcetera), una seriede tutoriales (conectar al laboratorio desde casa, configurar el correo electronico, etcetera).

Que los propios alumnos puedan configurar una pequena pagina personal, con la informacionacademica que deseen (normalmente los alumnos usan este medio para proporcionarinformacion sobre su persona y sus intereses profesionales).

Para poder implementar este servicio, instalaremos un servidor web en uno de los servidoresvisibles de cada uno de los Campus. En el campus de Mostoles, cuando los Laboratorioscomenzaron a funcionar, siempre se uso la maquina pantuflo para esta tarea. Como vimosen el capıtulo de Especificacion y Diseno, la maquina pantuflo implementa la tarea de ser lacabeza visible de los Laboratorios. Proporciona, ademas de servidor web, servidor de correoelectronico para los usuarios, listas de correo, etcetera. Por tanto, usaremos la direccionpantuflo.escet.urjc.es para instalar la pagina web del Laboratorio. Para las paginas personalesde los usuarios, usaremos la notacion tradicional de paginas web en un entorno Unix/Linux, esdecir, el nombre del host, seguido del caracter y el nombre del usuario. Ası, si mi nombrede usuario es agutierr, la URL que harıa referencia a mi espacio web en el servidor serıahttp://pantuflo.escet.urjc.es/agutierr/. De la misma forma, en el Campus de Fuenlabradatambien dispondremos de un servidor web que servira de pagina principal del Laboratorio.La maquina encargada de albergar este servidor (y por tanto la pagina del Laboratorioen Fuenlabrada) sera la maquina bilo, siendo la URL principal del Laboratorio la direccionhttp://bilo.cct.urjc.es/.

A continuacion vamos a ver como configurar rapidamente un gestor de contenidos para elLaboratorio, que permita editar, anadir y borrar contenido de forma facil e intuitiva (incluso, quepermita a los docentes hacerlo) y como configurar el servidor web para que permita a los usuariosgestionar sus paginas personales.



Pagina principal del Laboratorio

Desde el punto de vista informativo y corporativo, siempre resulta interesante comoorganizacion disponer de una pagina web de informacion, de cara al resto del mundo, que losalumnos o los visitantes puedan utilizar para saber cual es el regimen de funcionamiento internodel Laboratorio, ası como otra informacion muy interesante de cara a los usuarios finales delentorno. Es por ello que una de nuestras tareas sera instalar un servidor web que nos permitaconfigurar un gestor de contenidos para el Laboratorio.

Un servidor web es un programa que implementa el protocolo HTTP23. Este protocoloesta disenado para transferir lo que llamamos paginas web o paginas en formato HTML24. Sinembargo, es importante resenar que HTTP hace referencia al protocolo que permite el visionadode documentos escritos en HTML. Un servidor web, se encarga de mantenerse a la espera depeticiones HTTP que les llegan desde los clientes (normalmente, un navegador, como Firefox,Opera, Safari, etcetera). El navegador, realiza una peticion al servidor y este le responde con elcontenido que este solicita. Existen multitud de programas que implementan un servidor web,siendo uno de los mas conocidos en entornos Unix/Linux el servidor web Apache.

Versiones de Apache

Hoy en dıa, existen dos versiones principales de Apache: la version 1.3 y la version 2. Enel entorno en el que nos encontramos, instalaremos ambas. Ambas siguen en desarrollo, y lasprincipales ventajas de la version 2 sobre la version 1 radica en una mejora en las implementacionesque mejoran sustancialmente el rendimiento (en plataformas no Unix sobre todo), centrandoseen la modularizacion del servidor. En nuestro entorno, usaremos las dos, principalmente por dosrazones:

Existen modulos que solo estan disponibles para la version 1 (como es el caso del modulode PHP5)

Existen modulos que solo estan disponibles para la version 2 (como es el caso del modulode Webdav y Subversion)

Instalacion

La instalacion en Debian GNU/Linux de Apache (tanto en la version 1 como en la version 2) esrealmente sencilla e intuitiva. En primer lugar instalaremos Apache 1 con los modulos necesarios,en este caso, el modulo de PHP5.

Listado 4.46: Instalacion de Apache y del modulo PHP5 para el servidor

$ apt -get install apache libapache -mod -php5

Despues de responder a unas preguntas relativas a la configuracion del paquete, lomas probable es que el software se haya instalado correctamente, y ya podamos acudira la direccion principal para poder ver una pagina de prueba. Por tanto, en la direccionhttp://pantuflo.escet.urjc.es/ (y respectivamente, a la del Campus de Fuenlabrada) podemosver la pagina de prueba que nos deja Apache nada mas ser instalado.

A continuacion, vamos a instalar el servidor web Apache en su version 2, junto con el modulode Webdav/Subversion. Este modulo nos permitira acceder a repositorios Subversion dentro delservidor pantuflo, en ocasiones usado por alumnos para versionar el codigo fuente de sus practicas.

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



Listado 4.47: Instalacion del servidor Apache2 y del modulo WebDav/Subversion para elservidor

$ apt -get install apache2 libapache2 -svn

El gestor de paquetes de Debian resolvera las dependencias que considere oportunas, yterminara de instalar el software. Es importante destacar que obviamente, no es posible tenerlos dos servidores escuchando peticiones en los dos puertos, por lo que la decision adoptadasera establecer el puerto 80 (el estandar de HTTP) para el servidor Apache en la version 1 yel puerto 8080 para el servidor Apache en la version 2. Para llevar a cabo esta configuracion,editamos el fichero /etc/apache2/ports.conf :

Listen 8080

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

NO_START =0

De esta forma, el servidor web Apache 2 arrancara normalmente en el arranque o bajo peticiondel demonio correspondiente.

Configuracion de los Hosts virtuales

Los hosts virtuales son una caracterıstica del servidor web por la cual le permite resolverpeticiones que van dirigidas hacia diferentes hosts. Esto permite que un mismo servidor webpueda resolver peticiones que en principio, pertenecen a diferentes URLs o localizaciones. Ennuestro caso, disponemos de un nombre abreviado o alias que hace referencia al servidorpantuflo.escet.urjc.es. Este nombre es pantuflo.es, que nos sirve para no tener que escribir elnombre completo (a los alumnos les es mas facil recordar este nombre) y para disponer de un mapapropio de nombres que puede ser administrado por el Departamento y por los administradoresdel Laboratorio. Veremos mas adelante en la seccion de Configuracion del servicio de resolucionde nombres como configurar una zona concreta con un software de resolucion de nombres. Eneste punto, lo unico que nos debe preocupar es que nuestro servidor web sea capaz de atender laspeticiones dirigidas tanto a la direccion pantuflo.escet.urjc.es como a la direccion pantuflo.es(y que por supuesto, devuelva el mismo contenido).

La configuracion de los hosts virtuales se lleva a cabo en el fichero de configuracion de Apache,el fichero /etc/apache/httpd.conf. En la ultima seccion del fichero, podemos encontrar el areade declaracion de hosts virtuales. Como en nuestro caso solamente tenemos dos hosts, vamos adeclarar uno (el host pantuflo.escet.urjc.es) y el otro lo vamos a configurar como alias. Esto nospermitira no tener que repetir la misma informacion para el host pantuflo.es. La configuracion,por tanto, quedarıa como sigue:

Listado 4.48: Creacion de un host virtual en Apache para el host pantuflo.escet.urjc.es

<VirtualHost 212.128.4.4 >

2 ServerName pantuflo.escet.urjc.es

ServerAlias pantuflo.es

4 ServerAdmin agutierr@gsyc .escet.urjc.es

DocumentRoot /var/www/wikipantuflo/

6 Alias /parte.html /var/www/parte.html

Alias /imagenes_parte /var/www/imagenes_parte

8 Alias /calendario /var/www/icalendar/

Alias /tablas.css /var/www/tablas.css

10 Alias /admin /var/www/admin/

Alias /cuentas /var/www/cuentas



12 Alias /pipermail /var/lib/mailman/archives/public

Options +Indexes

14 </VirtualHost >

Se puede observar en el fragmento del fichero de configuracion anterior como se define el hostpantuflo.escet.urjc.es, una direccion de correo para el administrador del mismo, y la etiquetaDocumentRoot que indica a partir de que localizacion en el disco fısico se han de servir laspaginas web referenciadas por las peticiones entrantes al servidor. Tambien podemos ver comocon ayuda de la directiva ServerAlias, definimos que el host pantuflo.es es exactamente lomismo que el host pantuflo.escet.urjc.es. En la siguiente seccion veremos como retocar estaseccion del fichero de configuracion de Apache para que sea capaz de servir las paginas personalesde los usuarios bajo los hosts virtuales pantuflo.escet.urjc.es y pantuflo.es.

Gestor de contenidos MediaWiki

Una vez hemos instalado un servidor web en cada una de las maquinas visibles de losLaboratorios (las maquinas pantuflo y bilo vamos a proceder a la instalacion de un gestor decontenidos que nos permita anadir contenido a las paginas de cada uno de los laboratorios, deforma que sea facil, rapido y que los alumnos y docentes puedan modificar los contenidos. Laconjuncion de cada una de estas palabras responde a un unico termino: un wiki. Un wiki (ouna wiki) (del hawaiano wiki wiki, ((rapido))) es un sitio web colaborativo que puede ser editadopor varios usuarios. Los usuarios de una wiki pueden ası crear, modificar, borrar el contenidode una pagina web, de forma interactiva, facil y rapida; dichas facilidades hacen de la wiki unaherramienta efectiva para la escritura colaborativa.

Existen multitud de programas que implementan esta funcionalidad. El escogido para serusado en nuestro entorno sera la aplicacion MediaWiki25. Actualmente, uno de los wikis masgrandes que existen, es el proyecto Wikipedia, en cada uno de los lenguajes que dispone. Esteproyecto, utiliza como gestor de contenidos el software Mediawiki, unwiki con una apariencia muypersonalizable (permite gestionar diferentes estilos), con una sintaxis muy amplia (el lenguajede marcado que usa es bastante amplio) y que ademas, permite diferentes mecanismos deautenticacion de usuarios, entre ellos, autenticacion frente a un directorio LDAP. Es por estarazon que nos decantamos en favor de esta aplicacion, puesto que la integracion con el sistema deautenticacion es cien por cien: cualquier usuario con cuenta en los laboratorios (ya sea docenteo alumno) podra anadir o editar contenidos a la pagina del Laboratorio. Por supuesto, existiranpaginas para las que no se dispongan permisos de edicion (o solamente un docente pueda hacerlo).En general, no nos preocupa mucho que un alumno pueda borrar el contenido de una pagina:aparte de que su nombre quedarıa registrado, la propia estructura de un wiki hace que larecuperacion sea inmediata.

Instalacion de MediaWiki

La instalacion del software MediaWiki desde las fuentes es realmente sencilla. Para empezar,debemos descargar la ultima version26 del software, disponible en la pagina web del Proyecto. Unavez descargada y descomprimida, pasamos a leer el fichero INSTALL, en el que normalmente seincluyen las instrucciones de instalacion.

Listado 4.49: Descarga e Instalacion de la herramienta MediaWiki

$ wget http :// download.wikimedia.org/mediawiki /1.11/ mediawiki -1.11.1. tar.gz 1> /dev/null

$ cd /var/www/

$ mkdir mediawiki

$ cd mediawiki

$ mv /root/mediawiki -1.11.1. tar.gz .

$ tar xvfz mediawiki -1.11.1. tar.gz

25http://www.mediawiki.org26En el momento de escribir el presente documento, la ultima version estable es la 1.1 .



Una vez descomprimido el software, debemos acudir a la direccion /config para terminar laconfiguracion del mismo. En esta direccion se muestra un formulario para completar los ajustesrelativos a la base de datos donde se alojaran las paginas de la citada aplicacion, usuarios ydemas. Es necesario en este punto disponer de un servidor de bases de datos funcionando (notiene porque ser en la misma maquina donde se instala la aplicacion). Suponemos que de ser ası,simplemente introducirıamos los parametros de conexion oportunos (nombre de host donde seencuentra el servidor de base de datos, usuario y contrasena para la conexion, nombre de la basede datos que albergara el wiki, etcetera). Si todo ha ido bien, el script terminara de ejecutar susacciones instalando en el servidor de base de datos las tablas necesarias para que la aplicacionpueda funcionar correctamente.

Una vez que hemos completado esta accion, nuestro wiki queda correctamente instalado, ypreparado para ser personalizado. Tras unas tareas de edicion en el wiki, tenemos una paginatotalmente funcional donde poder informar a los usuarios del Laboratorio de diferentes aspectos,tal y como muestra la imagen 4.9:

Figura 4.9: Pagina principal del Laboratorio de Mostoles

En la seccion Noticias, se mostraran las noticias relacionadas con el servidor (informacion deincidencias, cambios de horario, avisos para los usuarios, etcetera). Estos avisos normalmentetambien se mandaran por correo electronico mediante la lista de usuarios del Laboratorio,cuya configuracion veremos mas tarde.

En la seccion Instalaciones se muestran las instalaciones (descripcion del hardware y fotos)de las que disponemos en los Laboratorios. Tambien puede resultar de utilidad a futurosalumnos o a visitantes ajenos a la Universidad.

En la seccion Tutoriales se muestran diversas guıas de configuracion de los servicios masusados en los Laboratorios: como configurar el correo de la cuenta, acceder a el mediante elwebmail, conectarse a las terminales desde casa, abrir una sesion grafica desde casa, etcetera.Esta seccion sin duda resulta de mucha ayuda a los alumnos que acuden a los Laboratoriosa realizar sus practicas, y sin duda es una de las mas visitadas.



En la seccion FAQs se encuentra una seleccion de las preguntas mas frecuentes, relacionadassobre todo con el Sistema Operativo Linux.

Etcetera.

Autenticacion en MediaWiki en un directorio LDAPComo se comento anteriormente, una de las principales ventajas de la aplicacion MediaWiki

es la integracion de autenticacion a traves de un directorio de usuarios LDAP. Esto nos va apermitir que los usuarios (tanto alumnos como profesores) se puedan autenticar de cara al wikiy puedan editar los contenidos (anadir, modificar o borrar).

Para poder llevar a cabo esta integracion, debemos descargar una extension de la aplicacion.Una extension es un aditivo que permite anadir funcionalidad a la aplicacion base. En este caso,esta extension nos va a permitir autenticar usuarios contra el directorio LDAP del Laboratorio.

La extension LDAP Authentication27 anade esta funcionalidad. El mecanismo deinstalacion y configuracion es realmente simple: en primer lugar, debemos descargar la extensionen el directorio de extensiones de la aplicacion:

$ cd /var/www/mediawiki/extensions/

$ wget http ://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/LdapAuthentication /

LdapAuthentication .php?revision =20128

1> /dev/null/

Una vez hemos descargado la extension, lo unico que tendremos que hacer es configurarla.Para ello, editamos el fichero principal de configuracion de la aplicacion, el fichero/var/www/mediawiki/LocalSettings.php. Tal y como detalla la documentacion de laextension, escribimos la configuracion de autenticacion LDAP para el entorno en el que nosencontramos:

Listado 4.50: Configuracion de MediaWiki para autenticar usuarios usando LDAP

require_once(’extensions/LdapAuthentication .php ’ );

2 $wgAuth = new LdapAuthenticationPlugin ();

4 $wgLDAPDomainNames = array(

"alumnos", "profes"

6 );

8 $wgLDAPServerNames = array(

"alumnos "=> "peloto.escet.urjc.es",

10 "profes" => "peloto.escet.urjc.es"

);

12

$wgLDAPUseLocal = true;

14

$wgLDAPEncryptionType = array(

16 "alumnos "=>"ssl",

"profes" => "ssl"

18 );

20 $wgLDAPSearchAttributes = array(

"alumnos "=>"uid",

22 "profes "=>"uid"

);

24

$wgLDAPBaseDNs = array(

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

28 );

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



30 $wgLDAPGroupBaseDNs = array(

"alumnos "=>"ou=grupos ,ou=escet ,ou=alumnos ,dc=zipi ,dc=escet ,dc=urjc ,dc=es",

32 "profes "=>"ou=grupos ,ou=profesores ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

);

34

$wgLDAPUserBaseDNs = array(

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

38 );

40 $wgLDAPAddLDAPUsers = array(

"alumnos "=>false ,

42 "profes"=>true

);

Figura 4.10: Autenticacion en la pagina del Laboratorio mediante el directorio LDAP.

Vemos como, se definen dos grupos diferentes de usuarios: alumnos y profes (en principio,cada uno dispondra de un conjunto diferente de privilegios). A continuacion, definimos el servidorde autenticacion (con uno de ellos hubiera bastado, especificamos el servidor primario) y deforma especial, destacamos que el mecanimos de conexion al servidor LDAP debe ser SSL. Si noespecificamos esto, la aplicacion MediaWiki intentara conectar al puerto estandar de LDAP enel servidor especificado (389) y la conexion fallara. En la imagen 4.10 podemos ver el resultadode esta configuracion. El sitio MediaWiki del Laboratorio permite la autenticacion contra eldirectorio LDAP de usuarios.

Web personales de usuarios

Un aspecto interesante de la configuracion de Apache es la que permite a los usuarioscolocar una pequena pagina personal de usuario en el servidor. Muchos de los usuariosdel sistema, utilizan esta posiblidad para colgar informacion sobre su currıculum, practicasrealizadas, etcetera. Para poder llevar a cabo esta configuracion, debemos editar la entradadel virtual host para que busque las paginas personales de los usuarios en el directoriopublic html del usuario que se especifica en la URL. Por ejemplo, la URL del usuarioagutierr sera http://pantuflo.escet.urjc.es/ agutierr (para el campus de Mostoles) ohttp://bilo.cct.urjc.es/ agutierr (para el campus de Fuenlabrada). Los ficheros que se serviran



en esa URL se localizaran dentro del directorio public html, en el directorio HOME del usuario.Es necesario que tanto este directorio como el superior, tenga permisos de lectura y ejecucion.

La configuracion que materializa esta funcionalidad se muestra a continuacion:

Listado 4.51: Configuracion de Apache para dar soporte a paginas personales de usuarios<IfModule mod_userdir.c>

2 UserDir public_html

<Directory /home /*/ public_html >

4 AllowOverride All

DirectoryIndex index.html index.php

6 <Limit GET POST OPTIONS PROPFIND >

Order allow ,deny

8 Allow from all

</Limit >

10 <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK >

Order deny ,allow

12 Deny from all

</Limit >

14 </Directory >

</IfModule >

Aplicando esta configuracion en los servidores web de cada una de las maquinas que lo alojan(pantuflo y bilo) los usuarios podran colgar su propia pagina personal alojada en su directorioHOME.

4.2.4. Servidor de correo electronico

Junto con la cuenta de usuario de los laboratorios se facilita una direccion de correo bajoel dominio pantuflo.escet.urjc.es (para el campus de Mostoles) y bilo.cct.urjc.es para losusuarios con cuenta en el campus de Fuenlabrada. Esta cuenta de correo en principio es la unicaforma de contactar con los usuarios del sistema, puesto que no disponemos de datos adicionalescomo direccion de correo de la Universidad, telefono, etcetera. Por tanto, el buen funcionamientode este servicio sera fundamental para mantener el contacto con los usuarios.

Relativo al servicio de correo electronico, se nos presentan varios objetivos para el correctofuncionamiento del servicio:

1. Instalar un servidor de correo entrante (SMTP) capaz de recoger todo el correo que lleguea los usuarios del servidor pantuflo.escet.urjc.es. Este servicio, obviamente residira en lamaquina pantuflo.escet.urjc.es y sera gestionado por la aplicacion Postfix, tal y comovimos en el capıtulo Estado del arte. Alternativamente, en el campus de Fuenlabrada, elcorreo sera recogido por la maquina bilo.cct.urjc.es.

2. Instalar un servidor de recogida de correo electronico, que permita a los usuarios recogerel correo electronico de sus buzones para descargarlos con su gestor de correo favorito. Enprincipio, ofreceremos servicio POP328 para la recogida de correo, aunque posteriormentetambien se ofrecera la posibilidad de consultar el correo electronico usando el protocoloIMAP29. Preferiblemente, es recomendable que los datos que usen estos protocolos viajende forma segura, es decir, haciendo uso de una capa de cifrado SSL. Es por ello que una vezque se ha configurado el servidor de recogida de correo para servir vıa POP e IMAP y se hacomprobado el correcto funcionamiento del mismo, pasaremos a habilitar el soporte POP3se IMAPs (variantes de los mismos protocolos en su version SSL) y quedara desactivado losprotocolos POP3 e IMAP en version texto claro. Esto garantizara a los usuarios una mayorseguridad y privacidad de los datos que intercambian con el servidor.

28POP son las siglas de Post Office Protocol29IMAP son las siglas de Internet Message Access Protocol



3. Alternativamente, vamos a ofrecer a los usuarios la posibilidad de consultar su correo atraves de un webmail. De esta forma siempre podran consultar sus correos en cualquiermomento, unicamente teniendo acceso a un navegador web.

Comentaremos a continuacion como conseguimos realizar cada uno de los hitos planteados enesta seccion.

Entrega de correo electronico (SMTP)

Para dotar al sistema de un servidor que recoja el correo electronico dirigido a la maquinapantuflo.escet.urjc.es instalaremos la aplicacion Postfix. Postfix es un servidor de entrega decorreo muy potente y muy sencillo de configurar al mismo tiempo. Como nuestro sistema enprincipio no tiene grandes pretensiones mas que la de simplemente recoger el correo y entregarseloa los usuarios, nos decantaremos por esta opcion.

La instalacion de Postfix es muy sencilla en maquinas basadas en el sistema de paquetes deDebian. En concreto, para la instalacion del mismo, ejecutaremos

Listado 4.52: Instalacion de la herramienta postfix usando apt-get

$ apt -get install postfix

El paquete solicitara configuracion adicional. No obstante, la configuracion es muy sencilla.Configuraremos el gestor como:

Sitio de Internet, capaz de recoger correo dirigido al dominio que nos ocupa(pantuflo.escet.urjc.es para el campus de Mostoles y bilo.cct.urjc.es para el campusde Fuenlabrada).

El dominio para el cual debe aceptar correo suele ser localhost para el correo local dela propia maquina, localhost.localdomain como extension al anterior, y por ultimo, eldominio visible desde Internet, que en nuestro caso sera pantuflo.escet.urjc.es para elcampus de Mostoles y bilo.cct.urjc.es para el campus de Fuenlabrada.

Por ultimo, y esto es muy importante, las IPs desde las cuales el servidor debe poderhacer relay. Hacer relay en un servidor de correo significa desde que IPs o redes de IPsse debe reenviar correo a dominios externos al propio sin pedir una confirmacion o unaautenticacion adicional. En general, se confıa siempre en la propia maquina (las subredescon IP 127.0.0.0/24) y las de la propia red local (en nuestro caso sera 212.128.4.0/24 para elcampus de Mostoles y 193.147.73.0/24 para el campus de Fuenlabrada). Si no configuramoseste parametro con especial cautela, numerosos spammers de Internet pueden usar nuestroservidor de correo para enviar correo fraudulento, publicidad y derivados.

Una vez hemos aplicado la configuracion en concreto para cada una de las maquinasque se encargaran de la entrega del correo, podemos comprobar que nuestro servidorfunciona adecuadamente (podemos enviarnos un correo de prueba y comprobar que nos llegacorrectamente). Si quisieramos modificar algun aspecto de la configuracion, Postfix almacena susopciones de configuracion en los ficheros /etc/postfix/main.cf y /etc/postfix/master.cf. Losficheros de configuracion de esta herramienta son bastante sencillos y asequibles de modificar.

Recogida de correo electronico (POP3 e IMAP)

La recogida de correo mediante protocolos como POP3 e IMAP es un aspecto casi fundamentalde cara a que los usuarios de nuestro sistema se sientan lo suficientemente motivados como para



usar el correo electronico del servidor pantuflo. De no proporcionar un servicio de recogida decorreo, los usuarios se verıan obligados a leer el correo electronico en la propia maquina que lorecibe, a traves del comando mail, o alguno mas avanzado, como Pine o Mutt.

La disposicion de permitir al usuario recoger el correo electronico mediante los citadosprotocolos permite al usuario utilizar aplicaciones de correo como Outlook, Evolution, oThunderbird, y gestionar el correo de forma eficiente. Mediante estas aplicaciones seran capacesde poder leer el correo electronico que les llegue a su cuenta de correo de pantuflo o de bilo sinnecesidad de tener que conectarse al servidor para poder leerlo. En concreto, vamos a implantar unservidor de recogida de correo que permita que los usuarios puedan descargarse el correo mediantelos protocolos POP3 e IMAP. Como ya vimos en el capıtulo Estado del arte, la aplicacion elegidapara realizar esta tarea sera la aplicacion Dovecot, por las ventajas enumeradas en este capıtulo.Esta aplicacion nos permitira que tanto la maquina pantuflo como la maquina bilo atiendan elservicio POP3 e IMAP, a traves de sus correspondientes versiones cifradas (POP3s e IMAPs).Es necesario recordar que ambos protocolos se transmiten por la red en texto claro, incluyendonombres de usuario y contrasenas, por lo que sera obligado el proporcionar el citado servicioutilizando algun metodo de encriptacion para datos sensibles, como son el correo electronico y lainformacion de autenticacion.

Dovecot

La aplicacion Dovecot es un servidor de recogida de correo que funciona tanto con ficherosmbox (en los que los correos electronicos se almacenan en un unico fichero) como con el formatomas actual de almacenamiento de correo electronico, el formato Maildir. Segun se detalla enla pagina oficial de Dovecot30, esta aplicacion fue pensada y escrita pensando principalmenteen la seguridad, en la escalabilidad y en el alto rendimiento, funcionando igual de bien parasistemas austeros, con pocos usuarios, como para grandes sistemas. Ademas, soporta multitud demecanismos de autenticacion, como por ejemplo la autenticacion mediante los modulos de PAM(que sera la que usemos en nuestro caso) ası como basados en bases de datos. Por ultimo, aunqueno es nuestro caso, Dovecot funciona perfectamente en clusters de ordenadores en red que usenpor ejemplo NFS como sistema de archivos compartidos. Aunque no es nuestro caso, es un buenejemplo de la escalabilidad que puede llegar a proveer esta aplicacion.

Instalacion de Dovecot

La instalacion de Dovecot resulta bien sencilla, puesto que se encuentra incluido comopaquete Debian en la distribucion estable, y por tanto, una simple llamada al comando apt-get bastara para su instalacion:

Listado 4.53: Instalacion de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo

$ apt -get install dovecot -common dovecot -pop3d dovecot -imapd

Como vemos, es necesario indicar que se desea instalar el paquete con la funcionalidad basicade Dovecot (paquete dovecot-common) ademas de los paquetes que proveeran funcionalidadde los protocolos POP3 e IMAP: los paquetes dovecot-pop3d y dovecot-imapd. Una vezinstalados ambos paquetes, sera necesario realizar unos ajustes que nos permitan configurar elsistema para que los usuarios puedan recoger el correo electronico mediante cualquiera de los dosprotocolos. Para ello, deberemos editar el fichero de configuracion /etc/dovecot/dovecot.conf.Nos centraremos en las siguientes lıneas:

1. Indicar los protocolos que deben ser servidos por el servidor de recogida de correo. Ennuestro caso, vamos a servir los protocolos POP3 e IMAP, en su version segura (apoyadosen las bibliotecas SSL). Lo indicamos de la siguiente forma:

30http://www.dovecot.org/



protocols = imaps pop3s

2. Indicar donde se encuentran los directorios de correo de los usuarios. Este aspecto es muyimportante, ya que si no indicamos la ruta hacia el directorio de correo de forma correcta,los usuarios obtendran un error cuando intenten descargar o consultar su correo con laaplicacion gestora correspondiente. En nuestro caso, los directorios de correo se encuentranen el directorio /var/mail/ seguido del nombre de usuario en cuestion. Hay que recordarque debido a que se proporciona funcionalidad IMAP, es necesario que el correo electronicose almacene en el formato Maildir, estandar casi de facto en la mayorıa de servidores decorreo. Para indicar este parametro en la configuracion de Dovecot, debemos escribir en elfichero de configuracion la siguiente lınea:

default_mail_env = maildir :/var/mail/ %u/

3. Por ultimo, y dado que la autenticacion de los usuarios en el servidor de recogida de correosera la estandar del sistema, podemos usar PAM para esta tarea. En ese sentido PAM esmuy flexible, ya que para anadir un nuevo servicio solamente debemos incluir en el directorio/etc/pam.d/ un fichero de nombre dovecot indicando como se realizara la autenticacion(exactamente igual al resto de servicios del sistema). Su contenido podra ser el siguiente:

# %PAM -1.0

@include common -auth

@include common -account

@include common -session

Una vez realizados estos ajustes en el fichero de configuracion de Dovecot, podemos reiniciarel servicio y comprobar que se encuentra escuchando peticiones de los protocolos indicadoscorrectamente:

Listado 4.54: Reiniciando el demonio dovecot tras su reconfiguracion

pantuflo :~# /etc/init.d/dovecot restart

Restarting mail server: dovecot.

pantuflo :~#

Una llamada a nmap desvela que los servicios se encuentran escuchando en los puertoscorrespondientes:

993/ tcp open imaps

995/ tcp open pop3s

Examinando los ficheros de log del servidor de correo podemos ver como los usuarios seautentican 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): Disconnected: 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



Jul 2 16:22:43 pantuflo dovecot: POP3(fescriba): Disconnected: 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 metodo para la consulta delcorreo electronico de sus cuentas @pantuflo y @bilo (para el Campus de Mostoles y deFuenlabrada,respectivamente) decidimos instalar un webmail. Un webmail es una aplicacion webque permite consultar a traves de un navegador web el correo electronico de una cuenta de unusuario en un sistema, normalmente una cuenta Unix o Linux. Dado que la instalacion de este tipode aplicaciones no es muy compleja, decidimos implantar este servicio para ambos campus. Deesta forma, aquellos usuarios que no quieran descargarse su correo mediante aplicaciones gestorasde correo (como Outlook, Evolution y derivados) podran consultarlo a traves del web.

Una de las aplicaciones que implementa el servicio webmail mas conocidas hoy en dıa es laSuite Horde, que ademas de proporcionar acceso al buzon de correo de un usuario en un sistemaUnix/Linux, proporciona servicios de agenda, calendario, etcetera. De hecho, esta aplicacion es enla que se basa el servicio webmail de la Universidad31. Esto sera una ventaja para nosotros, puestoque a los usuarios les resultara familiar el interfaz y apenas existira complejidad de adaptacion auna nueva herramienta.

HordeEl Proyecto Horde se compone de unas bibliotecas (llamado Horde Framework) que

proporcionan funcionalidades basicas (autenticacion, gestion de preferencias, interfaz grafica,etcetera) y que funciona como nexo de union entre distintas aplicaciones de usuario, queson gestionadas como subproyectos independientes, dentro de la aplicacion Horde. Entre estasaplicaciones encontramos IMP, un sistema webmail que permite el acceso a buzones de correomediante POP3 o IMAP. A traves de este acceso podremos acceder a los buzones de las cuentasde los usuarios, tanto en los servidores pantuflo como bilo.

La instalacion de esta aplicacion es extremadamente sencilla y por esta razon no sera detalladaen exceso en el presente documento. Para llevar a cabo la instalacion, es necesario descargar lasultimas versiones estables de la aplicacion principal de esta suite, llamada Horde: esta aplicaciones la unica no opcional bajo la que se sustentan el resto de modulos del sistema. Si unicamentedeseamos instalar la aplicacion IMP (webmail), deberemos descargar desde la pagina del proyectoel modulo imp, instalandolo a continuacion de horde.

Los unicos aspectos relevantes de la instalacion son:

1. Como se realiza el acceso al servidor POP3/IMAP donde se encuentran los buzones de losusuarios. En nuestro caso, es la configuracion de correo electronico que se llevo a cabo enel apartado anterior.

2. Como se lleva a cabo la autenticacion de usuarios para poder ingresar en el webmail.Dado que estas aplicaciones se instalaran en las maquinas pantuflo y bilo (es logicoque el webmail se encuentre en la misma maquina que recibe el correo) podemos usar laautenticacion local de la citada maquina: si un usuario puede entrar con una cuenta en esamaquina, podra entrar en el webmail (logicamente). Para llevar a cabo esta implementacion,debemos indicarle a IMP que la autenticacion se debe llevar a cabo usando los modulosPAM de la maquina donde se encuentra alojada la aplicacion.

En el soporte electronico de este documento se puede encontrar los ficheros de configuracion deHorde e IMP para esta configuracion. Una vez que se han llevado a cabo estos ajustes, realizamos

31https://webmail.urjc.es


4.3. OTROS SERVICIOS DISPONIBLES

Figura 4.11: Webmail de pantuflo

unos retoques adicionales a las plantillas HTML de ambos webmails, donde se indica el nombre dellaboratorio y unas instrucciones para poder acceder al mismo. El resultado lo podemos observaren las imagenes 4.11 para el webmail de la maquina pantuflo y 4.12 para el webmail de lamaquina bilo.

Sobre esta configuracion pueden realizarse mejoras adicionales, como dotar al sistema de unservicio de agenda, calendario, libreta de direcciones, e incluso acceso a las cuentas de usuario(ficheros personales de cada cuenta) a traves del navegador web. En nuestro caso, todos estosservicios se implementan junto al servicio webmail: agenda, libreta de direcciones y acceso a lascuentas a traves del navegador web.

4.3. Otros servicios disponibles

En la siguiente seccion se comentaran una serie de servicios que, aunque no son imprescindiblespara que el correcto funcionamiento del Laboratorio, resultan mas que interesantes para unfuncionamiento mas eficiente. En concreto, vamos a comentar brevemente la instalacion de listasde correo para la comunicacion entre administradores y usuarios del sistema (algo fundamental,debido a que no tenemos mas datos de los usuarios que su direccion de correo en el sistema)ası como la instalacion de una replica de paquetes de software tanto para Debian como paraUbuntu, 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 comunicacion entre los usuariosy los administradores o responsables tecnicos del mismo. En nuestro caso, debido a que laautenticacion en nuestros laboratorios no se basa en el dominio unico que provee la Universidad,no disponemos de mas datos de los usuarios que la direccion de correo que poseen en el momentoen el que se abre la cuenta (la direccion de correo con dominio @pantuflo.escet.urjc.es. Porsupuesto sera responsabilidad del usuario leer este correo o redireccionarlo a una direccion quelea 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.



Figura 4.12: Webmail de bilo

Para la gestion de la comunicacion entre los administradores del laboratorio y los usuarios,instalaremos la herramienta de listas de correo mailman. Para la comunicacion entre losadministradores del sistema y los usuarios del mismo, creamos dos listas, cuya funcion sera lasiguiente:

Figura 4.13: Gestion de listas de correo en pantuflo con Mailman.

Una lista para la comunicacion entre los administradores y los usuarios del sistema en elcampus de Mostoles, a la que llamaremos lista pantuflo-todos.

Una lista para la comunicacion entre los administradores y los usuarios del sistema en elcampus de Fuenlabrada, a la que llamaremos lista bilo-todos.


4.3. OTROS SERVICIOS DISPONIBLES

La primera lista, obviamente sera gestionada en uno de los servidores del campus de Mostoles.Como vimos en el Capıtulo de Especificacion y Diseno, este servidor sera la maquinapantuflo.escet.urjc.es. Uno de los motivos que lleva a que sea esta maquina la que alberguelas listas de correo para el campus de Mostoles es el dominio de salida de los correos, la maquinavisible al resto de los usuarios @pantuflo.escet.urjc.es.

De la misma forma, la segunda lista, destinada a la comunicacion entre los administradoresy los usuarios del sistema en el campus de Fuenlabrada, estara albergada en la maquinabilo.cct.urjc.es, que es la maquina destinada a albergar la gestion de la pagina web delLaboratorio y el correo electronico, entre otros.

Existen otras listas que pueden resultar de utilidad para la gestion interna del laboratorio.Estas listas reciben mensajes de alertas variados, como por ejemplo, avisos de errores en discosduros, el reporte diario de uso de disco del sistema, las alertas por caidas en el servicio, etcetera.Comentamos alguna a continuacion.

La lista pantuflo-local tiene como funcion la comunicacion interna entre profesores yadministradores del laboratorio.

La lista pantuflo-backups recibe las alertas de las copias de seguridad que se ejecutanperiodicamente en el sistema (en ambos campus).

La lista pantuflo-nagios-estaciones recibe las alertas por caidas en las estaciones deusuario, enviadas automaticamente por la herramienta nagios.

La lista pantuflo-nagios-servidores recibe las alertas por caidas en los servidores,enviadas automaticamente por la herramienta nagios.

La lista pantuflo-raids recibe notificaciones automaticas del estado de los raids en todaslas maquinas que los usan.

La lista pantuflo-hd-alerts recibe notificaciones de alertas que se puedan producir en losdiscos duros de las maquinas crıticas (servidores principalmente).

Debido a que la gestion del laboratorio (tanto del campus de Fuenlabrada como el de Mostoles)se suelen hacer fısicamente desde Mostoles, todas estas listas estaran albergadas en la maquinapantuflo.escet.urjc.es.

Gestion de listasLa gestion de listas a traves de la herramienta mailman es realmente sencilla. Como hemos

visto, la gestion de estas listas se llevara a cabo en las maquinas pantuflo.escet.urjc.es ybilo.cct.urjc.es, en las que esta instalado Debian GNU/Linux. Por tanto, la instalacion se puedellevar a cabo usando el gestor de paquetes apt-get:

Listado 4.55: Instalacion de mailman usando apt-get

$ apt -get install mailman

Durante la instalacion, es probable que el gestor de paquetes realice alguna pregunta relativa ala post configuracion del mismo. Una vez instalado, es necesario que se cree una primera lista paraque mailman comience a funcionar correctamente. Esta lista es la lista con nombre mailman, yla podemos crear de la siguiente forma:

Listado 4.56: Creacion de una nueva lista de mailman usando el comando newlist

$ newlist mailman



Despues de responder a algunas preguntas relativas a la gestion de la lista (persona que lagestiona, contrasena inicial, etcetera) sera necesario anadir la informacion de salida del comandoal fichero /etc/aliases. La informacion que el fichero contendra por tanto, es parecida a esta:

mailman: "|/ var/lib/mailman/mail/mailman post mailman"

mailman -admin: "|/ var/lib/mailman/mail/mailman admin mailman"

mailman -bounces: "|/ var/lib/mailman/mail/mailman bounces mailman"

mailman -confirm: "|/ var/lib/mailman/mail/mailman confirm mailman"

mailman -join: "|/ var/lib/mailman/mail/mailman join mailman"

mailman -leave: "|/ var/lib/mailman/mail/mailman leave mailman"

mailman -owner: "|/ var/lib/mailman/mail/mailman owner mailman"

mailman -request: "|/ var/lib/mailman/mail/mailman request mailman"

mailman -subscribe: "|/ var/lib/mailman/mail/mailman subscribe mailman"

mailman -unsubscribe: "|/ var/lib/mailman/mail/mailman unsubscribe mailman"

Es importante resenar que despues de haber modificado el contenido de este fichero es necesarioejecutar el comando newaliases. Si no se hace, no se hara visible ninguna modificacion que sehaya hecho de cara al gestor de correo y a mailman.

Una vez que las listas estan correctamente instaladas, la gestion de ellas se puede realizarunicamente utilizando un navegador. Solamente es necesario crearlas con el comando newlist,ya que toda su gestion puede realizarse mediante el interfaz web de mailman. En la figura 4.13podemos observar la pantalla de administracion de la listas de correo de mailman (para la maquinapantuflo).

4.3.2. Mirror de Debian y Ubuntu

Debido a que, como se comento en anteriores capıtulos, en las estaciones del Laboratoriotenemos instalada la ditribucion Ubuntu Linux, resulta realmente interesante tener disponible deforma interna a la red un mirror o espejo que nos sirva para poder instalar paquetes de una formamas eficiente. Sin duda la capacidad de la red es bastante alta, y en ese sentido, la instalacion depaquetes no resulta para nada lenta en ningun caso. Sin embargo, siempre resulta mas eficiente decara al trafico de la red descargar los paquetes una unica vez y luego replicarlo en todas aquellasmaquinas en las que sea necesario.

Por ello, se decide llevar a cabo la instalacion (o mejor dicho, la replica) de un servidor depaquetes tanto para Ubuntu, como para Debian. En el caso de Debian la necesidad no es tan alta,puesto que esta distribucion unicamente se usa en los servidores. Ademas, la red Rediris proveede un mirror o espejo de paquetes para esta distribucion, por tanto la penalizacion de trafico pordescarga no serıa tan alta en este caso.

Para la instalacion de un mirror local usamos la herramienta debmirror, la cualdescargara todos los paquetes necesarios para consolidar la replica local de una determinadaversion de Debian (o de Ubuntu), con sus correspondientes ramas y secciones. La herramientadebmirror 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: Instalacion de la herramienta debmirror usando apt-get

$ apt -get install debmirror

Una vez que ha sido instalada, debe ser configurada para ser ejecutada periodicamente (lomas normal, es que se ejecute una vez al dıa). Lo mas facil para llevar a cabo esta tarea esusar una lınea de cron, para asegurar que este comando se ejecuta periodicamente. Como essabido , las distribuciones que nos ocupan (Debian y Ubuntu) se dividen en versiones. A su vezestas versiones, estan divididas en secciones. Por tanto, deberemos indicarle a la herramienta



debmirror que versiones queremos replicar ası como que secciones y ramas de desarrollo. Lovemos 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 replica de Ubuntu usando el comando debmirror

debmirror --nosource -m --passive --host=archive.ubuntulinux.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 --section=main ,multiverse ,universe ,restricted

--arch=i386 /disks/raid/ubuntu -mirror/ --ignore -release -gpg --nocleanup

En la cual se indica que el mirror principal a traves del cual se replicara la informaciones archive.ubuntulinux.org, que se usara el metodo ftp, y que se replicaran las versionesde Ubuntu dapper, edgy, feisty, gutsy, y hardy. Ademas, en cada version se replicaran lassecciones main, universe, multiverse y restricted. Por ultimo, le indicamos que la unicaarquitectura que se debera replicar es la aquitectura Intel x86 y que se deberan ignorar lasadvertencias relativas a las firmas PGP.

El caso de Debian es mas simple, puesto que tanto el numero de versiones como las ramas ysecciones es mucho menor, tal y como muestra la llamada a debmirror del listado 4.59.

Listado 4.59: Descargando la replica de Debian usando el comando debmirror

debmirror /disks/raid/debian -mirror/ --host=ftp.rediris.es --root=/ debian

--dist=testing ,stable ,unstable ,experimental --section=main ,contrib ,non -free

--arch=i386 --progress --method=ftp --nosource --ignore -release -gpg

En la que se indica que unicamente se deberan replicar las versiones de Debian testing,stable, unstable y experimental, las secciones main, contrib y non-free en la arquitecturaIntel x86.

Una vez que hemos configurado el servidor de paquetes como replica para Ubuntu y Debian,configurar los clientes para que usen este mirror es trivial. Para ello, editamos el fichero/etc/apt/sources.list. Como comentamos en el capıtulo Diseno, la maquina peloto sera laencargada de albergar el mirror de Ubuntu y de Debian en el Laboratorio, por tanto, en el casode Ubuntu, el contenido del fichero podrıa ser el mostrado en el listado 4.60.

Listado 4.60: Contenido del fichero /etc/apt/sources.list usando la replica del Laboratorio

deb http :// peloto.escet.urjc.es/ubuntu feisty main restricted universe multiverse

2 deb http :// peloto.escet.urjc.es/ubuntu feisty -security main restricted universe multiverse

deb http :// peloto.escet.urjc.es/ubuntu feisty -backports main restricted universe

multiverse

4 deb http :// peloto.escet.urjc.es/ubuntu feisty -updates main restricted universe multiverse

Suponiendo que queremos que nuestro sistema se encuentre en la version feisty de Ubuntu.Para el caso de Debian, el contenido del fichero es practicamente el mismo, y por tanto nosera mostrado a continuacion.

4.4. Monitorizacion del Sistema

Una vez que todo el sistema esta implantado y se ha comprobado el correcto funcionamiento detodos los objetivos que nos planteabamos, la monitorizacion del mismo es un aspecto fundamental.Es muy importante conocer en todo momento el estado tanto de los hosts que forman nuestra



red como de los servicios que ofrecen. En particular, sera muy importante conocer el estado deaquellas maquinas que ofrecen servicios que resultan crıticos para el correcto funcionamiento delos laboratorios, es decir, los servidores.

La monitorizacion de las estaciones de trabajo es algo importante, pero en todo caso, el queuna estacion de trabajo no funcione en un momento dado, no origina que el resto de estacionesdel laboratorio dejen de funcionar, como es el caso de los servidores. En cualquier caso, ver quetodas las estaciones de una sala no funcionan, desde luego puede levantar nuestras sospechas deque algo extrano esta ocurriendo y requiere nuestra atencion.

Existen numerosas aplicaciones que prestan funcionalidad de monitorizacion de serviciosy maquinas en una red local. Como vimos en el capıtulo Estado del arte, hemos elegido laherramienta Nagios para la monitorizacion basica de estaciones, servidores y servicios en cadauna de ellas (alertar de posibles caıdas en maquinas y/o servicios y envıo de mensajes). Por otrolado, hemos elegido la herramienta Munin para recolectar informacion mas elaborada acerca delfuncionamiento de cada uno de los servidores. Esta informacion sera representada a traves degraficas que podremos visualizar a traves de nuestro navegador web favorito.

Por otro lado, utilizaremos un script muy sencillo que informara del estado de las estacionesde cara a los usuarios del mismo (principalmente, los alumnos). Esta utilidad volcara en unapagina web el estado de todas las estaciones, para las que se identificaran tres estados posibles:la maquina esta apagada, la maquina esta encendida pero solo responde al ping y por ultimo, lamaquina esta encendida y responde al ping (esta disponible). A esta utilidad la llamaremos partede guerra y estara disponible tanto en el campus de Mostoles y de Fuenlabrada. A continuacionvamos a ver de forma mas detallada el proceso de monitorizacion de los servidores y de lasestaciones.

4.4.1. Monitorizacion de servidores

Como ya se ha comentado, para la monitorizacion de los servidores usaremos dos aplicacionesprincipalmente. Utilizaremos Nagios para la monitorizacion basica de maquinas y servicios (estoes, saber si las maquinas y los servicios estan o no disponibles) y de forma mas avanzada,utilizaremos Munin para una monitorizacion mas avanzada de los servidores. Munin proporcionainformacion mas detallada y extensa de una maquina en concreto, representada a traves degraficas, que se pueden ver a traves del navegador web. Munin esta compuesto de dos aplicacionesprincipales: el cliente, que envıa informacion de la maquina al servidor Munin, y el servidor, querecolecta la informacion que le envıan los clientes y la representa a traves de graficas clasificadasen diferentes areas. Sera muy interesante obtener a traves de Munin la informacion del uso deCPU, memoria, procesos, uso de la red, uso del servidor NFS en una maquina en concreto.

La maquina que usaremos como vigıa de toda esta informacion (tanto Nagios como Munin)sera la maquina espatula, como ya se estudio en el capıtulo Especificacion y Diseno.

Instalacion de Nagios

La instalacion de Nagios usando apt-get es realmente sencilla, mostrandose en el listado 4.61.

Listado 4.61: Instalacion de la herramienta Nagios con apt-get

$ apt -get install nagios -text

Nagios esta disponible en diferentes paquetes. En concreto usaremos este, que almacena lainformacion en ficheros de texto. Otros paquetes de Nagios almacenan la informacion de lasmaquinas monitorizadas en bases de datos MySQL. Por no anadir otro servicio a la instalacion,



decidimos usar la version de nagios que no necesita de ningun sistema gestor para poder funcionaradecuadamente.

Una vez que la herramienta ha sido instalada, esta debe ser configurada. En el directorio/etc/nagios existen numerosos ficheros de configuracion que es necesario editar al gusto paraque la herramienta funcione segun nuestras necesidades. La configuracion de nagios puederesultar un tanto tediosa si no se automatiza apoyandonos en scripts de automatizacion. Es muyrecomendable disponer de un fichero de texto en el que se encuentren reflejadas todas las IPs quese desean monitorizar, ası como el nombre de cada maquina. A traves de este fichero y usandoscripts basicos de shell, la configuracion resulta muy sencilla. Vamos a comentar a continuacionlos ficheros principales de Nagios que es preciso editar para que funcione correctamente:

/etc/nagios/hosts.cfg: almacena la informacion de las maquinas que se deseanmonitorizar (basicamente, la direccion IP y el nombre de la maquina).

/etc/nagios/hostgroups.cfg: agrupa las maquinas anadidas en el fichero de configuracionanterior en grupos de maquinas. En nuestro caso, resulta aconsejable agrupar las maquinasde cada aula en un grupo diferente, y crear otro para los servidores.

/etc/nagios/contacts.cfg: contiene la informacion de las personas de contacto para losavisos automaticos de la aplicacion. La informacion reflejada en este fichero consta denombre de la persona de contacto, correo electronico, telefono, etcetera.

/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 laadministracion de cada maquina estuviera separada. En nuestro caso (debido a que el equipotecnico es mas bien pequeno) no se usara, y unicamente existira un grupo.

/etc/nagios/services.cfg: este fichero almacen la informacion de los servicios que sedesean monitorizar de una maquina o de un grupo de maquinas en concreto. Por ejemplo,monitorizar que la maquina esta disponible (servicio check ping), que la maquina tiene elservicio SSH ejecutando (servicio check ssh), etcetera.

Una vez que todos los ficheros han sido configurados, es necesario reiniciar el servico nagios,para que la configuracion se actualice y todo empiece a funcionar adecuadamente. Existendiferentes otros ficheros de configuracion que no son exactamente relativos a Nagios, como son laconfiguracion de Apache, los usuarios que pueden acceder a la informacion, etcetera.

Una vez que esta todo funcionando, podemos acceder al sistema de monitorizacion32. En laimagen 4.14 se pude observar la pagina principal del estado de los servicios en Nagios. Podemosver las maquinas del Laboratorio de Mostoles agrupadas por aula (106, 108, 109 y 111) y losservidores. Por cada grupo, se puede observar las maquinas que estan disponibles y el estado delos servicios que se monitorizan en esas maquinas. Podemos ver que en todas las aulas todas lasmaquinas estan disponibles (estado OK) menos en el aula 108, que hay dos que no lo estan, yque en principio la mayorıa de los servicios estan disponibles (excepto de las maquinas que estanapagadas, por supuesto). Por cada maquina se monitorizan como mınimo dos servicios: servicioping y servicio ssh. Para los servidores, se monitorizan mas cosas. Por ejemplo, en pantuflonos interesara saber que los servidores web (HTTP) y correo (SMTP, POP3s e IMAPs) estandisponibles.

En la parte de la izquierda de la pagina se muestra el menu de opciones de Nagios (que sonbastantes). La parte mas interesante sera saber los problemas de los servicios que haya en algunasmaquinas. Podemos acudir a la opcion service problems para ver los problemas que hay en las

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



Figura 4.14: La pagina de resumen de estado de Nagios para el Laboratorio de Mostoles.

Figura 4.15: La pagina de problemas de Nagios muestra los problemas en algunas maquinas.

maquinas que se monitorizan. En la imagen 4.15 podemos ver la informacion contenida en estaseccion, las maquinas que tienen problemas, la duracion del mismo y cuando se comprobo porultima vez.

Ademas de esta informacion, por supuesto, los problemas que pueda tener una maquina enconcreto se pueden enviar por correo electronico. Para ello, es preciso configurar los ficheros quese comentaban anteriormente. Es necesario observar que las alertas de problemas en las estacionespueden ocasionar mucho ruido: tenemos 160 estaciones en el campus de Mostoles, y 100 en elcampus de Fuenlabrada. A cada reinicio de maquina, tendremos dos mensajes de correo electronico(servicio DOWN y servicio UP). Esto puede ocasionar demasiados mensajes y producir un efectorebote, que nos haga prescindir de esta informacion. En nuestro caso, los mensajes de alerta de lasestaciones se enviaran a una direccion de correo y los de los servidores (ya que requieren muchamas atencion) se enviaran a otra.

Instalacion de Munin

Vamos a utilizar Munin como sistema de recoleccion de informacion para los servidoresunicamente. Como hemos visto, Munin se compone de un servidor que representa la informacionde los clientes, y los nodos que envıan la informacion al servidor. La instalacion de Munin es muysencilla en un sistema Debian o basado en la herramienta apt-get:

En el servidor:



Listado 4.62: Instalacion de la herramienta Munin (servidor) con apt-get

$ apt -get install munin

En los clientes:

Listado 4.63: Instalacion de la herramienta Munin (cliente) con apt-get

$ apt -get install munin -node

En los clientes, unicamente sera necesario indicar que servidor puede conectarse al puerto deescucha de Munin y obtener la informacion de la maquina. Esto se puede indicar editando elfichero /etc/munin/munin-node.conf :

Listado 4.64: Instalacion de la herramienta Munin (cliente) con apt-get

host_name lechuzo

allow ^212\.128\.4\.9 $

Los parametros mas importantes son el nombre que se mostrara en la pagina de Munin,y la IP que puede acceder al nodo para recopilar la informacion. Este parametro obviamentedependera de la maquina que recoja los datos de los clientes de Munin.

4.4.2. Monitorizacion de estaciones

La monitorizacion de estaciones de cara a los usuarios del sistema se llevara a cabo a traves deun 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 realizarsus practicas.

Figura 4.16: El parte de guerra de Mostoles muestra el estado de las estaciones.

En la imagen 4.16 puede observarse la visualizacion del parte de guerra para el campus deMostoles33. Como se puede observar, para cada estacion se representa mediante el color verde

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



el que la maquina tenga el servicio disponible (ping o ssh) y rojo en caso contrario. De estaforma, los alumnos saben en cada momento a que estacion se pueden conectar para realizarsus tareas. Alternativamente, se aplica el mismo script para el campus de Fuenlabrada34. Lasalida de esta pagina es bastante similar a la mostrada en la imagen 4.16. El parte de guerrase actualiza aproximadamente cada tres minutos mediante una tarea de cron en las maquinaspantuflo.escet.urjc.es y bilo.cct.urjc.es.

En el apendice adjunto al documento pueden consultarse los scripts que producen la salidacorrespondiente para ambos partes de guerra.

4.5. Seguridad

Para finalizar, el ultimo de nuestros objetivos sera elevar el grado de seguridad de todos losservicios disponibles. En concreto, vamos a centrar nuestros esfuerzos en tener controlados lossiguientes aspectos:

Limitar los accesos remotos a las maquinas clave para el correcto funcionamiento dellaboratorio (servidores, principalmente).

Detectar intrusiones en las estaciones mediante geolocalizacion de las conexiones de hostsremotos.

Deteccion de ataques de fuerza bruta en los intentos de autenticacion a las estaciones

Evaluar la debilidad de las contrasenas de los usuarios mediante la herramienta John theripper.

4.5.1. Limitar los accesos remotos

En primer lugar, vamos a impedir el acceso a aquellas maquinas que son crıticas para elcorrecto funcionamiento del Laboratorio. Principalmente, los servidores, tanto del campus deMostoles como el de Fuenlabrada. Aunque tambien, sera necesario limitar las conexiones enlos servidores LDAP para que solamente sea posible que se conecten a ellos estaciones de losLaboratorios.

Limitar el acceso SSH mediante los ficheros hosts.allow y hosts.deny

Para limitar el acceso SSH a los servidores, vamos a restringir la conectividad a redespertenecientes o bien al Departamento de Sistemas Telematicos o al Laboratorio. Esto es,a maquinas pertenecientes a la subredes 212.128.4.0/24, 193.147.71.0/24 para el Campus deMostoles, y 193.147.73.0/24 junto con la subred 193.147.71.0/24 para el Campus de Fuenlabrada.De esta forma, aseguramos que nadie pueda iniciar una sesion SSH en ningun servidor si no lohace desde dentro de alguna de nuestras redes. Esta norma se aplicara a todos los servidoresexcepto al servidor pantuflo y al servidor bilo, en los que se puede iniciar una sesion SSH enprincipio desde cualquier host.

Para poder llevar a cabo esta restriccion, haremos uso de los ficheros /etc/hosts.deny y/etc/hosts.allow. En concreto, en el fichero /etc/hosts.deny, debemos indicar que por defectose deniegue cualquier conexion SSH a no ser que alguna regla lo permita (descrita en el fichero/etc/hosts.allow. Por tanto, el fichero /etc/hosts.deny debe contener lo siguiente:

sshd: ALL

34http://bilo.cct.urjc.es


4.5. SEGURIDAD

De esta forma estamos indicando que el servicio SSH sera denegado a cualquier host, a no serque el fichero /etc/hosts.allow diga lo contrario. Y es aquı donde este fichero entra en juego:

sshd: 212.128.4. , 193.147.71. , 193.147.73.

Como vemos, es posible indicar mediante los tres primeros dıgitos de la IP desde que subredessı se admitira usar el servicio SSH. De esta forma, no podremos abrir una conexion SSHdesde fuera de estas tres subredes, lo que a priori, reducira considerablemente la probabilidadde que alguien ajeno a los laboratorios o al departamento intente nada contra estas maquinas.Si intentamos conectarnos a cualquiera de los servidores que incluyan estas restricciones,obtendremos el siguiente error:

ssh_exchange_identification : Connection closed by remote host

Limitar el acceso SSH mediante clave publica/privada

Si queremos aumentar aun mas el grado de seguridad a la hora de inicar una sesionSSH en cualquiera de los servidores, podemos desactivar el inicio de sesion mediantedesafıo pregunta/respuesta (el tradicional acceso introduciendo una contrasena), y activar laautenticacion unicamente usando mecanismos de criptografıa de clave publica/privada. De estaforma, sera necesario generar un par de claves, copiar la clave publica del host desde el quequeremos conectar al servidor en cuestion y anadirlo en el fichero authorized keys del directorio/root/.ssh/. De esta forma, solamente podran inciar sesion en el servidor aquellos usuarios queposean la clave privada y la palabra de paso que la desbloquea (en caso de que hayasido generada con contrasena). Ademas, en caso de perder la clave privada, no tendrıamos porque preocuparnos (demasiado) debido a que sin la palabra de paso, es una clave totalmente inutil.

Por tanto, para poder iniciar sesion en cualquiera de los servidores, necesitaremos cumplirestrictamente 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 ademas saber la palabra de paso que desbloquea la clave)

Como vemos, son dos requisitos suficientemente restrictivos que nos proporcionan bastantetranquilidad en la seguridad del servidor y disminuyen bastante la probabilidad de intrusion enla maquina.

Impedir la conexion a los servidores LDAP desde fuera de los Laboratorios

Los servidores LDAP, si nada lo impide, permiten que cualquier maquina pueda realizarpeticiones de lectura sin emplear ningun mecanismo de autenticacion previo. Debido a laarquitectura de LDAP como mecanismo de autenticacion, es necesario que de forma anonima,un usuario pueda realizar peticiones de lectura de su nombre de usuario (ademas de otra seriede datos), de forma totalmente anonima (de hecho, esto es lo que le permite autenticarse). Caberesenar que entre estos datos no se encuentra la contrasena, aunque existen otros que son tambienmuy sensibles, y que se pueden consultar de forma anonima si nada lo impide. La otra posibilidades introducir un usuario que permita leer los datos de todos los usuarios, incluıda la contrasena, yconfigurar los clientes para que se aten a este usuario para realizar operaciones de autenticacion.En nuestro caso hemos optado por el primer mecanismo, ya que configuraremos los servidores paraque no respondan a peticiones que vengan de maquinas que no se encuentran en los Laboratorios.



Para llevar a cabo esta restriccion, vamos a emplear el mismo mecanismo que en el puntoanterior, cuando limitabamos el acceso a los servidores mediante SSH: haciendo uso de los ficheroshosts.allow y hosts.deny. De esta forma, en cada servidor LDAP debemos incluir las subredesde todos los laboratorios (recordamos que las peticiones de autenticacion de un campus puedenresolverse en un servidor LDAP de otro campus, si todos los servidores de este campus se hancaido). De la misma forma que en el punto anterior, debemos denegar todas las conexionesal servicio slapd (encargado de atender las peticiones LDAP) desde cualquier host. Esta regladebe ser incluida en el fichero /etc/hosts.deny:

slapd: ALL

Y si queremos que se acepten conexiones al servicio slapd desde redes especıficas, solamentelo debemos indicar en el fichero /etc/hosts.allow:

slapd: 212.128.4. , 193.147.56. , 193.147.57. , 193.147.73.

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

4.5.2. Auditorıa de usuarios

Otro de los aspectos que es muy importante de cara a la seguridad general del sistema es laimplantancion de algun tipo de sistema de auditorıa, tanto de los usuarios que se encuentran en unmomento dado en el sistema como de los comandos que ejecutan en cualquiera de las estaciones.

En este sentido, no hemos encontrado ninguna aplicacion en sistemas operativos Linux querealize esta tarea de forma automatica. En concreto, para la auditorıa de comandos realizadospor los usuarios, existe un parche para el kernel de Linux llamado process accounting a travesdel cual, el kernel del sistema operativo vuelca en un fichero (situado en el directorio /proc) quepuede ser leido en principio por aplicaciones que obtienen en un formato legible por humanos lainformacion concerniente a los diversos comandos que los usuarios ejecutan en el sistema.

No obstante, esta informacion es demasiado verbosa, ya que anade una entrada por cadaproceso que el usuario ejecuta en un momento dado. Cuando realizamos algunas pruebas de estesistema de auditorıa nos encontramos con que en un solo dıa podemos obtener miles y miles delıneas de informacion (debido al elevado numero de estaciones y de usuarios) con el consecuenteproblema de almacenamiento que ello suponıa (ademas del indexado posterior en un momentodeterminado).

Sin embargo, la auditorıa de los usuarios conectados en el sistema en un momento dadono resulta ni tan verbosa ni tan costosa en terminos de almacenamiento. Es por ello que nosplanteamos la creacion de un sistema que registre en cualquier momento los usuarios que seencuentran logueados en el sistema, en cualquier maquina del laboratorio.

Como ya hemos comentado anteriormente, no encontramos ninguna aplicacion que nosresolviera esta funcionalidad de forma satisfactoria, por lo que optamos por programar nuestropropio sistema de auditorıa a medida. El sistema no debe tener grandes pretensiones: simplementedebe almacenar en un sistema de almacenamiento (por ejemplo, una base de datos) las entradasde los usuarios que en ese momento se encuentran en el sistema. Para ello, podemos apoyarnosen scripts basicos de shell que recojan la salida de comandos estandar de Unix que devuelvenla informacion relativa a los usuarios conectados en el sistema en un momento dado (como porejemplo los comandos w o who).

En principio, la informacion que nos gustarıa almacenar de cada usuario serıa la siguiente:

Host o estacion en la que el usuario se encuentra conectado o logueado.


4.5. SEGURIDAD

Consola en la que ha iniciado sesion (una consola virtual, de texto o la consola grafica).

Fecha y hora en la que ha iniciado sesion

Fecha y hora actual

Host remoto desde el que ha iniciado la sesion.

El almacenamiento de esta informacion en una base de datos MySQL supondra la creacionde una base de datos y una tabla a tal efecto. Para la informacion que necesitamos almacenar,podemos usar las siguientes sentencias de SQL mostradas en el el listado 4.65.

Listado 4.65: Creacion de una tabla en MySQL para almacenar la informacion relativa a auditorıade usuarios

CREATE TABLE ‘who ‘ (

2 ‘id ‘ int (20) NOT NULL auto_increment ,

‘hostname ‘ varchar (255) NOT NULL default ’’,

4 ‘logname ‘ varchar (12) NOT NULL default ’’,

‘pts ‘ varchar (255) NOT NULL default ’’,

6 ‘login ‘ datetime NOT NULL default ’0000-00-00 00:00:00 ’ ,

‘now ‘ datetime NOT NULL default ’0000-00-00 00:00:00 ’ ,

8 ‘from ‘ varchar (255) NOT NULL default ’’,

PRIMARY KEY (‘id ‘),

10 KEY ‘hostname ‘ (‘hostname ‘,‘logname ‘)

) ENGINE=MyISAM ;

Por supuesto asumimos que en cualquier host disponemos de un sistema gestor MySQL conlos permisos suficientes para realizar las anteriores tareas. Una vez que la base de datos ha sidocreada, podemos usar el script mostrado en el listado 4.66 para poder registrar la informacionrelativa a la auditorıa de usuarios:

Listado 4.66: Script basico para registrar informacion de auditorıa de usuarios

#!/bin/bash

2

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

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

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

8 for linea in ‘cat $TMP_FILE1 ‘; do

i=‘echo $linea | sed s/’_’/’ ’/g‘

10 HOSTNAME=‘hostname ‘

LOGNAME=‘echo $i | awk ’{print $1}’‘

12 PTS=‘echo $i | awk ’{print $2}’‘

DATE=‘echo $i | awk ’{print $3}’‘" "‘echo $i | awk ’{print $4}’‘

14 FROM=‘echo $i | awk ’{print $5}’ | sed s/’) ’/’’/g | sed s/’(’/’’/g‘

NOW=‘date + %F" " %T‘

16 echo "INSERT INTO who VALUES (’’,’"$HOSTNAME"’,’"$LOGNAME"’,’"$PTS"’,’"$DATE"’,’"$NOW

"’,’"$FROM"’)"

echo "INSERT INTO who VALUES (’’,’"$HOSTNAME"’,’"$LOGNAME"’,’"$PTS"’,’"$DATE"’,’"$NOW

"’,’"$FROM"’)" > $TMP_FILE2

18 done

20 cat $TMP_FILE2 | /usr/bin/mysql -u who -h $MYSQL_HOST --password=$MYSQL_PASSWORD

$MYSQL_DATABASE 1> /dev/null 2> /dev/null

22 rm $TMP_FILE1

rm $TMP_FILE2

A traves del script anterior, se registraran los usuarios que estan conectados en una maquinaen un momento dado. Combinando el script anterior con una sentencia de cron, podemos registrar



automaticamente todos los usuarios que esten conectados en una estacion, con una frecuencia muybaja (cada minuto). La siguiente lınea de cron puede ser suficiente para dejar definida la tarea:

Listado 4.67: Lınea de cron para la automatizacion de la auditorıa de usuarios en el sistema

*/1 * * * * sh /root/who -mostoles.sh

La posterior consulta de datos en un momento determinado, dado que estos son almacenadosen una base de datos MySQL, se puede realizar a traves de sentencias basicas de SQL. Incluso, sepuede realizar a traves de un portal PhpMyAdmin35, para minimizar la dificultad en la consultade estos datos.

4.5.3. Deteccion de intrusos

Deteccion de IPs no espanolas

Gracias al sistema que hemos disenado e implantado para registrar los accesos de los usuariosen cada una de las estaciones, podemos disenar diversos sistemas de alerta que nos avisen antesituaciones sospechosas. Una de estas situaciones podrıa ser la conexion en una estacion desde unhost remoto fuera de Espana. No es frecuente en el entorno que tenemos instalado que se conectenal laboratorio alumnos desde fuera del paıs, excepto contadas excepciones, las cuales podrıan serenumeradas en un fichero de nombres de usuario a no tener en cuenta por este monitor.

Para poder detectar si un host remoto pertenece o no al paıs, podemos usar la herramientageoiplookup, tal y como se muestra en el ejemplo mostrado en el listado 4.5.3. La ejecucion deeste comando devuelve el codigo de paıs correspondiente a la geolocalizacion del host.

agutierr@minervo ~ $ geoiplookup 212.128.4.4

GeoIP Country Edition: ES , Spain

Si a traves de la salida de este comando se detecta que la IP o host remoto no pertenece aEspana (es decir, haciendo busquedas por codigos no pertenecientes a ES, Spain tendremos unalista de IPs (combinando con la estacion y nombre de usuario que se ha usado en la conexion)cuanto menos, sospechosas de ser investigadas.

El monitor o script que realiza esta tarea puede ser consultado en el apendice de estedocumento. 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 suspracticas, existen unos lımites horarios a partir de los cuales ya no es muy frecuente encontrarusuarios conectados en las estaciones (si bien siempre existen alumnos a los que les gusta realizarsus practicas a altas horas de la madrugada). Debido a que encontrar usuarios trabajando a altashoras de la noche tambien puede ser sospechoso a priori, podemos programar otro monitor quenos alerte de los usuarios que han realizado conexiones nocturas, por ejemplo, entre las dos y lassiete de la madrugada.

Listado 4.68: Monitor de alerta de conexiones nocturnas en el laboratorio

DATE=‘date + %Y- %m- %d‘

2

TMPFILE=‘mktemp ‘

35Aplicacion que permite realizar operaciones de gestion y consulta sobre un sistema gestor MySQL a traves deun navegador.


4.5. SEGURIDAD

4

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 conexionnocturna en el presente dıa, entre las dos y las 7h del dıa en cuestion, tal y como muestra ellistado de codigo 4.68. Este volcado nos devolvera la lista de logins, estacion y fecha/hora en laque el usuario ha iniciado una sesion nocturna, que puede ser enviado por correo electronico a unadministrador del laboratorio, para su posterior estudio, por ejemplo.

Como se puede observar, las posibilidades que ofrece un sistema de auditorıa son bastanteelevadas, y puede resultar muy interesante estudiar estos registros, y no con fines necesariamentebasados en la seguridad del sistema. La generacion de estadısticas de uso de las estaciones,disponibilidad, etcetera, pueden ser tambien objetivo del uso de estos indicadores.

4.5.4. Ataques de fuerza bruta vıa SSH

Los ataques de fuerza bruta son muy frecuentes en ordenadores con sistema operativo Unix,con multitud de usuarios y con IPs publicas accesibles desde cualquier punto del mundo, en el queademas, se dispone de un rango entero de direcciones para poder intentar romper una contrasenay lograr estar dentro del sistema. Desde este punto de vista, nuestro sistema cumple con todoslos aspectos deseables para un intruso: disponemos de 160 maquinas con IPs publicas, servicioSSH y gran multitud de usuarios. Por si fuera poco, el conseguir entrar en una cuenta en unode los equipos, proporciona evidentemente acceso al resto. Resulta muy atractivo desde el puntode vista del intrusismo de sistemas el conseguir penetrar en un estacion de una red universitaria.Ya no solamente por el mero hecho de conseguirlo, sino por las consecuencias o las posibilidadesque esto puede traer. Debido a la gran cantidad de estaciones de las que dispone el laboratorioy la gran capacidad de ancho de banda del mismo, un ataque de denegacion de servicio lanzadoadecuadamente puede provocar la caida de cualquier sitio en Internet. En la traza del fichero/var/log/auth.log mostrada en el listado 4.69 podemos ver los intentos de conexion usandofuerza bruta para conseguir entrar en el sistema probando nombres de usuario y contrasenasaleatorios.

Listado 4.69: Intentos de ataque de SSH mediante fuerza bruta o diccionario

Jun 26 08:43:28 delta08 sshd [7699]: Invalid user staff from 82.187.180.163

2 Jun 26 08:43:36 delta08 sshd [7701]: Invalid user sales from 82.187.180.163

Jun 26 08:43:40 delta08 sshd [7703]: Invalid user recruit from 82.187.180.163

4 Jun 26 08:43:44 delta08 sshd [7705]: Invalid user alias from 82.187.180.163

Jun 26 08:43:49 delta08 sshd [7707]: Invalid user office from 82.187.180.163

6 Jun 26 08:43:54 delta08 sshd [7709]: Invalid user samba from 82.187.180.163

Jun 26 08:43:57 delta08 sshd [7712]: Invalid user tomcat from 82.187.180.163

8 Jun 27 21:48:29 delta08 sshd [17458]: Invalid user fluffy from 59.144.127.75

Vemos como, en el mismo dıa, y desde la misma IP, se intenta acceder al sistema usandonombres de usuario aleatorios (normalmente provenientes de diccionarios anglosajones) sin exito,por supuesto. Es por esto que reducir las posibilidades de que un atacante consiga una cuenta deun usuario mediante fuerza bruta sera un aspecto fundamental del sistema. Para lograr que estono 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 contrasenas de los usuarios, mediante la ejecucion periodicade herramientas del estilo de John the ripper.



Limitar la conectividad a un usuario segun el numero de intentos erroneos de autenticacion enun periodo determinado de tiempo es una tarea bastante sencilla, si se desea programar mediantescripts caseros y no usar ninguna aplicacion que ya permita realizar esta tarea. Basta auditarel fichero de autenticacion /var/log/auth.log en busca de entradas de autenticacion erronea,obtener el host remoto que ha iniciado la autenticacion e impedir la posterior autenticacion aeste usuario. Para impedir a este usuario que se vuelva a autenticar en el sistema podemosusar iptables, anadiendo reglas concretas de denegacion de servicio SSH para la IP concretacorrespondiente a su Host o incluyendo la IP correspondiente en el fichero /etc/hosts.deny.Hay que tener en cuenta que un numero muy extenso de reglas en IPTables puede provocar lasobrecarga del sistema a la hora de atender peticiones de red, por lo que se recomienda el uso delos ficheros /etc/hosts.allow y /etc/hosts.deny, como hemos visto anteriormente.

Sin embargo, la programacion de estos scripts y filtros, ademas del conseguiente uso deiptables para denegar o aceptar conexiones a determinados hosts puede resultar un tanto tediosa,por lo que en nuestro caso, vamos a usar una aplicacion que se encarga precisamente de filtrarlos intentos de ataques de fuerza bruta en el servicio SSH. Esta aplicacion es Denyhosts, yesta programada en Python. Ademas, se incluye como paquete Debian tanto en Debian establecomo en Ubuntu, por lo que la podremos instalar tanto en las estaciones de trabajo de los usuarioscomo en la mayorıa de los servidores.

DenyhostsComo hemos descrito anteriormente, Denyhosts36 es una herramienta que intenta eliminar

la mayorıa de los ataques de fuerza bruta mediante SSH, monitorizando para ello el fichero/var/log/auth.log en busca de intentos de acceso con usuarios inexistentes, o intentos deautenticacion erroneos. Una vez detectados estos intentos, clasificados como ataques, se incluira elhost que ha provocado tal intento en el fichero /etc/hosts.deny, impidiendo al host remoto laconectividad al puerto SSH de la vıctima, o directamente, a cualquier servicio. La herramientaDenyhosts es muy popular entre administradores de sistemas de todo el mundo, existiendo dehecho una base de datos de atacantes y atacados, que puede ser consultada y descargada porcualquier maquina que se encuentre ejecutando la herramienta. Esto permite prevenir de algunausando listas negras de atacantes que nos puedan atacar, aunque esta ultima caracterıstica, nosiempre es bien acogida, debido a que podemos clasificar a priori como atacante a una maquina queno lo es (supongamos un escenario en el que existe una red de maquinas que usan IPs privadas,saliendo a Internet mediante un NAT con una unica IP publica). Es por ello, que se deja aeleccion del administrador el descargar la base de datos de IPs de los atacantes mas frecuentes,o no. De la misma forma, y para que la caracterıstica anterior funcione, tambien podremosinformar de nuestros atacantes a la base de datos global de Denyhosts, para conocimiento delresto de administradores o de maquinas. Todo esto es facilmente configurable a traves del ficherode configuracion de Denyhosts.

La instalacion de Denyhosts es inmediata en sistemas basados en Debian. Una unica llamadaal gestor de paquetes basta para realizar la instalacion:

Listado 4.70: Instalacion de la herramienta Denyhostspantuflo :~# apt -get install denyhosts

Una vez instalada la herramienta, podemos configurar la multitud de opciones que permitenel funcionamiento a medida segun el grado de seguridad que queramos implantar en nuestramaquina. Para ello, podemos editar el fichero /etc/denyhosts.conf. Algunas de las opcionesmas importantes, pueden ser:

SECURE LOG, que indica la ruta hacia el fichero que se debe monitorizar.

36http://denyhosts.sourceforge.net/


4.5. SEGURIDAD

HOSTS DENY, que indica la ruta hacia el fichero donde deben incluirse los atacantespara la posterior denegacion del servicio SSH.

PURGE DENY, que indica el plazo de denegacion una vez que se incluye el atacante enel fichero HOSTS DENY. Este plazo puede indicarse en minutos, horas dıas, semanas, oanos. En el caso de las estaciones del Laboratorio, el tiempo de denegacion es de 12 horas.

DENY THRESHOLD INVALID, que indica el umbral de intentos con loginincorrecto. En el caso en el que se intente acceder al sistema con un usuario que noexiste un numero de veces igual a este valor mas uno, el host sera clasificado como atacantee incluido en el fichero HOSTS DENY. En el caso del Laboratorio este valor es de 5 intentos.

HOSTS DENY, muy similar al parametro anterior, pero para intentos con login validopero contrasena incorrecta. En el caso del Laboratorio, este valor es de 10 intentos.

DENY THRESHOLD ROOT, numero de intentos invalidos para el usuario root, apartir 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ıa de veces que seaccede como usuario root a las estaciones es con clave publica, y no mediante desafıo decontrasena. Por lo que, el monitorizar esta accion puede resultar cuanto menos, sospechoso.

SYNC UPLOAD, activando este parametro informaremos de nuestros atacantes a lapagina de Denyhosts, para compartirlos con el resto de usuarios.

SYNC DOWNLOAD, y de la misma forma, podremos descargar la informacion deatacantes del resto de usuarios mundiales de Denyhosts.

El fichero de configuracion de Denyhosts es bastante extenso, permitiendo un gran numero decombinaciones que permiten subir o bajar el nivel de seguridad a la hora de clasificar los intentosde ataques de fuerza bruta. Recomendamos la consulta de uno de los ficheros de configuracion deDenyhosts que se incluyen tanto en el apendice de este documento como en el soporte electronicoadjunto, correspondiente al fichero de configuracion que se usa en las estaciones del Laboratorio.

La aplicacion Denyhosts es casi fundamental para impedir la multitud de ataques diarios defuerza bruta que se producıan en el sistema antes de instalarla. Sin ella, debido a la debilidad delas contrasenas de los usuarios, tendrıamos multitud de intrusiones en las estaciones de usuario(como pasaba anteriormente, cuando no se usaba).

4.5.5. Seguridad en las contrasenas de los usuarios

Los intentos de securizar al maximo el sistema pueden resultar en vano si posteriormente,los usuarios emplean contrasenas debiles en sus cuentas. Esta situacion puede provocar que unusuario malicioso que tenga en su poder la lista de usuarios del sistema (lo cual no resulta muycomplicado) pueda sentir impulsos de romper las contrasenas de los usuarios. Esta accion puedellevarse de manera muy simple, y aunque como vimos en secciones anteriores, hemos intentadolimitar el numero de accesos por estacion y usuario incorrecto, el usuario textit malicioso puedetener suerte y conseguir hacerse con una cuenta ajena. Una vez que un usuario ajeno tiene accesoa una cuenta de usuario, los danos suelen basarse en el uso de las estaciones para lanzar ataquesDOS sobre sitios web, etcetera, accion que causa bastantes problemas de cara al funcionamientode la red dentro de la Universidad.

Sin duda, uno de los aspectos mas importantes del lado de la seguridad del sistema reside enconcienciar a los usuarios de que las contrasenas de sus cuentas deben cumplir al menos, unosrequisitos mınimos de seguridad. Aunque al principio y a lo largo del curso se informa a los



usuarios de esta situacion, no son pocos los que no hacen caso y deciden establecer contrasenasno muy seguras para sus cuentas. En este caso, nos vemos obligados a intentar avisarles de lasituacion personalmente y si deciden no hacer caso y como ultimo remedio, cambiar su contrasenaautomaticamente. Para intentar automatizar esta tarea al maximo, programamos un script quecon ayuda de la herramienta John the ripper compruebe la dureza de las contrasenas delsistema. Este script se ejecutara todas las noches tanto para las cuentas del campus de Mostolescomo para el de Fuenlabrada.

John the ripper

John the Ripper es un programa de criptografıa que aplica fuerza bruta para descifrarcontrasenas. Es capaz de romper varios algoritmos de cifrado o hash, como DES, SHA-1 y otros.Es una herramienta de seguridad muy popular, ya que permite a los administradores de sistemascomprobar que las contrasenas de los usuarios son suficientemente buenas. John the Ripper escapaz de autodetectar el tipo de cifrado de entre muchos disponibles, y se puede personalizar sualgoritmo de prueba de contrasenas. Eso ha hecho que sea uno de los mas usados en este campo.

Ejecutando John the ripper regularmente

Apoyandonos en la herramienta John the ripper, vamos a comprobar la dureza de lascontrasenas de los usuarios diariamente. El procedimiento a seguir sera el siguiente:

Descargar el fichero de usuarios del sistema (para cada campus) en formato LDIF.

Transformar ese fichero al formato clasico passwd/shadow. En este punto usaremos elscript auxiliar ldif2passwd, escrito en Perl.

Ejecutar John the ripper durante ocho horas, aproximadamente. Pasadas estas ochohoras, todos aquellos usuarios para los que su contrasena haya sido descifrada, seranavisados mediante correo electronico de la situacion. Seran avisados como mucho dosveces, ya que a la tercera, su cuenta sera desactivada temporalemente (su contrasenasera modificada automaticamente). La nueva contrasena sera elegida automaticamente conayuda del comando pwgen.

De esta forma, nos aseguramos que las contrasenas de los usuarios cumplen unos mınimosrequisitos de seguridad, y que la posibilidad de que un usuario pueda colarse a traves de unacuenta ajena es mınima. En el apendice de este documento, ası como en el soporte electronicoadjunto, puede consultarse el script que lleva a cabo esta tarea de forma automatica.


4.5. SEGURIDAD


Capıtulo 5Conclusiones

Con el capıtulo Conclusiones llegamos al final de este documento. En este breve capıtulo quesirve como cierre del proyecto evaluaremos si se han cumplido todos los hitos que nos planteabamosen un principio. A continuacion, intentaremos realizar una lista de todos los conocimientos quese han adquirido gracias a la realizacion del proyecto. Por ultimo, intentaremos plantear lıneasfuturas de trabajo que pueden servir como base para la continuacion de este proyecto, bien a travesde un proyecto perteneciente a un programa de postgrado o bien como un proyecto derivado paratitulaciones de grado.

105

5.1. LOGROS ALCANZADOS

5.1. Logros alcanzados

En esta seccion haremos un breve resumen por todos aquellos hitos que se han completadosatisfactoriamente durante la realizacion del proyecto.

Desarrollar un sistema de instalaciones masivas y completamente desatendidas:Se ha implementado un mecanismo de instalacion para sistemas Linux (en concreto para ladistribucion Ubuntu Linux) totalmente desatendido, que prepara un sistema listo para serusado en un entorno docente como en el que nos encontramos. El sistema esta personalizadopara los requisitos docentes del Departamento, pero puede ser adaptado para cualquierentorno docente o empresarial muy facilmente. Este sistema facilita la tarea al administradorde cara a realizar instalaciones masivas en cualquier entorno de una forma limpia, sencillay eficiente.

Implantar un sistema de cuentas de usuario y disco en red: Despues de evaluarlas diferentes alternativas de las que se disponıan para implementar un sistema de cuentasde usuario en red, se ha puesto en marcha un servicio de directorio basado en LDAP queproporciona un servicio de autenticacion de usuarios en entornos Unix. A traves de esteprotocolo los usuarios pueden iniciar una sesion en una estacion del Laboratorio y realizarsu trabajo diario. Ademas, se facilita un servicio de disco en red para que los usuariosdispongan de su propio directorio personal una vez que inician su sesion. Gracias a estedirectorio pueden almacenar sus practicas, ası como sus ficheros personales (documentos,apuntes, etcetera).

Dotar al entorno de una serie de servicios de valor anadido: Los hitos anterioresconforman las bases principales del proyecto. Sin embargo, una vez que estos objetivos secompletan, se dota al entorno con un conjunto de servicios que lo van a convertir en unentorno mas agradable y funcional de cara a los usuarios del mismo. Estos servicios son:

1. Pagina web del Laboratorio, donde se incluye la maxima documentacion delentorno de cara a los usuarios (horarios, preguntas de uso frecuente, noticias y notasde regimen interno de los Laboratorios, etcetera). Ademas se da la posibilidad a losusuarios de disponer de su propio espacio personal donde puedan colgar materialrelacionado con cualquiera de las asignaturas que cursan.

2. Sistema de correo electronico, se pone en marcha un sistema de correo electronicoque sirva como mecanismo de comunicacion entre los administradores del Laboratorioy los propios usuarios. Ademas, los usuarios pueden usar este buzon como cuenta decorreo electronico personal.

3. Listas de correo, las cuales son usadas para los anuncios que se envıen a todos losusuarios del sistema (en ambos Campus) ası como un mecanismo de envıo de alertassobre 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 lavelocidad de los procesos de instalacion de los sistemas y de cualquier software en losLaboratorios, se instala un mirror local en la organizacion de las distribuciones queusamos en el Laboratorio: Debian GNU/Linux y Ubuntu. Este mirror puede ser usadopor los propios alumnos desde sus portatiles o incluso en sus equipos personales decasa.

Instaurar un servicio de monitorizacion de la red y de los servicios: Se instala yconfigura una herramienta de monitorizacion de la red (Nagios) la cual nos va a permitir


CAPITULO 5. CONCLUSIONES

controlar en todo el momento el estado de nuestro entorno, tanto si las maquinas estantodas encendidas y funcionando como si estas se encuentran ejecutando todos los servicioscorrespondientes. Esta herramienta, fundamental en un entorno en el que nos encontramos,nos va a permitir detectar por medio de alertas enviadas por correo electronico cualquierproblema que se produzca en un plazo muy corto de tiempo.

Aumentar al maximo la seguridad del entorno: La seguridad en nuestro es un aspectobastante crıtico, debido a que el numero de estaciones es muy elevado, ası como la cantidadde cuentas de usuario. Al tener todas las estaciones direcciones IP publicas, digamos quehay muchas posibilidades de que si no se toma ninguna medida, un usuario anonimo fueracapaz de conseguir una cuenta de usuario de forma ilegıtima. A traves de las medidas quetomamos en esta seccion conseguimos aumentar la seguridad del entorno en tres frentesprincipales: establecer polıticas de acceso a servidores en funcion de la direccion IP delos clientes, intentar detectar los intentos de ataques de fuerza bruta al servicio SSH yrestringir el acceso desde esas IP, y revisar la fuerza de las contrasenas de los usuariosutilizando la herramienta John the ripper. Podemos concluir por la experiencia que graciasa 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 dotadocon una serie de conocimientos adquiridos que pueden suponer el inicio de una carrera o de unperfil basado en la administracion de sistemas, un perfil muy valorado hoy en dıa en el entornoempresarial. Estos conocimientos son, entre otros, los siguientes:

Conocimientos avanzados de entornos Unix/Linux: La administracion diaria deeste entorno supone una base muy solida en esta familia de sistemas operativos. Aunquelas distribuciones usadas en nuestro entorno han sido Debian GNU/Linux y Ubuntu,estos conocimientos son facilmente aplicables o extensibles a cualquier distribucion, ypor supuesto aplicable en cualquier sistema operativo de la familia Unix. En este sentidopodemos tambien garantizar los conocimientos adquiridos en la administracion diaria delentorno, en la creacion de scripts o guiones, lo que proporciona conocimientos en lenguajesde shell como bash, python o perl.

Procesos de instalaciones desatendidos para PCs: A traves de la construccion delproceso de instalacion desatendido de Ubuntu para las estaciones del Laboratorio, noshemos visto obligados a probar otras alternativas (era el caso de la clonacion de disco).Aunque no fue finalmente el metodo elegido como proceso de instalacion para nuestrosequipos, adquirimos bastantes conocimientos en la lınea de estas herramientas, muy usadasen entornos docentes o empresariales donde se requiere la instalacion clonica de sistemasoperativos de escritorio en general de numerosos equipos. Por supuesto, se han adquiridoconocimientos del metodo de los ficheros de preconfiguracion de paquetes o preseeds enDebian. Este metodo es muy potente y a medida que avance el tiempo y se documente unpoco mas sera muy usado en entornos empresariales y docentes.

Sistemas de cuentas de usuario en red: Dado que anteriormente la solucion enproduccion en el Laboratorio para proporcionar servicio de cuentas de usuario en red estababasada en la tecnologıa NIS de Sun Microsystems, podemos afirmar que se ha aprendido amanejar esta tecnologıa a administrar cuentas de usuario distribuidas usando este protocolo.Una vez planteado el cambio a un directorio LDAP, tuvimos que conocer el funcionamiento


5.3. TRABAJO FUTURO

de este protocolo y las aplicaciones que lo implementaban, como OpenLDAP, por lo quetambien hemos aprendido a manejar un directorio de usuarios basado en LDAP, con todolo que ello conlleva. Ademas, se han llevado a cabo configuraciones avanzadas de servidoresLDAP, incluyendo replicacion, tolerancia a fallos y seguridad en las comunicaciones. Estosconocimientos son particularmente interesantes ya que LDAP supone ya casi un estandarde facto como mecanismo de autenticacion de usuarios, por su flexibilidad y sencillez.

Aplicaciones de servidor en entornos Unix: Debido a la implantacion de diferentesservicios de valor anadido. En concreto, podemos enumerar los siguientes:

1. Apache, como servidor de paginas web, para la publicacion de la pagina web delLaboratorio ası como la gestion de las paginas web de usuarios.

2. Dovecot como servidor de recogida de correo POP3 e IMAP y postfix como agentede transporte de correo electronico.

3. NFS como sistema de ficheros en red, para facilitar el uso de directorios personalespor parte de los usuarios.

4. Soluciones RAID para poder proporcionar un servicio de disco en red losuficientemente grande para dar espacio a todas las cuentas de usuario que poseeel sistema. En particular, se ha usado la herramienta mdadm para la gestion delRAID vıa software, tomando nociones de los diferentes niveles de RAID existentes yponiendolo en practica.

5. Mailman como gestor de listas de correo para el envıo de anuncios a los usuarios delLaboratorio, y el envıo de alertas por parte del sistema de monitorizacion.

6. MediaWiki como gestor de contenidos para la pagina web de los Laboratorios de losCampus de Mostoles y Fuenlabrada.

7. Munin y Nagios como herramientas de monitorizacion. En concreto Munin esta masorientado a conocer el estado particular de una maquina (un servidor) y Nagiosmas orientado a conocer el estado de la red, enviando alertas ante cualquier tipo deincidencia que se encuentre.

5.3. Trabajo futuro

Por ultimo y de forma muy breve, se comentan algunas lıneas de investigacion o de desarrollofuturas basadas en todo el trabajo desarrollado:

Creacion de una herramienta personalizada para la administracion de cuentas en elLaboratorio. Dicha herramienta podrıa tratarse de una aplicacion web, para que puedaser usada en principio tanto por los administradores del Laboratorio como por los propiosprofesores.

Uso de virtualizacion en los servidores. En vez de usar maquinas fısicas, se podrıanvirtualizar todos aquellos servidores que se consideraran oportunos. La tecnica de lavirtualizacion esta muy de moda hoy en dıa y supone un gran avance en la administracionde sistemas. A traves de ella se consigue que en un mismo servidor se puedan ejecutarmultiples servidores virtuales aislados y seguros.

Creacion de herramientas para la sincronizacion y la instalacion automatica de paquetes.Ahora mismo, la sincronizacion en la instalacion de los paquetes ası como en los propiosficheros de cada maquina es totalmente manual.


Apendice AScripts de Instalacion Automatica

En el siguiente apendice se incluiran todos aquellos ficheros de preconfiguracion necesariospara la herramienta de instalacion automatica desarrollada para los Laboratorios. En concretoy para este caso, no hay muchos ficheros importantes: el fichero de preconfiguracion para lainstalacion, el fichero de Isolinux necesario para el arranque por red y posterior comienzo de lainstalacion y los ficheros de configuracion del servidor DHCP.

i

A.1. FICHERO DE PRECONFIGURACION GENERICO

A.1. Fichero de preconfiguracion generico

El siguiente fichero de preconfiguracion se usa para la instalacion del Laboratorio 111 de losLaboratorios de Linux de la ETSII, en el Campus de Mostoles. Sin embargo, la adaptacion acualquier otro equipo o instalacion es extremadamente simple, unicamente es necesario modificarel esquema de particionado del disco y si se desea, el script de postinstalacion que realiza losajustes necesarios una vez que se ha instalado el sistema base.

Listado A.1: El fichero de preconfiguracion necesario para la instalacion desatendida.## Network Configuration

# Note that any hostname and domain names assigned from dhcp take

# precidence over values set here. However , setting the values still

# prevents the questions from being shown even if values come from dhcp.

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

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

25 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 device name can

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

35

# Si no , puede colocar la receta en una lınea. Este ejemplo crea una particion

# /boot peque~na , una particion de intercambio apropiada y usa el resto del

# espacio para la particion raız:

d-i partman -auto/expert_recipe string boot -root :: 300 7000 40000 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 } .

40

#d-i partman -auto/expert_recipe string boot -root :: 20 10000 10000000 ext3 $primary{ }

$bootable{ } method{ format } format{ } use_filesystem{ } filesystem{ ext3 }

mountpoint{ / } . 500 10000 1000000000 ext3 method{ format } format{ } use_filesystem{

} filesystem{ ext3 } mountpoint{ /data } . 64 512 300 % linux -swap method{ swap }

format{ } .

# en un formato mas legible:

45 # boot -root ::

# 40 50 100 ext3

# $primary{ } $bootable{ }

# method{ format } format{ }

# use_filesystem{ } filesystem{ ext3 }

50 # mountpoint{ /boot }

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 }

55 # mountpoint{ / }

# .

# 64 512 300 % linux -swap

# method{ swap } format{ }

# .

60

# This makes partman automatically partition without confirmation.

d-i partman/choose_partition select Finish partitioning and write changes to

disk

d-i partman/confirm boolean true

65 ## Boot loader

# This is fairly safe to set , it makes grub install automatically 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

70 # too , which is less safe as it might not be able to boot that other 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)

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

80 d-i finish -install/reboot_in_progress note

d-i apt -setup/uri_type select http

d-i apt -setup/country select enter information manually

d-i apt -setup/hostname string peloto.escet.urjc.es

d-i apt -setup/directory string /ubuntu/

85 d-i apt -setup/another boolean false

d-i apt -setup/security -updates boolean false

d-i apt -setup/security_host string peloto.escet.urjc.es

d-i apt -setup/main boolean true

d-i apt -setup/universe boolean true

90 d-i apt -setup/multiverse boolean true

d-i apt -setup/restricted boolean true

d-i apt -setup/backports boolean true

## Zona horaria

95 d-i time/zone string Europe/Madrid

## comando final , termina de ajustar el host con los parametros y aplicaciones del

laboratorio

d-i preseed/late_command string wget http :// espatula.pantuflo.es/preseeds/hardy

/111/ ajustes/ajusta -instalacion.sh; chmod +x ajusta -instalacion.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/choose_country_zone_single boolean true

105 ###### Account setup.

#### Stolen from oem.seed

# Create a special user with a preconfigured uid.

#passwd passwd/user -fullname string OEM Configuration (temporary user)

#passwd passwd/username string oem

110 #passwd passwd/user -uid string 29999

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

115 # passwd/root -password password r00tme

# passwd/root -password -again password r00tme

A. Gutierrez Mayoral iii ETSI Informatica

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 passwd/user -fullname string agutierr

d-i passwd/username string agutierr

d-i passwd/user -password -crypted passwd $1$ascCqW.t$bfUOFHDQLpBmpr9dOrP .a0

125

## Package selection

#d-i pkgsel/install -pattern string ~tûbuntu -standard$ |~nôpenssh -server$ |~n^

ubuntu -desktop$

#d-i pkgsel/install -pattern string ~tûbuntu -desktop$ |~nôpenssh -server$

d-i tasksel/first multiselect ubuntu -desktop

130 # You can choose to install any combination of tasks that are available.

# Available tasks as of this writing include: Desktop environment ,

# 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

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

#tasksel tasksel/first multiselect Web server , Mail server , DNS server

# d-i tasksel tasksel/first multiselect spanish

140

# 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/dc_eximconfig_configtype select no configuration at this

time

#d-i exim4 -config exim4/dc_postmaster string

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

# you override whatever it chooses. Still , vesa will work most places.

#xserver -xorg xserver -xorg/config/device/driver select 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 possibility of

# an infinite loop if the mouse is not autodetected.

#xserver -xorg xserver -xorg/autodetect_mouse boolean true

160 # d-i xserver -xorg xserver -xorg/autodetect_monitor boolean true

#xserver -xorg xserver -xorg/config/monitor/selection -method select medium

#xserver -xorg xserver -xorg/config/monitor/mode -list select 1024 x768 @ 60 Hz

#xserver -xorg xserver -xorg/config/display/modes multiselect 1024x768 , 800 x600

165 # 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 touch keymap

# keyboard layouts

170 #console -data console -data/keymap/qwerty/layout select ES spanish

#console -data console -data/keymap/family select qwerty

#console -common console -data/keymap/family select qwerty

#

175 # preguntas de ldap

# LDAP version to use:

# Choices: 3, 2

ldap -auth -config ldap -auth -config/ldapns/ldap_version select 3

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

Proyecto Fin de Carrera iv Universidad Rey Juan Carlos


185 ldap -auth -config ldap -auth -config/ldapns/base -dn string dc=example ,dc=netfindme

# Does the LDAP database require login?

ldap -auth -config ldap -auth -config/dblogin boolean false

# Make local root Database admin:

ldap -auth -config ldap -auth -config/dbrootlogin boolean false

190 # LDAP account for root:

ldap -auth -config ldap -auth -config/rootbinddn string cn=manager ,dc=example ,dc=

net

# LDAP root account password:

ldap -auth -config ldap -auth -config/rootbindpw password

195 # not manage with debconf

ldap -auth -config ldap -auth -config/move -to -debconf select No

ldap -auth -config ldap -auth -config/move -to -debconf boolean false

#ldap -auth -config ldap -auth -client/move -to -debconf boolean false

200 ldap -auth -client ldap -auth -client/move -to -debconf select No

ldap -auth -client ldap -auth -client/move -to -debconf boolean false

ldap -auth -config ldap -auth -config/override boolean false

205 clock -setup clock -setup/utc boolean false

# ajustes finales

d-i preseed/late_command string wget http :// espatula.pantuflo.es/preseeds/hardy

/111/ ajustes/ajusta -instalacion; chmod +x ajusta -instalacion; sh ajusta -instalacion

A.2. Configuracion Isolinux

Ademas del fichero de preconfiguracion, es necesario modificar el fichero Isolinux para quearranque con el fichero de preconfiguracion que se detalla anteriormente. Estos detalles seespecifican en el capıtulo de Implantacion del presente documento. A continuacion mostramos elfichero de configuracion de Isolinux necesario para llevar a cabo esta accion.

Listado A.2: Fichero de configuracion de Isolinux para el arranque por red.

DISPLAY ubuntu -installer/i386/boot -screens/boot.txt

F1 ubuntu -installer/i386/boot -screens/f1.txt


5 F3 ubuntu -installer/i386/boot -screens/f3.txt





10 F8 ubuntu -installer/i386/boot -screens/f8.txt



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 fichero depreconfiguracion correspondiente con la directiva preseed/url.

A. Gutierrez Mayoral v ETSI Informatica

A.3. FICHERO DE CONFIGURACION DEL SERVIDOR DHCP

A.3. Fichero de configuracion del servidor dhcp

Por ultimo, para que el equipo sea capaz de arrancar correctamente por red, es necesarioponer en marcha un servidor DHCP que despache direcciones IP y el resto de la configuracionpor red necesaria para esta tarea. El fichero de configuracion del demonio DHCP que lleva a caboesta labor se muestra a continuacion. Para no exceder en numero de lıneas del documento, semuestra unicamente la entrada para un host en concreto (el host beta01 ) ya que la configuraciones similar para N hosts. En el soporte electronico adjunto se puede encontrar el fichero en sutotalidad, para los 160 hosts existentes en el Laboratorio.

Listado A.3: Fichero de configuracion de Isolinux para el arranque por red.

#

# Sample configuration file for ISC dhcpd for Debian

#

# Attention: If /etc/ltsp/dhcpd.conf exists , that will be used as

5 # 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 default to the

# behavior of the version 2 packages (’none ’, since DHCP v2 didn ’t

# have support for DDNS.)

ddns -update -style none;

15

# option definitions common to all supported networks ...

option domain -name "pantuflo.es";

option domain -name -servers 212.128.4.1 , 212.128.4.3;

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

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

30

# No service will be given on this subnet , but declaring it helps the

# DHCP server to understand the network topology.

#subnet 212.128.4.0 netmask 255.255.255.0 {

35 #}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {

40 # range 10.254.239.10 10.254.239.20;

# option routers rtr -239-0-1. example.org , rtr -239-0-2. example.org;

#}

# This declaration allows BOOTP clients to get dynamic addresses ,

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

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

55 # range 212.128.4.19 212.128.4.254;

Proyecto Fin de Carrera vi Universidad Rey Juan Carlos


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;

60 default -lease -time 400;

max -lease -time 7200;

}

# Hosts which require special configuration options can be listed in

65 # host statements. If no address is specified , the address will be

# allocated dynamically (if possible), but the host -specific information

# will still come from the host declaration.

#host passacaglia {

70 # hardware ethernet 0:0:c0:5d:bd:95;

# filename "vmunix.passacaglia ";

# server -name "toccata.fugue.com";

#}

75 # Fixed IP addresses can also be specified for hosts. These addresses

# should not also be listed as being available for dynamic assignment.

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

80 # to which a BOOTP client is connected which has the dynamic -bootp flag

# set.

#host fantasia {

# hardware ethernet 08:00:07:26: c0:a5;

# fixed -address fantasia.fugue.com;

85 #}

# You can declare a class of clients and then do address allocation

# based on that. The example below shows a case where all clients

# in a certain class get addresses on the 10.17.224/24 subnet , and all

90 # other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {

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

#}

95

#shared -network 224-29 {

# subnet 10.17.224.0 netmask 255.255.255.0 {

# option routers rtr -224. example.org;

# }

100 # subnet 10.0.29.0 netmask 255.255.255.0 {

# option routers rtr -29. example.org;

# }

# pool {

# allow members of "foo";

105 # range 10.17.224.10 10.17.224.250;

# }

# pool {

# deny members of "foo";

# range 10.0.29.10 10.0.29.230;

110 # }

#}

#

host beta01 {

115 hardware ethernet 00:0F:1F:E4:A9:20;

fixed -address 212.128.4.19;

next -server 212.128.4.12;

filename "hardy /111/ pxelinux .0";

}

A. Gutierrez Mayoral vii ETSI Informatica

A.3. FICHERO DE CONFIGURACION DEL SERVIDOR DHCP

Proyecto Fin de Carrera viii Universidad Rey Juan Carlos

Apendice BScripts adicionales

En el presente apendice incluimos la mayorıa de los scripts que se usan a diario en laadministracion de todo el entorno. Los mas importantes son los scripts de copias de seguridad,sobre todo aquellos que se ocupan de realizar una copia de seguridad de los ficheros personalesde los usuarios (de forma diaria, en otra maquina). Tambien son muy importantes todos losscripts que se usan para poder iniciar una sesion SSH en cualquier estacion del Laboratorio comousuario root o superusuario, sin necesidad de incluir la contrasena correspondiente. A traves deestos scripts se realizan diferentes tareas, como la instalacion de paquetes, la sincronizacion dealgun directorio en particular o la actualizacion de todos los paquetes del sistema. Sin duda sinestos scripts estarıamos en un serio problema, ya que tendrıamos que realizar cada accion equipopor equipo introduciendo la contrasena correspondiente del superusuario.

ix

B.1. SCRIPTS DE COPIAS DE SEGURIDAD

B.1. Scripts de copias de seguridad

B.1.1. 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

5 LOG=/var/log/backups/log_backups_ ‘date + %Y- %m- %d‘

RSYNC =/usr/bin/rsync

## CUIDADO: PONEMOS -S (sparse) en rsync para manejar adecuadamente

## los ficheros sparse. Si no lo ponemos , la copia ocuparıa tanto que

10 ## no cabrıa en el servidor.

echo "Hora de comienzo: " ‘date ‘ >> $LOG

for i in ‘ls $DIR_ORIGEN ‘; do

15 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 =500M \

--exclude ="debian -mirror *" \

20 --exclude ="*. mp3" \

--exclude ="*. avi" \

--exclude ="*. mpg" \

--exclude =".*" \

--include =". forward" \

25 --include =". ssh" \

$DIR_ORIGEN/$i root@212 .128.4.6: $DIR_DESTINO

done

echo "Hora de fin: " ‘date ‘ >> $LOG

30

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

5 LOG=/var/log/backups/log_backups_ ‘date + %d- %m- %Y‘

/etc/init.d/nscd stop

sleep 5

10



## no cabrıa en el servidor.

15 if [ ! "‘pidof backup -nano.sh ‘" ] ; then

for i in ‘ls $DIR_ORIGEN ‘

do

echo Haciendo backup a nano >> $LOG

Proyecto Fin de Carrera x Universidad Rey Juan Carlos

APENDICE B. SCRIPTS ADICIONALES

echo *origen $DIR_ORIGEN/$i >> $LOG

20 echo *destino $DIR_DESTINO/$i >> $LOG

rsync -arzvvS $DIR_ORIGEN/$i --max -size =500M --exclude ="debian -mirror *" --exclude ="*.

mp3" --exclude ="*. avi" --exclude ="*. mpg" --exclude =".*" --delete --exclude ="*. disk

" [email protected]:$DIR_DESTINO

done

echo ------------------------------------------------------------------- >>$LOG

echo BACKUP A NANO TERMINADO >> $LOG

25 echo ------------------------------------------------------------------- >>$LOG

fi

mail -s "Backup bilo -> nano ‘date + %d- %m- %Y‘" pantuflo [email protected] <

$LOG

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

5 LOG=/var/log/backups/log_backups -usb_ ‘date + %d- %m- %Y‘



## no cabrıa en el servidor.

10

if [ ! "‘pidof backup -usb.sh ‘" ] ; then


do

echo Haciendo backup a USB >> $LOG

15 echo *origen $DIR_ORIGEN/$i >> $LOG


rsync -arzvvS --delete $DIR_ORIGEN/$i $DIR_DESTINO

done

echo ------------------------------------------------------------------- >>$LOG

20 echo BACKUP SAPIENTIN -USB TERMINADO >> $LOG

echo ------------------------------------------------------------------- >>$LOG

fi

mail -s "Backup sapientin ->disco usb en ‘date ‘" pantuflo [email protected] <

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

5 LOG=/var/log/backups/log_backups -usb_ ‘date + %d- %m- %Y‘



## no cabrıan en el servidor.

10

if [ ! "‘pidof backup -usb.sh ‘" ] ; then


do

A. Gutierrez Mayoral xi ETSI Informatica

B.2. SCRIPT DE COPIA DE SEGURIDAD DEL DIRECTORIO LDAP

echo Haciendo backup a USB >> $LOG

15 echo *origen $DIR_ORIGEN/$i >> $LOG


rsync -arzvvS --delete $DIR_ORIGEN/$i $DIR_DESTINO

done

echo ------------------------------------------------------------------- >>$LOG

20 echo BACKUP SAPIENTIN -USB TERMINADO >> $LOG

echo ------------------------------------------------------------------- >>$LOG

fi

mail -s "Backup nano -> disco usb en ‘date ‘" pantuflo [email protected] <

$LOG

B.2. Script de copia de seguridad del directorio LDAP

Listado B.5: Script backup-ldap.sh

#!/bin/bash

DATE=‘date + %F‘

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

B.3. Auditorıa de usuarios

La auditorıa de usuarios nos permite saber en todo momento los usuarios que iniciaron unasesion en el Laboratorio en un momento determinado, con todo lujo de detalles: nombre de usuario,maquina en la que iniciaron una sesion, fecha y hora del inicio de la sesion, etcetera. Estos datos sealmacenan en una base de datos MySQL, mediante scripts de Shell que se ejecutan cada minuto,en cada una de las estaciones del Laboratorio. A continuacion mostramos el script de creacion dela base de datos y el de insercion de datos.

B.3.1. Creacion de la base de datos

Listado B.6: Creacion de la base de datos de Auditorıa

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

5 ‘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 ‘),

10 KEY ‘hostname ‘ (‘hostname ‘,‘logname ‘)

) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT =8599042 ;

B.3.2. Insercion de los datos de auditorıa

Listado B.7: Script who-mostoles.sh

#!/bin/bash

Proyecto Fin de Carrera xii Universidad Rey Juan Carlos




5

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

for linea in ‘cat $TMP_FILE1 ‘; do

i=‘echo $linea | sed s/’_’/’ ’/g‘

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

15 NOW=‘date + %F" " %T‘

echo "INSERT INTO who VALUES (’’,’"$HOSTNAME"’,’"$LOGNAME"’,’"$PTS"’,’"$DATE"’,’"

$NOW"’,’"$FROM"’)"

echo "INSERT INTO who VALUES (’’,’"$HOSTNAME"’,’"$LOGNAME"’,’"$PTS"’,’"$DATE"’,’"

$NOW"’,’"$FROM"’)" > $TMP_FILE2

done

20 cat $TMP_FILE2 | /usr/bin/mysql -u who -h 212.128.4.12 --password =??????? who -escet 1> /

dev/null 2> /dev/null

rm $TMP_FILE1

rm $TMP_FILE2

B.4. Scripts ssh-a-todos y scp-a-todos

Los scripts llamados ssh-a-todos son algo imprescindible en el sistema. A traves de ellos,conseguimos iniciar una sesion SSH desde un servidor o estacion a todos las estaciones delLaboratorio, como usuario root, sin necesidad de introducir ninguna contrasena. Gracias a esto,podemos copiar ficheros, sincronizar directorios, instalar software, en definitiva, lanzar cualquiercomando en cualquier estacion o en un grupo de estaciones de forma totalmente automatica.

Para realizar esta tarea se utiliza un mecanismo de autenticacion por clave publica-privada,conteniendo la clave publica del servidor desde el cual iniciamos una sesion en el fichero/root/.ssh/authorized keys de todas las maquinas del laboratorio.

B.4.1. Scripts ssh-a-todos

Disponemos de un script que inicia una sesion SSH a un laboratorio concreto (sala alpha,beta, gamma o delta) o un script que realiza un SSH a todos las estaciones (las cuatro aulas).

Listado B.8: Script sshatodos-alphas.sh

#!/bin/bash

for i in ‘seq -w 01 40‘; do

echo alpha$i

ssh alpha$i "$1"

5 done

Listado B.9: Script sshatodos-betas.sh

#!/bin/bash


echo beta$i

ssh beta$i "$1"

5 done

A. Gutierrez Mayoral xiii ETSI Informatica

B.4. SCRIPTS SSH-A-TODOS Y SCP-A-TODOS

Listado B.10: Script sshatodos-gammas.sh

#!/bin/bash


echo gammaa$i

ssh gamma$i "$1"

5 done

Listado B.11: Script sshatodos-deltas.sh

#!/bin/bash


echo deltaa$i

ssh delta$i "$1"

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

5 ssh $i$j "$1"

done

done

B.4.2. Scripts scp-a-todos

Disponemos de un script que inicia una sesion SCP a un laboratorio concreto (sala alpha,beta, gamma o delta) o un script que realiza un SCP a todos las estaciones (las cuatro aulas).

Listado B.13: Script scpatodos-alphas.sh

#!/bin/bash


echo scp $1 alpha$j:$2

scp $1 alpha$j:$2

5 done

Listado B.14: Script scpatodos-betas.sh

#!/bin/bash


echo scp $1 beta$j:$2

scp $1 beta$j:$2

5 done

Listado B.15: Script scpatodos-gammas.sh

#!/bin/bash


echo scp $1 gamma$j:$2

scp $1 gamma$j:$2

5 done

Listado B.16: Script scpatodos-deltas.sh

#!/bin/bash

Proyecto Fin de Carrera xiv Universidad Rey Juan Carlos



echo scp $1 delta$j:$2

scp $1 delta$j:$2

5 done

Listado B.17: Script scpatodos.sh

#!/bin/bash

for i in ‘echo alpha beta gamma delta ‘; do


echo scp $1 $i$j:$2

5 scp $1 $i$j:$2

done

done

B.5. Script de debilidad de contrasenas

Como indicamos en el capıtulo 4 (Implantacion), diriamente se comprueba la debilidad delas contrasenas de los usuarios, utilizando la herramienta John the Ripper. Para automatizaresta tarea, se ha desarrollado un script para cada Campus que comprueba la debilidad de lascontrasenas en cada una de las ramas del directorio LDAP: para los usuarios cuya cuenta seencuentra en el subarbol de Mostoles ası como para los que su cuenta se encuentra en el subarbolde Fuenlabrada. Dichos scripts tienen por nombre john-laboratorio-mostoles para el Campusde Mostoles y john-laboratorio-fuenla para el Laboratorio de Fuenlabrada.

Listado B.18: Script john-laboratorio-mostoles

#!/bin/bash

START_STOP_DAEMON =/sbin/start -stop -daemon

JOHN=/var/local/john/john

5

FICHERO_ALERTAS =/etc/john -alertas

EMAIL_AVISO =/etc/mail -aviso -mala -pass

LDAPPASSWD =/usr/bin/ldappasswd

10 LDIF2PASSWD =/usr/bin/ldif2passwd.pl

LDAPSEARCH =/usr/bin/ldapsearch

MAIL=/usr/bin/mail

15 ## 1) Si el argumento es ’start ’, ejecutamos john the ripper con el fichero

## de passwords del mismo dia ...

## 2) Si el argumento es ’stop ’, matamos el proceso john y recogemos los usuarios

## de los que ha averiguado la password.

20

## Para cada usuario devuelto , lo metemos en /etc/john -alertas en el siguiente formato:

## usuario:num aviso

## con la siguiente regla:

## - Si el usuario no estaba en el fichero , introducimos -> login :1

25 ## - Si el usuario YA estaba en el fichero , introducimos -> login :(n+1)

##

## Procesamos el fichero /etc/john -alertas en busca de los usuarios que tengan el aviso

## a 3. En ese caso , se modifica aleatoriamente la password del usuario , y lo eliminamos

## del fichero.

30 ##

## Para todos los usuarios restantes del fichero , se les envia un correo adviertiendo de

## la situacion , con la posibilidad de que cambien su password.

##

35 ## Introduce al usuario en el fichero $FICHERO_ALERTAS

A. Gutierrez Mayoral xv ETSI Informatica

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 ‘" != "" ];

40 then

NUM_AVISO=‘cat $FICHERO_ALERTAS | grep ^$1 | cut -d: -f2 ‘

NUM_AVISO=‘echo $NUM_AVISO +1 | bc ‘


cat $FICHERO_ALERTAS | grep -v $1 > $TMPFILE

45 echo $1:$NUM_AVISO >> $TMPFILE

mv $TMPFILE $FICHERO_ALERTAS

else

echo "$1:1" >> $FICHERO_ALERTAS

fi

50 }

## cambia la password de un usuario a una password generada automaticamente .

function desactiva_usuario () {

PASSWORD_ALEATORIA =‘pwgen -N 1 -c 12‘

55 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 $PASSWORD_ALEATORIA -w e7ds ,enua

$DN_USER

echo "Se desactiva la cuenta por password mala malisima ." | $MAIL -s "

Desactivacion de cuenta usuario (mostoles) $1" agutierr@gsyc .escet.urjc.es


Desactivacion de cuenta usuario (mostoles) $1" pantuflo -cuentas -

anuladas@pantuflo .escet.urjc.es

}

60

## busca en el fichero de alertas aquellos usuarios que tengan

## el numero de avisos =3. A estos usuarios , se les cambia la password 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 desactivadas.

65 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

70 case $NUM_INTENTOS in

"1")

cat $EMAIL_AVISO | mail -s "[ laboratorios -linux -mostoles ]

Primer aviso , detectada mala password"

$USUARIO@pantuflo .escet.urjc.es


Primer aviso , detectada mala password [$USUARIO ]"

pantuflo -cuentas -anuladas@pantuflo .escet.urjc.es



[email protected]

75 ;;

"2")


Segundo aviso , detectada mala password"

$USUARIO@pantuflo .escet.urjc.es


Segundo aviso , detectada mala password [$USUARIO ]"




[email protected]

80 ;;

"3")

## se desactiva la cuenta del usuario

desactiva_usuario $USUARIO


85 cat $FICHERO_ALERTAS | grep -v $USUARIO > $TMPFILE


;;

esac

Proyecto Fin de Carrera xvi Universidad Rey Juan Carlos


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 () {

95 TMPFILE1=‘mktemp ‘

for i in ‘echo $1 ‘; do

echo $i >> $TMPFILE1

done

echo "Usuarios que han salido ahora :" "$1"


for j in ‘cat $FICHERO_ALERTAS ‘; do

USER=‘echo $j | cut -d: -f1 ‘

echo $USER

if [ "‘cat $TMPFILE1 | grep $USER ‘" != "" ];

105 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

110 echo "Quitando al usuario $j del fichero ..."

fi

done

/bin/mv $TMPFILE2 $FICHERO_ALERTAS

115 }

## vuelca el arbol ldap en un fichero de texto

function vuelca_ldap () {

TMPFILE=‘mktemp -p /var/tmp/john ‘

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

}

125 case $1 in

start )

TMPFILE=‘mktemp -p /var/tmp/john/‘

LDAP_FILE=‘vuelca_ldap ‘

cat $LDAP_FILE | $LDIF2PASSWD > $TMPFILE

130 $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 -laboratorio.pid


135 LDAP_FILE=‘vuelca_ldap ‘


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

140 for i in ‘echo $USUARIOS_ALERTA ‘; do

alerta_usuario $i

done

# los usuarios del fichero $FICHERO_ALERTAS que no hayan salido (se

presupone que han cambiado su pass)

# son borrados del fichero ...

145 #alerta_inversa $USUARIOS_ALERTA

/bin/rm /var/local/john/john.pot

/bin/rm /var/tmp/john/*

;;

alerta )

150 comprueba_alertas

A. Gutierrez Mayoral xvii ETSI Informatica


;;

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

10 LDIF2PASSWD =/usr/bin/ldif2passwd.pl

LDAPSEARCH =/usr/bin/ldapsearch

MAIL=/usr/bin/mail

15 ## 1) Si el argumento es ’start ’, ejecutamos john the ripper con el fichero

## de passwords del mismo dia ...

## 2) Si el argumento es ’stop ’, matamos el proceso john y recogemos los usuarios

## de los que ha averiguado la password.

20

## Para cada usuario devuelto , lo metemos en /etc/john -alertas en el siguiente formato:

## usuario:num aviso

## con la siguiente regla:

## - Si el usuario no estaba en el fichero , introducimos -> login :1

25 ## - Si el usuario YA estaba en el fichero , introducimos -> login :(n+1)

##

## Procesamos el fichero /etc/john -alertas en busca de los usuarios que tengan el aviso

## a 3. En ese caso , se modifica aleatoriamente la password del usuario , y lo eliminamos

## del fichero.

30 ##

## Para todos los usuarios restantes del fichero , se les envia un correo adviertiendo de

## la situacion , con la posibilidad de que cambien su password.

##

35 ## 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 ‘" != "" ];

40 then

NUM_AVISO=‘cat $FICHERO_ALERTAS | grep ^$1 | cut -d: -f2 ‘

NUM_AVISO=‘echo $NUM_AVISO +1 | bc ‘


cat $FICHERO_ALERTAS | grep -v $1 > $TMPFILE

45 echo $1:$NUM_AVISO >> $TMPFILE


else

echo "$1:1" >> $FICHERO_ALERTAS

fi

50 }

## cambia la password de un usuario a una password generada automaticamente .

function desactiva_usuario () {

PASSWORD_ALEATORIA =‘pwgen -N 1 -c 12‘

55 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 $PASSWORD_ALEATORIA -w e7ds ,enua

$DN_USER


Desactivacion de cuenta usuario (fuenla) $1" agutierr@gsyc .escet.urjc.es


Desactivacion de cuenta usuario (fuenla) $1" pantuflo -cuentas -

anuladas@pantuflo .escet.urjc.es

Proyecto Fin de Carrera xviii Universidad Rey Juan Carlos


}

60

## busca en el fichero de alertas aquellos usuarios que tengan

## el numero de avisos =3. A estos usuarios , se les cambia la password 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 desactivadas.

65 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

70 case $NUM_INTENTOS in

"1")

cat $EMAIL_AVISO | mail -s "[ laboratorios -linux -fuenla]

Primer aviso , detectada mala password" $USUARIO@bilo .

cct.urjc.es






[email protected]

75 ;;

"2")


Segundo aviso , detectada mala password" $USUARIO@bilo .

cct.urjc.es






[email protected]

80 ;;

"3")

## se desactiva la cuenta del usuario

desactiva_usuario $USUARIO


85 cat $FICHERO_ALERTAS | grep -v $USUARIO > $TMPFILE


;;

esac

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 () {


for i in ‘echo $1 ‘; do

echo $i >> $TMPFILE1

done

echo "Usuarios que han salido ahora :" "$1"


for j in ‘cat $FICHERO_ALERTAS ‘; do

USER=‘echo $j | cut -d: -f1 ‘

echo $USER

if [ "‘cat $TMPFILE1 | grep $USER ‘" != "" ];

105 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

110 echo "Quitando al usuario $j del fichero ..."

fi

done

/bin/mv $TMPFILE2 $FICHERO_ALERTAS

A. Gutierrez Mayoral xix ETSI Informatica


115 }

## vuelca el arbol ldap en un fichero de texto

function vuelca_ldap () {

TMPFILE=‘mktemp -p /var/tmp/john ‘

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

}

125 case $1 in

start )


LDAP_FILE=‘vuelca_ldap ‘


130 $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 -laboratorio.pid


135 LDAP_FILE=‘vuelca_ldap ‘


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

140 for i in ‘echo $USUARIOS_ALERTA ‘; do

alerta_usuario $i

done

# los usuarios del fichero $FICHERO_ALERTAS que no hayan salido (se

presupone que han cambiado su pass)

# son borrados del fichero ...

145 #alerta_inversa $USUARIOS_ALERTA

/bin/rm /var/local/john/john.pot

/bin/rm /var/tmp/john/*

;;

alerta )

150 comprueba_alertas

;;

esac

Proyecto Fin de Carrera xx Universidad Rey Juan Carlos

Apendice CFicheros de configuracion

Por ultimo, incluiremos en este apendice los ficheros de configuracion de aquellos servicios quehemos considerado mas importantes. Para agrupar estos ficheros de configuracion, realizaremosuna clasificacion en primer lugar a nivel de maquina donde se alojan y en segundo lugar, encuanto al servicio que prestan.

xxi

C.1. MAQUINAS ZIPI Y ZAPE

C.1. Maquinas zipi y zape

Las maquinas zipi y zape son servidores secundarios LDAP y a la vez, sirven el mapa deldominio .pantuflo.es, como ya vimos en el capıtulo Implantacion. Como ya vimos, el servidorDNS primario se aloja en la maquina zipi y el secundario en la maquina zape.

C.1.1. Servidor LDAP. Fichero slapd.conf

Listado C.1: Fichero de configuracion /etc/ldap/slapd.conf# This is the main slapd configuration file. See slapd.conf (5) for more

# info on the configuration options.

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

5 # Global Directives:

# Features to permit

#allow bind_v2

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

15 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

25 loglevel 0

# Where the dynamically loaded modules are stored

modulepath /usr/lib/ldap

moduleload back_bdb

30

# The maximum number of entries that is returned for a search operation

sizelimit 500

# The tool -threads parameter sets the actual amount of cpu ’s that is used

35 # for indexing.

tool -threads 1

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

# Specific Backend Directives for bdb:

40 # Backend specific directives apply to this backend until another

# ’backend ’ directive occurs

backend bdb

checkpoint 512 30

45 #######################################################################

# Specific Backend Directives for ’other ’:

# Backend specific directives apply to this backend until another


#backend <other >

50

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

# Specific Directives for database #1, of type bdb:

# Database specific directives apply to this databasse until another

# ’database ’ directive occurs

55 database bdb

# The base of your directory in database #1

Proyecto Fin de Carrera xxii Universidad Rey Juan Carlos

APENDICE C. FICHEROS DE CONFIGURACION

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

60 # rootdn directive for specifying a superuser on the database. 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

65 directory "/var/lib/ldap"

# For the Debian package we use 2MB as default but be sure to update this

# value if you have plenty of RAM

dbconfig set_cachesize 0 2097152 0

70

# Sven Hartge reported that he had to set this value incredibly high

# to get slapd running at all. See http :// bugs.debian.org /303057

# for more information.

75 # Number of objects that can be locked at the same time.

dbconfig set_lk_max_objects 1500

# Number of locks (both requested and granted)

dbconfig set_lk_max_locks 1500

# Number of lockers

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

# 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

95 # These access lines apply to database #1 only

# Ensure read access to the base for things like

# supportedSASLMechanisms . Without this you may

# have problems with SASL not knowing what

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

105 # happily.

#access to dn.base ="" by * read

# The admin dn has full write access , everyone else

# can read everything.

110 #access to *

# by dn="cn=admin ,dc=zipi ,dc=escet ,dc=urjc ,dc=es" write

# by * read

access to dn.base ="" by * read

115

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

by * read


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

125 by dn="cn=admin ,dc=zipi ,dc=escet ,dc=urjc ,dc=es" write

by dn="uid=tgonzale ,ou=usuarios ,ou=profesores ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

write

A. Gutierrez Mayoral xxiii ETSI Informatica


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

130 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

135 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

140 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

145 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

150 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

155

# For Netscape Roaming support , each user gets a roaming

# profile for which they have write access to

#access to dn=".*,ou=Roaming ,o=morsnet"

160 # by dn="cn=admin ,dc=zipi ,dc=escet ,dc=urjc ,dc=es" write

# by dnattr=owner write

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

# Specific Directives for database #2, of type ’other ’ (can be bdb too):

165 # Database specific directives apply to this databasse until another


#database <other >

# The base of your directory for database #2

170 #suffix "dc=debian ,dc=org"

#

TLSCipherSuite HIGH:MEDIUM:-SSLv2

TLSCACertificateFile /etc/ldap/ssl/server.pem

175 TLSCertificateFile /etc/ldap/ssl/server.pem

TLSCertificateKeyFile /etc/ldap/ssl/server.pem

sizelimit -1

180 updatedn "cn=replicator ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

updateref ldaps :// peloto.escet.urjc.es

C.1.2. Servidor DNS. Fichero named.conf y db.pantuflo.es para zipi

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

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

//

Proyecto Fin de Carrera xxiv Universidad Rey Juan Carlos


// Please read /usr/share/doc/bind9/README.Debian.gz for information on the

// structure of BIND configuration files in Debian , *BEFORE* you customize

5 // this configuration file.

//

// If you are just adding zones , please do that in /etc/bind/named.conf.local

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

10

// prime the server with knowledge of the root servers

zone "." {

type hint;

file "/etc/bind/db.root";

15 };

zone "gsyc.info" {

type slave;

masters { 193.147.71.64; };

20 file "/etc/bind9/db.gsyc.info.slave ";

};

zone "dat.escet.urjc.es" {

type slave;

25 masters { 193.147.71.64; };

file "/etc/bind9/db.dat.escet.urjc.es.slave ";

};

zone "gsyc.es" {

30 type slave;

masters { 193.147.71.64; };

file "/etc/bind9/db.gsyc.es.slave ";

};

35 zone "ditte.es" {

type slave;

masters { 193.147.71.64; };

file "/etc/bind9/db.ditte.es.slave ";

};

40

zone "ladyr.es" {

type slave;

masters { 193.147.71.64; };

file "/etc/bind9/db.ladyr.es.slave ";

45 };

50 // be authoritative for the localhost forward and reverse zones , and for

// broadcast zones as per RFC 1912

zone "localhost" {

type master;

55 file "/etc/bind/db.local ";

};

zone "127.in -addr.arpa" {

type master;

60 file "/etc/bind/db .127";

};


type master;

65 file "/etc/bind/db.0";

};


type master;

70 file "/etc/bind/db .255";

};

A. Gutierrez Mayoral xxv ETSI Informatica


zone "pantuflo.es" {

type master;

75 file "/etc/bind9/db.pantuflo.es";

};

// logging {

// category lame -servers { null; };

80 //};

logging {

channel "querylog" { file "/var/log/bind9 -query.log"; print -time yes; };

category queries { querylog; };

85 };

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

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

90 // From the release notes:

// Because many of our users are uncomfortable receiving undelegated 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 applies delegation -only

95 // logic to all top level domains , and to the root domain. An exception 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 "; };

100 include "/etc/bind/named.conf.local ";

Listado C.3: Fichero de configuracion /etc/bind9/db.pantuflo.es

; /var/named/db.gsyc.info

;

; datos de la zona pantuflo.es ( @ = gsyc.info. )

;

5

pantuflo.es. IN SOA ns0.pantuflo.es. agutierr.pantuflo.es. (

2007037912 ; Serial

28800 ; Refresh 8 horas

7200 ; Retry 2 horas

10 604800 ; Expire 1 semana

86400 ) ; Minimum ttl 1 dia

pantuflo.es. IN NS ns0.pantuflo.es.

15 pantuflo.es. IN NS ns1.pantuflo.es.

ns0 IN A 212.128.4.2

ns1 IN A 212.128.4.3

@ IN A 212.128.4.4

20

;

pantuflo.es. IN MX 10 pantuflo.es.

; servidores

25 zipi IN A 212.128.4.2

zape IN A 212.128.4.3

jaimita IN A 212.128.4.5

sapientin IN A 212.128.4.6

peloto IN A 212.128.4.7

30 lechuzo IN A 212.128.4.8

minervo IN A 212.128.4.9

pildorin IN A 212.128.4.10

espatula IN A 212.128.4.12

hydra IN A 193.147.73.53

35 leviatan IN A 212.128.4.120

auditoria.pantuflo.es. IN A 212.128.4.12

Proyecto Fin de Carrera xxvi Universidad Rey Juan Carlos


; aliases

40 www IN CNAME pantuflo.es.

ftp IN CNAME pantuflo.es.

webmail IN CNAME pantuflo.es.

pop3 IN CNAME pantuflo.es.

smtp IN CNAME pantuflo.es.

45 mysql IN CNAME pantuflo.es.

subversion IN CNAME pantuflo.es.

trac IN CNAME pantuflo.es.

; Mirrors de Debian y Ubuntu

50 ubuntu IN CNAME peloto.pantuflo.es.

debian IN CNAME peloto.pantuflo.es.

wiki.pantuflo.es. IN A 212.128.4.4

55 ; Laboratorios docentes

; Estaciones

alpha01 IN A 212.128.4.251

alpha02 IN A 212.128.4.172

60 alpha03 IN A 212.128.4.173

alpha04 IN A 212.128.4.174

alpha05 IN A 212.128.4.175

alpha06 IN A 212.128.4.176

alpha07 IN A 212.128.4.177

65 alpha08 IN A 212.128.4.178

alpha09 IN A 212.128.4.179

alpha10 IN A 212.128.4.180

alpha11 IN A 212.128.4.181

alpha12 IN A 212.128.4.182

70 alpha13 IN A 212.128.4.183

alpha14 IN A 212.128.4.184

alpha15 IN A 212.128.4.185

alpha16 IN A 212.128.4.186

alpha17 IN A 212.128.4.187

75 alpha18 IN A 212.128.4.188

alpha19 IN A 212.128.4.189

alpha20 IN A 212.128.4.190

alpha21 IN A 212.128.4.191

alpha22 IN A 212.128.4.192

80 alpha23 IN A 212.128.4.193

alpha24 IN A 212.128.4.194

alpha25 IN A 212.128.4.195

alpha26 IN A 212.128.4.196

alpha27 IN A 212.128.4.197

85 alpha28 IN A 212.128.4.198

alpha29 IN A 212.128.4.199

alpha30 IN A 212.128.4.200

alpha31 IN A 212.128.4.201

alpha32 IN A 212.128.4.202

90 alpha33 IN A 212.128.4.203

alpha34 IN A 212.128.4.204

alpha35 IN A 212.128.4.115

alpha36 IN A 212.128.4.116

alpha37 IN A 212.128.4.117

95 alpha38 IN A 212.128.4.118

alpha39 IN A 212.128.4.119

alpha40 IN A 212.128.4.210

beta01 IN A 212.128.4.131

beta02 IN A 212.128.4.132

100 beta03 IN A 212.128.4.133

beta04 IN A 212.128.4.134

beta05 IN A 212.128.4.135

beta06 IN A 212.128.4.136

beta07 IN A 212.128.4.137

105 beta08 IN A 212.128.4.138

beta09 IN A 212.128.4.139

beta10 IN A 212.128.4.140

beta11 IN A 212.128.4.141

A. Gutierrez Mayoral xxvii ETSI Informatica


beta12 IN A 212.128.4.142

110 beta13 IN A 212.128.4.143

beta14 IN A 212.128.4.144

beta15 IN A 212.128.4.145

beta16 IN A 212.128.4.146

beta17 IN A 212.128.4.147

115 beta18 IN A 212.128.4.148

beta19 IN A 212.128.4.149

beta20 IN A 212.128.4.150

beta21 IN A 212.128.4.151

beta22 IN A 212.128.4.152

120 beta23 IN A 212.128.4.153

beta24 IN A 212.128.4.154

beta25 IN A 212.128.4.155

beta26 IN A 212.128.4.156

beta27 IN A 212.128.4.157

125 beta28 IN A 212.128.4.158

beta29 IN A 212.128.4.159

beta30 IN A 212.128.4.160

beta31 IN A 212.128.4.161

beta32 IN A 212.128.4.162

130 beta33 IN A 212.128.4.163

beta34 IN A 212.128.4.164

beta35 IN A 212.128.4.165

beta36 IN A 212.128.4.166

beta37 IN A 212.128.4.167

135 beta38 IN A 212.128.4.168

beta39 IN A 212.128.4.169

beta40 IN A 212.128.4.170

gamma01 IN A 212.128.4.211

gamma02 IN A 212.128.4.212

140 gamma03 IN A 212.128.4.213

gamma04 IN A 212.128.4.214

gamma05 IN A 212.128.4.215

gamma06 IN A 212.128.4.216

gamma07 IN A 212.128.4.217

145 gamma08 IN A 212.128.4.218

gamma09 IN A 212.128.4.219

gamma10 IN A 212.128.4.220

gamma11 IN A 212.128.4.221

gamma12 IN A 212.128.4.222

150 gamma13 IN A 212.128.4.223

gamma14 IN A 212.128.4.224

gamma15 IN A 212.128.4.225

gamma16 IN A 212.128.4.226

gamma17 IN A 212.128.4.227

155 gamma18 IN A 212.128.4.228

gamma19 IN A 212.128.4.229

gamma20 IN A 212.128.4.230

gamma21 IN A 212.128.4.231

gamma22 IN A 212.128.4.232

160 gamma23 IN A 212.128.4.233

gamma24 IN A 212.128.4.234

gamma25 IN A 212.128.4.235

gamma26 IN A 212.128.4.236

gamma27 IN A 212.128.4.237

165 gamma28 IN A 212.128.4.238

gamma29 IN A 212.128.4.239

gamma30 IN A 212.128.4.240

gamma31 IN A 212.128.4.241

gamma32 IN A 212.128.4.242

170 gamma33 IN A 212.128.4.243

gamma34 IN A 212.128.4.244

gamma35 IN A 212.128.4.245

gamma36 IN A 212.128.4.246

gamma37 IN A 212.128.4.247

175 gamma38 IN A 212.128.4.248

gamma39 IN A 212.128.4.249

gamma40 IN A 212.128.4.250

delta01 IN A 212.128.4.61

Proyecto Fin de Carrera xxviii Universidad Rey Juan Carlos


delta02 IN A 212.128.4.62

180 delta03 IN A 212.128.4.63

delta04 IN A 212.128.4.64

delta05 IN A 212.128.4.65

delta06 IN A 212.128.4.66

delta07 IN A 212.128.4.67

185 delta08 IN A 212.128.4.68

delta09 IN A 212.128.4.69

delta10 IN A 212.128.4.70

delta11 IN A 212.128.4.71

delta12 IN A 212.128.4.72

190 delta13 IN A 212.128.4.73

delta14 IN A 212.128.4.74

delta15 IN A 212.128.4.75

delta16 IN A 212.128.4.76

delta17 IN A 212.128.4.77

195 delta18 IN A 212.128.4.78

delta19 IN A 212.128.4.79

delta20 IN A 212.128.4.80

delta21 IN A 212.128.4.81

delta22 IN A 212.128.4.82

200 delta23 IN A 212.128.4.83

delta24 IN A 212.128.4.84

delta25 IN A 212.128.4.85

delta26 IN A 212.128.4.86

delta27 IN A 212.128.4.87

205 delta28 IN A 212.128.4.88

delta29 IN A 212.128.4.89

delta30 IN A 212.128.4.90

delta31 IN A 212.128.4.49

delta32 IN A 212.128.4.50

210 delta33 IN A 212.128.4.51

delta34 IN A 212.128.4.52

delta35 IN A 212.128.4.53

delta36 IN A 212.128.4.54

delta37 IN A 212.128.4.55

215 delta38 IN A 212.128.4.56

delta39 IN A 212.128.4.57

delta40 IN A 212.128.4.58

epsilon01 IN A 193.147.73.56

epsilon02 IN A 193.147.73.57

220 epsilon03 IN A 193.147.73.58

epsilon04 IN A 193.147.73.59

epsilon05 IN A 193.147.73.60

epsilon06 IN A 193.147.73.61

epsilon07 IN A 193.147.73.62

225 epsilon08 IN A 193.147.73.63

epsilon09 IN A 193.147.73.64

epsilon10 IN A 193.147.73.65

epsilon11 IN A 193.147.73.66

epsilon12 IN A 193.147.73.67

230 epsilon13 IN A 193.147.73.68

epsilon14 IN A 193.147.73.69

epsilon15 IN A 193.147.73.70

epsilon16 IN A 193.147.73.71

epsilon17 IN A 193.147.73.72

235 epsilon18 IN A 193.147.73.73

epsilon19 IN A 193.147.73.74

epsilon20 IN A 193.147.73.75

epsilon21 IN A 193.147.73.76

epsilon22 IN A 193.147.73.77

240 epsilon23 IN A 193.147.73.78

epsilon24 IN A 193.147.73.79

epsilon25 IN A 193.147.73.80

epsilon26 IN A 193.147.73.81

epsilon27 IN A 193.147.73.82

245 epsilon28 IN A 193.147.73.83

epsilon29 IN A 193.147.73.84

epsilon30 IN A 193.147.73.85

epsilon31 IN A 193.147.73.86

A. Gutierrez Mayoral xxix ETSI Informatica


epsilon32 IN A 193.147.73.87

250 epsilon33 IN A 193.147.73.88

epsilon34 IN A 193.147.73.89

epsilon35 IN A 193.147.73.90

epsilon36 IN A 193.147.73.91

epsilon37 IN A 193.147.73.92

255 epsilon38 IN A 193.147.73.93

epsilon39 IN A 193.147.73.94

epsilon40 IN A 193.147.73.95

epsilon41 IN A 193.147.73.96

zeta01 IN A 193.147.73.97

260 zeta02 IN A 193.147.73.98

zeta03 IN A 193.147.73.99

zeta04 IN A 193.147.73.100

zeta05 IN A 193.147.73.101

zeta06 IN A 193.147.73.102

265 zeta07 IN A 193.147.73.103

zeta08 IN A 193.147.73.104

zeta09 IN A 193.147.73.105

zeta10 IN A 193.147.73.106

zeta11 IN A 193.147.73.107

270 zeta12 IN A 193.147.73.108

zeta13 IN A 193.147.73.109

zeta14 IN A 193.147.73.110

zeta15 IN A 193.147.73.111

zeta16 IN A 193.147.73.112

275 zeta17 IN A 193.147.73.113

zeta18 IN A 193.147.73.114

zeta19 IN A 193.147.73.115

zeta20 IN A 193.147.73.116

zeta21 IN A 193.147.73.117

280 zeta22 IN A 193.147.73.118

zeta23 IN A 193.147.73.119

zeta24 IN A 193.147.73.120

zeta25 IN A 193.147.73.121

zeta26 IN A 193.147.73.122

285 zeta27 IN A 193.147.73.123

zeta28 IN A 193.147.73.124

zeta29 IN A 193.147.73.125

zeta30 IN A 193.147.73.126

zeta31 IN A 193.147.73.127

290 zeta32 IN A 193.147.73.128

zeta33 IN A 193.147.73.129

zeta34 IN A 193.147.73.130

zeta35 IN A 193.147.73.131

zeta36 IN A 193.147.73.132

295 zeta37 IN A 193.147.73.133

zeta38 IN A 193.147.73.134

zeta39 IN A 193.147.73.135

zeta40 IN A 193.147.73.136

zeta41 IN A 193.147.73.137

300

; seminario 5 de fuenla (laboratorio SSOO)

theta01 IN A 193.147.57.71

305 theta02 IN A 193.147.57.72

theta03 IN A 193.147.57.73

theta04 IN A 193.147.57.74

theta05 IN A 193.147.57.75

theta06 IN A 193.147.57.76

310 theta07 IN A 193.147.57.77

theta08 IN A 193.147.57.78

theta09 IN A 193.147.57.79

theta10 IN A 193.147.57.80

theta11 IN A 193.147.57.81

315 theta12 IN A 193.147.57.82

theta13 IN A 193.147.57.83

theta14 IN A 193.147.57.84

theta15 IN A 193.147.57.85

Proyecto Fin de Carrera xxx Universidad Rey Juan Carlos


theta16 IN A 193.147.57.86

320 theta17 IN A 193.147.57.87

theta18 IN A 193.147.57.88

theta19 IN A 193.147.57.89

theta20 IN A 193.147.57.90

C.1.3. Servidor DNS. Fichero named.conf para zape

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

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

//

// Please read /usr/share/doc/bind9/README.Debian.gz for information on the

// structure of BIND configuration files in Debian , *BEFORE* you customize

5 // this configuration file.

//

// If you are just adding zones , please do that in /etc/bind/named.conf.local

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

10

// prime the server with knowledge of the root servers

zone "." {

type hint;

file "/etc/bind/db.root";

15 };

// be authoritative for the localhost forward and reverse zones , and for

// broadcast zones as per RFC 1912

20 zone "localhost" {

type master;

file "/etc/bind/db.local ";

};

25 zone "127.in -addr.arpa" {

type master;

file "/etc/bind/db .127";

};


type master;

file "/etc/bind/db.0";

};


type master;

file "/etc/bind/db .255";

};

40 zone "pantuflo.es" {

type slave;

file "/etc/bind9/db.pantuflo.es";

masters { 212.128.4.2; };

};

45

logging {

category lame -servers { null; };

};

50

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

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

// From the release notes:

55 // Because many of our users are uncomfortable receiving undelegated answers

// from root or top level domains , other than a few for whom that behaviour

// has been trusted and expected for quite some length of time , we have now

A. Gutierrez Mayoral xxxi ETSI Informatica

C.2. MAQUINA PANTUFLO

// introduced the "root -delegations -only" feature which applies delegation -only

// logic to all top level domains , and to the root domain. An exception list

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

C.2. Maquina pantuflo

Los servicios mas importantes que se sirven en la maquina pantuflo son la pagina web delLaboratorio, las paginas web de los alumnos, el correo de las cuentas @pantuflo.escet.urjc.esy el servicio MySQL (que no ha sido estudiado en este documento).

C.2.1. Fichero de configuracion de Apache

Los ficheros de configuracion de sitios para Apache en la version 2, se encuentran situadosbajo el directorio /etc/apache2/sites-enabled.

Listado C.5: Fichero de configuracion /etc/apache2/sites-enabled/pantuflo.es

<VirtualHost 212.128.4.4:80 >

ServerAdmin agutierr@gsyc .escet.urjc.es

ServerName pantuflo.es

ReWriteEngine On

5 RewriteRule ^/(.*) http :// pantuflo.escet.urjc.es/$1 [L,R]

</VirtualHost >

<VirtualHost 212.128.4.4:443 >


10 ServerName pantuflo.es

RewriteRule ^/(.*) https :// pantuflo.escet.urjc.es/$1 [L,R]

</VirtualHost >

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

<VirtualHost 212.128.4.4:80 >


ServerName pantuflo.escet.urjc.es


5 <Directory />

Options FollowSymLinks

AllowOverride None

</Directory >

<Directory /var/www/wikipantuflo/>

10 Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow ,deny

allow from all

# This directive allows us to have apache2 ’s default start page

15 # in /apache2 -default/, but still have / go to the right place

</Directory >

ScriptAlias /cgi -bin/ /usr/lib/cgi -bin/

20 <Directory "/usr/lib/cgi -bin">

AllowOverride None

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow ,deny

Allow from all

25 </Directory >

Proyecto Fin de Carrera xxxii Universidad Rey Juan Carlos


CustomLog /var/log/apache2/pantuflo.escet.urjc.es/access.log combined

ErrorLog /var/log/apache2/pantuflo.escet.urjc.es/error.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 >


ServerName pantuflo.escet.urjc.es

SSLEngine On

SSLCertificateFile /etc/apache2/ssl/certificado -pantuflo.escet.urjc.es.pem


50 <Directory />


AllowOverride None

</Directory >

<Directory /var/www/wikipantuflo/>

55 Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow ,deny

allow from all

# This directive allows us to have apache2 ’s default start page

60 # in /apache2 -default/, but still have / go to the right place

</Directory >

ScriptAlias /cgi -bin/ /usr/lib/cgi -bin/

65 <Directory "/usr/lib/cgi -bin">

AllowOverride None


Order allow ,deny

Allow from all

70 </Directory >

ErrorLog /var/log/apache2/error.log

# Possible values include: debug , info , notice , warn , error , crit ,

75 # alert , emerg.

LogLevel warn

CustomLog /var/log/apache2/access.log combined

ServerSignature On

80

Alias /webmail /var/www/webmail/

Alias /admin /var/www/admin/

Alias /nagios/cgi -bin /usr/lib/cgi -bin/nagios/

Alias /nagios/stylesheets /etc/nagios/stylesheets

85 Alias /nagios /usr/share/nagios/htdocs

<Directory /var/www/admin >

AllowOverride None


90 Order allow ,deny

Allow from all

</Directory >

<Directory /usr/lib/cgi -bin/nagios >

95 Options ExecCGI

A. Gutierrez Mayoral xxxiii ETSI Informatica


AllowOverride AuthConfig

Order Allow ,Deny

Allow From All

100

AuthName "Servidor Nagios de Pantuflo"

AuthType Basic

AuthUserFile /etc/nagios/htpasswd.users

require valid -user

105 </Directory >

<Directory /usr/share/nagios/htdocs >


110 AllowOverride AuthConfig

Order Allow ,Deny

Allow From All

AuthName "Servidor Nagios de Pantuflo"

115 AuthType Basic

AuthUserFile /etc/nagios/htpasswd.users

require valid -user

</Directory >

120

</VirtualHost >

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

<VirtualHost 212.128.4.4:80 >


ServerName webmail.pantuflo.es

ReWriteEngine On

5 RewriteRule ^/(.*) https :// webmail.pantuflo.es/$1 [L,R]

</VirtualHost >

<VirtualHost 212.128.4.4:443 >


10 ServerName webmail.pantuflo.es

SSLEngine On

SSLCertificateFile /etc/apache2/ssl/certificado -webmail.pantuflo.es.pem

DocumentRoot /var/www/webmail/

</VirtualHost >

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

<VirtualHost 212.128.4.4:80 >

ServerName mysql.pantuflo.es


RewriteEngine on

5 RewriteRule ^/(.*) https :// mysql.pantuflo.es/$1 [L,R]

</VirtualHost >

<VirtualHost 212.128.4.4:443 >

ServerName mysql.pantuflo.es


DocumentRoot /usr/share/phpmyadmin/

SSLEngine On

SSLCertificateFile /etc/apache2/ssl/certificado -mysql.pantuflo.es.pem

<Directory /usr/share/phpmyadmin/>

15 AllowOverride All

</Directory >

<Directory /var/www/phpmyadmin/>

AllowOverride All

20 </Directory >

<Directory /var/lib/phpmyadmin/>

Proyecto Fin de Carrera xxxiv Universidad Rey Juan Carlos


Options -FollowSymLinks

AllowOverride None

25 Order deny ,allow

Deny from all

</Directory >

<Directory /usr/share/phpmyadmin/config/>

30 Options -FollowSymLinks

AllowOverride None

Order deny ,allow

Deny from all

</Directory >

35

<Directory /var/www/phpmyadmin/config/>

Options -FollowSymLinks

AllowOverride None

Order deny ,allow

40 Deny from all

</Directory >

ErrorLog /var/log/apache2/mysql.pantuflo.es/error.log

LogLevel warn

45 CustomLog /var/log/apache2/mysql.pantuflo.es/access.log combined

</VirtualHost >

C.2.2. Fichero de configuracion de Postfix

Los ficheros de configuracion mas importantes de Postfix se encuentran situados en los ficheros/etc/postfix/main.cf y /etc/postfix/master.cf.

Listado C.9: Fichero de configuracion /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented , more complete version

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

biff = no

5

# appending .domain is the MUA ’s job.

append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings

10 #delay_warning_time = 4h

myhostname = pantuflo

alias_maps = hash:/etc/aliases

alias_database = hash:/etc/aliases

15 myorigin = /etc/mailname

mydestination = pantuflo.escet.urjc.es , pantuflo , localhost.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

20 mailbox_size_limit = 0

recipient_delimiter = +

inet_interfaces = all

#smtpd_sasl_auth_enable = yes

25 #broken_sasl_auth_clients = yes

#smtpd_sasl_application_name = smtpd

#smtpd_recipient_restrictions = permit_sasl_authenticated ,permit_mynetworks ,

reject_unauth_destination

#smtpd_sasl_security_options = noanonymous

#smtpd_sasl_local_domain = $myhostname

30

#smtpd_sasl_auth_enable = yes

A. Gutierrez Mayoral xxxv ETSI Informatica


#smtpd_sasl_authenticated_header = yes

#smtpd_sasl_application_name = smtpd

35 #smtpd_sasl_path = private/auth

smtpd_recipient_restrictions =

permit_mynetworks ,

check_client_access hash:/var/lib/pop -before -smtp/hosts ,

40 reject_unauth_destination ,

check_relay_domains

Listado C.10: Fichero de configuracion /etc/postfix/master.cf

#

# Postfix master process configuration file. Each logical line

# describes how a Postfix daemon program should be run.

#

5 # A logical line starts with non -whitespace , non -comment text.

# Empty lines and whitespace -only lines are ignored , as are comment

# lines whose first non -whitespace character is a ‘#’.

# A line that starts with whitespace continues a logical line.

#

10 # The fields that make up each line are described below. A "-" field

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

15 # host:port. The host part (and colon) may be omitted. Either host

# or port may be given in symbolic form or in numeric form. Examples

# for the SMTP server: localhost:smtp receives mail via the loopback

# interface only; 10025 receives mail on port 10025.

#

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

# Default is private service. Internet (inet) sockets can ’t be private.

25 #

# Unprivileged: whether the service runs with root privileges or as

# the owner of the Postfix system (the owner name is controlled by the

# mail_owner configuration variable in the main.cf file). Only the

# pipe , virtual and local delivery daemons require privileges.

30 #

# 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 daemons can run

# chrooted , except for the pipe , virtual and local delivery daemons.

35 # 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 describe how

# to set up a Postfix chroot environment for your type of machine.

#

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

45 #

# Max procs: the maximum number of processes that may execute this

# service simultaneously. Default is to use a globally configurable

# limit (the default_process_limit configuration parameter in main.cf).

# Specify 0 for no process count limit.

50 #

# Command + args: the command to be executed. The command name is

# relative to the Postfix program directory (pathname is controlled by

# the daemon_directory configuration variable). Adding one or more

# -v options turns on verbose logging for that service; adding a -D

55 # option enables symbolic debugging (see the debugger_command variable

# in the main.cf configuration file). See individual command man pages

# for specific command -line options , if any.

Proyecto Fin de Carrera xxxvi Universidad Rey Juan Carlos


#

# General main.cf options can be overridden for specific services.

60 # To override one or more main.cf options , specify them as arguments

# below , preceding each option by "-o". There must be no whitespace

# in the option itself (separate multiple values for an option by

# commas).

#

65 # In order to use the "uucp" message tranport below , set up entries

# in the transport table.

#

# In order to use the "cyrus" message transport below , configure it

# in main.cf as the mailbox_transport .

70 #

# SPECIFY ONLY PROGRAMS THAT ARE WRITTEN TO RUN AS POSTFIX DAEMONS.

# ALL DAEMONS SPECIFIED HERE MUST SPEAK A POSTFIX -INTERNAL PROTOCOL.

#

# DO NOT SHARE THE POSTFIX QUEUE BETWEEN MULTIPLE POSTFIX INSTANCES.

75 #

# ==========================================================================

# service type private unpriv chroot wakeup maxproc command + args

# (yes) (yes) (yes) (never) (100)

# ==========================================================================

80 smtp inet n - n - - smtpd

#submission inet n - - - - smtpd

# -o smtpd_etrn_restrictions =reject

#628 inet n - - - - qmqpd

pickup fifo n - - 60 1 pickup

85 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

90 defer unix - - - - 0 bounce

trace unix - - - - 0 bounce

verify unix - - - - 1 verify

flush unix n - - 1000? 0 flush

proxymap unix - - n - - proxymap

95 smtp unix - - - - - smtp

relay unix - - - - - smtp

# -o smtp_helo_timeout =5 -o smtp_connect_timeout =5

showq unix n - - - - showq

error unix - - - - - error

100 local unix - n n - - local

virtual unix - n n - - virtual

lmtp unix - - n - - lmtp

anvil unix - - n - 1 anvil

#

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

#

110 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

115 flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)

bsmtp unix - n n - - pipe

flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient

scalemail -backend unix - n n - 2 pipe

flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail -store ${nexthop} ${user} ${

extension}

120

# only used by postfix -tls

#tlsmgr fifo - - n 300 1 tlsmgr

#smtps inet n - n - - smtpd -o smtpd_tls_wrappermode =yes

-o smtpd_sasl_auth_enable =yes

#587 inet n - n - - smtpd -o smtpd_enforce_tls

=yes -o smtpd_sasl_auth_enable =yes

A. Gutierrez Mayoral xxxvii ETSI Informatica


125 tlsmgr unix - - - 1000? 1 tlsmgr

scache unix - - - - 1 scache

discard unix - - - - - discard

C.2.3. Fichero de configuracion de Dovecot

El fichero de configuracion del servidor de recogida de correo Dovecot se encuentra en/etc/dovecot/dovecot.conf.

Listado C.11: Fichero de configuracion /etc/dovecot/dovecot.conf

## Dovecot configuration file

# If you ’re in a hurry , see http :// wiki.dovecot.org/QuickConfiguration

5 # ’#’ character and everything after it is treated as comments. Extra spaces

# and tabs are ignored. If you want to use either of these explicitly , put the

# value inside quotes , eg.: key = "# char and trailing whitespace "

# Default values are shown after each value , it ’s not required to uncomment

10 # any of the lines. Exception to this are paths , they ’re just examples

# with real defaults being based on configure options. The paths listed here

# are for configure --prefix =/usr --sysconfdir =/etc --localstatedir =/var

# --with -ssldir =/etc/ssl

15 # Base directory where to store runtime data.

#base_dir = /var/run/dovecot/

# Protocols we want to be serving:

# imap imaps pop3 pop3s

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

25 # "[::]" 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

30 # specify different ports for IMAP/POP3. For example:

# protocol imap {

# listen = *:10143

# ssl_listen = *:10943

# ..

35 # }

# protocol pop3 {

# listen = *:10100

# ..

# }

40 #listen = *

# IP or host address where to listen in for SSL connections. Defaults

# to above if not specified.

#ssl_listen =

45

# Disable SSL/TLS support.

#ssl_disable = no

# PEM encoded X.509 SSL/TLS certificate and private key. They ’re opened before

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

55 # If key file is password protected , give the password here. Alternatively

# give it when starting dovecot with -p parameter.

Proyecto Fin de Carrera xxxviii Universidad Rey Juan Carlos


#ssl_key_password =

# File containing trusted SSL certificate authorities. Usually not needed.

60 #ssl_ca_file =

# Request client to send a certificate.

#ssl_verify_client_cert = no

65 # How often to regenerate the SSL parameters file. Generation is quite CPU

# intensive operation. The value is in hours , 0 disables regeneration

# entirely.

#ssl_parameters_regenerate = 168

70 # SSL ciphers to use

#ssl_cipher_list = ALL:!LOW

# Disable LOGIN command and all other plaintext authentications unless

# SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and

75 # IPv6 ::1 addresses are considered secure , this setting has no effect if

# you connect from those addresses.

#disable_plaintext_auth = yes

# Should all IMAP and POP3 processes be killed when Dovecot master process

80 # shuts down. Setting this to "no" means that Dovecot can be upgraded 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 processes can ’t write

# to log files anymore.

85 #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 closed).

#log_path =

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 strftime (3)

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

100 # facilities are supported.

#syslog_facility = mail

##

## Login processes

105 ##

# Directory where authentication process places authentication UNIX sockets

# which login needs to be able to connect to. The sockets are created when

# running as root , so you don ’t have to worry about permissions. Note that

110 # everything in this directory is deleted when Dovecot is started.

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

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

120 # only it has access , it ’s used to control access for authentication process.

# Note that this user is NOT used to access mails.

# http :// wiki.dovecot.org/UserIds

#login_user = dovecot

125 # Set max. process size in megabytes. If you don ’t use

# login_process_per_connection you might need to grow this.

A. Gutierrez Mayoral xxxix ETSI Informatica


#login_process_size = 32

# Should each login be processed in it ’s own process (yes), or should one

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

#login_process_per_connection = yes

135 # Number of login processes to create. If login_process_per_connection 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 extra process count

140 # usually stays at login_processes_count , but when multiple users start logging

# in at the same time more extra processes are created. To prevent fork -bombing

# we check only once in a second if new processes should be created - if all

# of them are used at the time , we double their amount until limit set by this

# setting is reached. This setting is used only if login_process_per_use is yes.

145 #login_max_processes_count = 128

# Maximum number of connections allowed in login state. When this limit is

# reached , the oldest connections are dropped. If login_process_per_connection

# is no , this is a per -process value , so the absolute maximum number of users

150 # logging in actually login_processes_count * max_logging_users .

#login_max_logging_users = 256

# Greeting message for clients.

#login_greeting = Dovecot ready.

155

# Space -separated list of elements we want to log. The elements which have

# a non -empty variable value are joined together to form a comma -separated

# string.

#login_log_format_elements = user=< %u> method= %m rip= %r lip= %l %c

160

# Login log format. %$ contains login_log_format_elements 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 ,

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

175 # (eg. shared mailboxes or if same uid is used for multiple accounts).

#verbose_proctitle = no

# Show protocol level SSL errors.

#verbose_ssl = no

180

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

# Note that denying root logins is hardcoded to dovecot binary and can ’t

# be done even if first_valid_uid is set to 0.

185 #first_valid_uid = 500

#last_valid_uid = 0

# Valid GID range for users , defaults to non -root/wheel. Users having

# non -valid GID as primary group ID aren ’t allowed to log in. If user

190 # belongs to supplementary groups with non -valid GIDs , those groups are

# not set.

#first_valid_gid = 1

#last_valid_gid = 0

195 # Grant access to these extra groups for mail processes. Typical use would be

# to give "mail" group write access to /var/mail to be able to create dotlocks.

Proyecto Fin de Carrera xl Universidad Rey Juan Carlos


#mail_extra_groups = mail

# ’:’ separated list of directories under which chrooting is allowed for mail

200 # processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too).

# This setting doesn ’t affect login_chroot or auth_chroot variables.

# 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

205 # /usr/share/doc/dovecot -common/configuration .txt for more information.

#valid_chroot_dirs =

# Default chroot directory for mail processes. This can be overridden for

# specific users in user database by giving /./ in user ’s home directory

210 # (eg. /home /./ user chroots into /home). Note that usually there is no real

# need to do chrooting , Dovecot doesn ’t allow users to access files outside

# their mail directory anyway.

#mail_chroot =

215 # 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 leaving this empty

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

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

230 #

# 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

#

235 default_mail_env = maildir :/var/mail/ %u/

# If you need to set multiple mailbox locations or want to change default

# namespace settings , you can do it by defining namespace sections:

#

240 # You can have private , shared and public namespaces. The only difference

# between them is how Dovecot announces them to client via NAMESPACE

# extension. Shared namespaces are meant for user -owned mailboxes which are

# shared to other users , while public namespaces are for more globally

# accessible mailboxes.

245 #

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

250 #namespace private {

# Hierarchy separator to use. You should use the same separator for all

# namespaces or some clients get confused. ’/’ is usually a good one.

#separator = /

255 # Prefix required to access this namespace. This needs to be different for

# all namespaces. For example "Public /".

#prefix =

# Physical location of the mailbox. This is in same format as

260 # default_mail_env , which is also the default for it.

#location =

# There can be only one INBOX , and this setting defines which namespace

# has it.

265 #inbox = yes

A. Gutierrez Mayoral xli ETSI Informatica


# If namespace is hidden , it ’s not advertised to clients via NAMESPACE

# extension or shown in LIST replies. This is mostly useful when converting

# from another server with different namespaces which you want to depricate

270 # but still keep working. For example you can create hidden namespaces with

# prefixes "~/ mail/", "~ %u/mail/" and "mail /".

#hidden = yes

#}

275 # Space -separated list of fields to initially save into cache file. Currently

# these fields are allowed:

#

# flags , date.sent , date.received , size.virtual , size.physical

# mime.parts , imap.body , imap.bodystructure

280 #

# Different IMAP clients work in different ways , so they benefit 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.

285 #

# Dovecot attempts to automatically figure out what client wants and it keeps

# only that. However the first few times a mailbox is opened , Dovecot hasn ’t

# yet figured out what client needs , so it may not perform optimally. If you

# know what fields the majority of your clients need , it may be useful to set

290 # these fields by hand. If client doesn ’t actually use them , Dovecot will

# eventually drop them.

#

# Usually you should just leave this field alone. The potential benefits are

# typically unnoticeable.

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

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

305 #mail_cache_min_mail_count = 0

# When IDLE command is running , mailbox is checked once in a while to see if

# there are any new mails or other changes. This setting defines the minimum

# time to wait between those checks. Dovecot is however able to use dnotify

310 # and inotify with Linux to reply immediately after the change occurs.

#mailbox_idle_check_interval = 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 works with both

315 # maildir and mboxes , allowing you to prefix mailboxes names with eg. /path/

# or ~user/.

#mail_full_filesystem_access = no

# Maximum allowed length for mail keyword name. It ’s only forced when trying

320 # to create new keywords.

#mail_max_keyword_length = 50

# Save mails with CR+LF instead of plain LF. This makes sending those mails

# take less CPU , especially with sendfile () syscall with Linux and FreeBSD.

325 # But it also creates a bit more disk I/O which may just make it slower.

# Also note that if other software reads the mboxes/maildirs , they may handle

# the extra CRs wrong and cause problems.

#mail_save_crlf = no

330 # Use mmap() instead of read() to read mail files. read() seems 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_read_mmaped = yes.

#mail_read_mmaped = no

335 # Don ’t use mmap() at all. This is required if you store indexes to shared

# filesystems (NFS or clustered filesystem).

Proyecto Fin de Carrera xlii Universidad Rey Juan Carlos


#mmap_disable = no

# Don ’t write () to mmaped files. This is required for some operating systems

340 # which use separate caches for them , such as OpenBSD.

#mmap_no_write = no

# Locking method for index files. Alternatives are fcntl , flock and dotlock.

# Dotlocking uses some tricks which may create more disk I/O than other locking

345 # 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 beginning with dot.

# Enabling this option makes Dovecot return only entries which are directories.

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

355 # Copy mail to another folders using hard links. This is much faster than

# actually copying the file. This is problematic only if something modifies

# the mail in one folder but doesn ’t want it modified in the others. I don ’t

# know any MUA which would modify mail files directly. IMAP protocol also

# requires that the mails don ’t change , so it would be problematic in any case.

360 # If you care about performance , enable it.

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

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

370 #

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

# locking methods as well. Some operating systems don ’t allow using some of

# them simultaneously.

375 #mbox_read_locks = fcntl

#mbox_write_locks = dotlock fcntl

# Maximum time in seconds to wait for lock (all of them) before aborting.

#mbox_lock_timeout = 300

380

# If dotlock exists but the mailbox isn ’t modified in any way , override the

# lock file after this many seconds.

#mbox_dotlock_change_timeout = 120

385 # 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 simply read the

# new mails. If this setting is enabled , Dovecot does this but still safely

# fallbacks to re -reading the whole mbox file whenever something in mbox isn ’t

390 # how it ’s expected to be. The only real downside to this setting is that if

# some other MUA changes message flags , Dovecot doesn ’t notice it immediately.

# Note that a full sync is done with SELECT , EXAMINE , EXPUNGE and CHECK

# commands.

#mbox_dirty_syncs = yes

395

# Like mbox_dirty_syncs , but don ’t do full syncs even with SELECT , EXAMINE ,

# EXPUNGE or CHECK commands. If this is set , mbox_dirty_syncs is ignored.

#mbox_very_dirty_syncs = no

400 # Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK

# commands and when closing the mailbox). This is especially useful for POP3

# where clients often delete all mails. The downside is that our changes

# aren ’t immediately visible to other MUAs.

#mbox_lazy_writes = yes

405

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

A. Gutierrez Mayoral xliii ETSI Informatica


# If an index file already exists it ’s still read , just not updated.

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

415 #dbox_rotate_min_size = 16

# Maximum dbox file age in days until it ’s rotated. Day always begins from

# midnight , so 1 = today , 2 = yesterday , etc. 0 = check disabled .

#dbox_rotate_days = 0

420

# umask to use for mail files and directories

#umask = 0077

# Drop all privileges before exec()ing the mail process. This is mostly

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

#mail_drop_priv_before_exec = no

430 # 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 pretty high.

#mail_process_size = 256

# Log prefix for mail processes. See

435 # /usr/share/doc/dovecot -common/variables.txt for list of possible variables

#you can use.

#mail_log_prefix = " %Us( %u): "

##

440 ## IMAP specific settings

##

protocol imap {

# Login executable location.

445 #login_executable = /usr/lib/dovecot/imap -login

# IMAP executable location. Changing this allows you to execute other

# binaries before the imap process is executed.

#

450 # This would write rawlogs into ~/ dovecot.rawlog/ directory:

# mail_executable = /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap

#

# This would attach gdb into the imap process and write backtraces into

# /tmp/gdbhelper .* files:

455 # 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 generate very long

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

#imap_max_line_length = 65536

# Support for dynamically loadable plugins. mail_plugins is a space separated

465 # list of plugins to load.

#mail_plugins =

#mail_plugin_dir = /usr/lib/dovecot/modules/imap

# Send IMAP capabilities in greeting message. This makes it unnecessary for

470 # clients to request it with CAPABILITY command , so it saves one round -trip.

# Many clients however don ’t understand it and ask the CAPABILITY anyway.

#login_greeting_capability = no

# Workarounds for various client bugs:

475 # delay -newmail:

# Send EXISTS/RECENT new mail notifications only when replying to NOOP

Proyecto Fin de Carrera xliv Universidad Rey Juan Carlos


# and CHECK commands. Some clients ignore them otherwise , for example

# OSX Mail. Outlook Express breaks more badly though , without this it

# may show user "Message no longer in server" errors. Note that OE6 still

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

485 # 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 empty "end of

# headers" line. Normally all messages have this , but setting this

490 # workaround makes sure that Netscape never breaks by adding the line if

# it doesn ’t exist. This is done only for FETCH BODY[HEADER.FIELDS ..]

# commands. Note that RFC says this shouldn ’t be done.

# tb -extra -mailbox -sep:

# With mbox storage a mailbox can contain either mails or submailboxes ,

495 # but not both. Thunderbird separates these two by forcing server to

# accept ’/’ suffix in mailbox names in subscriptions list.

# The list is space -separated.

#imap_client_workarounds = outlook -idle

}

500

##

## POP3 specific settings

##

505 protocol pop3 {

# Login executable location.

#login_executable = /usr/lib/dovecot/pop3 -login

# POP3 executable location

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

515 #pop3_no_flag_updates = 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. Enabling this

# makes RSET command clear all \Seen flags from messages.

520 #pop3_enable_last = no

# If mail has X-UIDL header , use it as the mail ’s UIDL.

#pop3_reuse_xuidl = no

525 # Keep the mailbox locked for the entire POP3 session.

#pop3_lock_session = no

# POP3 UIDL format to use. You can use following variables:

#

530 # %v - Mailbox UIDVALIDITY

# %u - Mail UID

# %m - MD5 sum of the mailbox headers in hex (mbox only)

# %f - filename (maildir only)

#

535 # If you want UIDL compatibility with other POP3 servers , use:

# UW ’s ipop3d : %08Xv %08Xu

# Courier version 0 : %f

# Courier version 1 : %u

# Courier version 2 : %v- %u

540 # 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 format which was

545 # Dovecot ’s default , so if you ’re building a new server it would be a good

# idea to change this. %08Xu %08Xv should be pretty fail -safe.

A. Gutierrez Mayoral xlv ETSI Informatica


#

# NOTE: Nowadays this is required to be set explicitly , since the old

# default was bad but it couldn ’t be changed without breaking existing

550 # installations . %08Xu %08Xv will be the new default , so use it for new

# installations .

#

pop3_uidl_format = %f

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

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

565 # Support for dynamically loadable plugins. mail_plugins is a space separated

# list of plugins to load.

#mail_plugins =

#mail_plugin_dir = /usr/lib/dovecot/modules/pop3

570 # Workarounds for various client bugs:

# outlook -no -nuls:

# Outlook and Outlook Express hang if mails contain NUL characters.

# This setting replaces them with 0x80 character.

# oe -ns -eoh:

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

##

## dovecot -lda specific settings

##

585 # protocol lda {

# If you wish to use plugins you need to specify plugin directory

# For example quota enforcing is implemented by plugin

#module_dir = /usr/lib/dovecot/modules/lda

590 # 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 script is

# executed if set.

595 #global_script_path =

# UNIX socket path to master authentication server to find users.

#auth_socket_path = /var/run/dovecot -auth -master

# }

600

##

## Authentication processes

##

605 # Executable location

#auth_executable = /usr/lib/dovecot/dovecot -auth

# Set max. process size in megabytes.

#auth_process_size = 256

610

# Authentication cache size in kilobytes. 0 means it ’s disabled.

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

615 #auth_cache_size = 0

# Time to live in seconds for cached data. After this many seconds the cached

Proyecto Fin de Carrera xlvi Universidad Rey Juan Carlos


# record is no longer used , *except* if the main database lookup returns

# internal failure.

#auth_cache_ttl = 3600

620

# Space separated list of realms for SASL authentication mechanisms that need

# them. You can leave it empty if you don ’t want to support multiple realms.

# Many clients simply use the first one listed here , so keep the default realm

# first.

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

# List of allowed characters in username. If the user -given username contains

# a character not listed in here , the login automatically fails. 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 allow all characters ,

635 # set this value to empty.

#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890 .-_@

# Username character translations before it ’s looked up from databases. The

# value contains series of from -> to characters. For example "#@/@" means

640 # that ’#’ and ’/’ characters are translated to ’@’.

#auth_username_translation =

# If you want to allow master users to log in by specifying the master

# username within the normal username string (ie. not using SASL mechanism ’s

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

650 # Username to use for users logging in with ANONYMOUS SASL mechanism

#auth_anonymous_username = anonymous

# More verbose logging. Useful for figuring out why authentication isn ’t

# working.

655 #auth_verbose = no

# Even more verbose logging for debugging purposes. Shows for example SQL

# queries.

#auth_debug = no

660

# In case of password mismatches , log the passwords and used scheme so the

# problem can be debugged. Requires auth_debug=yes to be set.

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

#auth_worker_max_count = 30

670 # Kerberos keytab to use for the GSSAPI mechanism. Will use the system

# default (usually /etc/krb5.keytab) if not specified.

#auth_krb5_keytab =

auth default {

675 # Space separated list of wanted authentication mechanisms :

# plain login digest -md5 cram -md5 ntlm rpa apop anonymous gssapi

#mechanisms = plain login

##

680 ## dovecot -lda specific settings

##

#

# Password database is used to verify user ’s password (and nothing more).

685 # You can have multiple passdbs and userdbs. This is useful if you want to

# allow both system users (/etc/passwd) and virtual users to login without

A. Gutierrez Mayoral xlvii ETSI Informatica


# duplicating the system users into virtual database.

#

# http :// wiki.dovecot.org/Authentication

690 #

# By adding master=yes setting inside a passdb you make the passdb 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 setting to the

695 # master passdb.

#

# http :// wiki.dovecot.org/MasterPassword

# Users can be temporarily disabled by adding a passdb with deny=yes.

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

705 #args = /etc/dovecot.deny

#deny = yes

#}

# PAM authentication. Preferred nowadays by most systems.

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

715 passdb pam {

# [session=yes] [cache_key=<key >] [<service name >]

#

# session=yes makes Dovecot open and immediately close PAM session. Some

# PAM plugins need this to work , such as pam_mkhomedir .

720 #

# 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 checking password ,

# such as checking IP address. Dovecot can ’t know about these checks

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

730 # %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).

735 #

# Some examples:

# args = session=yes *

# args = cache_key= %u dovecot

#args = dovecot

740 }

# /etc/passwd or similar , using getpwnam ()

# In many systems nowadays this uses Name Service Switch , which is

# configured in /etc/nsswitch.conf.

745 #passdb passwd {

#}

# /etc/shadow or similiar , using getspnam (). Deprecated by PAM nowadays.

#passdb shadow {

750 #}

# BSD authentication. Used by at least OpenBSD.

#passdb bsdauth {

# [cache_key=<key >] - See cache_key in PAM for explanation.

755 #args =

#}

Proyecto Fin de Carrera xlviii Universidad Rey Juan Carlos


# passwd -like file with specified location

#passdb passwd -file {

760 # Path for passwd -file

#args =

#}

# checkpassword executable authentication

765 # NOTE: You will probably want to use "userdb prefetch" with this.

#passdb checkpassword {

# Path for checkpassword binary

#args =

#}

770

# SQL database

#passdb sql {

# Path for SQL configuration file , see /etc/dovecot/dovecot -sql.conf for

# example

775 #args =

#}

# LDAP database

#passdb ldap {

780 # Path for LDAP configuration file , see /etc/dovecot/dovecot -ldap.conf for

# example

#args =

#}

785 # vpopmail authentication

#passdb vpopmail {

# [cache_key=<key >] - See cache_key in PAM for explanation.

#args =

#}

790

#

# User database specifies where mails are located and what user/group IDs

# own them. For single -UID configuration use "static ".

#

795 # http :// wiki.dovecot.org/Authentication

# http :// wiki.dovecot.org/VirtualUsers

#

# /etc/passwd or similar , using getpwnam ()

800 # In many systems nowadays this uses Name Service Switch , which is

# configured in /etc/nsswitch.conf.

userdb passwd {

}

805 # passwd -like file with specified location

#userdb passwd -file {

# Path for passwd -file

#args =

#}

810

# static settings generated from template

#userdb static {

# Template for settings. Can return anything a userdb could normally

# return , eg.: uid , gid , home , mail , nice

815 #

# 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

820 #

#args =

#}

# SQL database

825 #userdb sql {

# Path for SQL configuration file , see /etc/dovecot/dovecot -sql.conf for

A. Gutierrez Mayoral xlix ETSI Informatica


# example

#args =

#}

830

# LDAP database

#userdb ldap {

# Path for LDAP configuration file , see /etc/dovecot/dovecot -ldap.conf for

# example

835 #args =

#}

# vpopmail

#userdb vpopmail {

840 #}

# "prefetch" user database means that the passdb already provided the

# needed information and there ’s no need to do a separate userdb lookup.

# This can be made to work with SQL and LDAP databases , see their example

845 # configuration files for more information how to do it.

# http :// wiki.dovecot.org/AuthSpecials

#userdb prefetch {

#}

850 # User to use for the process. This user needs access to only user and

# password databases , nothing else. Only shadow and pam authentication

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

855 # That user is specified by userdb above.

user = root

# Directory where to chroot the process. Most authentication backends don ’t

# work if this is set , and there ’s no point chrooting if auth_user is root.

860 # Note that valid_chroot_dirs isn ’t needed to use this setting.

#chroot =

# Number of authentication processes to create

#count = 1

865

# Require a valid SSL client certificate or the authentication fails.

#ssl_require_client_cert = no

# Take the username from client ’s SSL certificate , using X509_NAME_oneline ()

870 # which typically uses subject ’s Distinguished Name.

#ssl_username_from_cert = no

}

# It ’s possible to export the authentication interface to other programs ,

875 # 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 anyone access to

# it. Master socket is used to a) query if given client was successfully

# authenticated , b) userdb lookups.

880

# listener sockets will be created by Dovecot ’s master process using the

# settings given inside the auth section

#auth default_with_listener {

# mechanisms = plain

885 # passdb pam {

# }

# userdb passwd {

# }

# socket listen {

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

895 # # Default user/group is the one who started dovecot -auth (root)

# #user =

Proyecto Fin de Carrera l Universidad Rey Juan Carlos


# #group =

# }

# client {

900 # path = /var/run/dovecot -auth -client

# mode = 0660

# }

# }

#}

905

# connect sockets are assumed to be already running , Dovecot ’s master

# process only tries to connect to them. They don ’t need any other settings

# than path for the master socket , as the configuration is done elsewhere.

# Note that the client sockets must exist in login_dir.

910 #auth external {

# socket connect {

# master {

# path = /var/run/dovecot -auth -master

# }

915 # }

#}

plugin {

# Here you can give some extra environment variables to mail processes.

920 # This is mostly meant for passing parameters to plugins. %variable

# expansion is done for all values.

# Quota plugin. Multiple backends are supported:

# dirsize: Find and sum all the files found from mail directory

925 # dict: Keep quota stored in dictionary (eg. SQL)

# maildir: Maildir ++ quota

# fs: Read -only support for filesystem quota

#quota = maildir

930 # ACL plugin. vfile backend reads ACLs from "dovecot -acl" file from maildir

# directory. You can also optionally give a global ACL directory path where

# ACLs are applied to all users ’ mailboxes. The global ACL directory contains

# one file for each mailbox , eg. INBOX or sub.mailbox.

#acl = vfile :/etc/dovecot -acls

935

# Convert plugin. If set , specifies the source storage path which is

# converted to destination storage (default_mail_env).

#convert_mail = mbox: %h/mail

}

C.3. Maquina lechuzo

El unico servicio relevante que se sirve en la maquina lechuzo (servicio crıtico, por otra parte)son los ficheros personales de los usuarios, a traves de NFS. El fichero de configuracion masimportante es el fichero /etc/exports, que se muestra a continuacion.

Listado C.12: Fichero de configuracion /etc/exports

#

# /etc/exports: the access control list for filesystems which may be exported

# to NFS clients. See exports (5).

5 #

# Example for NFSv2 and NFSv3:

# /srv/homes hostname1(rw ,sync) hostname2(ro ,sync)

#

# Example for NFSv4:

10 # /srv/nfs4 gss/krb5i(rw ,sync ,fsid=0,crossmnt)

# /srv/nfs4/homes gss/krb5i(rw ,sync)

#

# HOMES

A. Gutierrez Mayoral li ETSI Informatica

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

C.4. Maquina peloto

El servicio mas relevante de esta maquina es el que se ofrece a traves del servidor LDAP. Lamaquina peloto es el servidor LDAP primario del Laboratorio. El fichero de configuracion de esteservicio se encuentra en /etc/ldap/slapd.conf.

Listado C.13: Fichero de configuracion /etc/postfix/master.cf

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

# info on the configuration options.

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

5 # Global Directives:

# Features to permit

#allow bind_v2

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

15 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

25 loglevel 0

# Where the dynamically loaded modules are stored

modulepath /usr/lib/ldap

moduleload back_bdb

30

# The maximum number of entries that is returned for a search operation

sizelimit -1

# The tool -threads parameter sets the actual amount of cpu ’s that is used

35 # for indexing.

tool -threads 1

threads 64

40 #######################################################################

# Specific Backend Directives for bdb:



backend bdb

45 checkpoint 512 30

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

# Specific Backend Directives for ’other ’:


50 # ’backend ’ directive occurs

#backend <other >

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

# Specific Directives for database #1, of type bdb:

Proyecto Fin de Carrera lii Universidad Rey Juan Carlos


55 # Database specific directives apply to this databasse until another


database bdb

# The base of your directory in database #1

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

# rootdn directive for specifying a superuser on the database. This is needed

# for syncrepl.

# rootdn "cn=admin ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

65

# Where the database file are physically stored for database #1

directory "/var/lib/ldap"

# For the Debian package we use 2MB as default but be sure to update this

70 # value if you have plenty of RAM

dbconfig set_cachesize 0 2097152 0

# Sven Hartge reported that he had to set this value incredibly high

# to get slapd running at all. See http :// bugs.debian.org /303057

75 # for more information.

# Number of objects that can be locked at the same time.

dbconfig set_lk_max_objects 1500

# Number of locks (both requested and granted)

80 dbconfig set_lk_max_locks 1500

# Number of lockers

dbconfig set_lk_max_lockers 1500

# Indexing options for database #1

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

90 lastmod on

# Where to store the replica logs for database #1

replogfile /var/lib/ldap/replog

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 access to attrs=userPassword ,shadowLastChange



write


write


105 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



write

by dn="uid=jcenteno ,ou=usuarios ,ou=profesores ,dc=zipi ,dc=escet ,dc=urjc ,dc=es"

write

110 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




115 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




A. Gutierrez Mayoral liii ETSI Informatica

C.4. MAQUINA PELOTO

120 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




125 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

130 by * none

# Ensure read access to the base for things like

# supportedSASLMechanisms . Without this you may

# have problems with SASL not knowing what

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

140 # happily.

access to dn.base ="" by * read


# can read everything.

145 access to *



write


write


150 by dn="uid=kleal ,ou=usuarios ,ou=profesores ,dc=zipi ,dc=escet ,dc=urjc ,dc=es" write



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

155 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




160 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




165 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




170 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

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

# by dnattr=owner write

180

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

Proyecto Fin de Carrera liv Universidad Rey Juan Carlos


# Specific Directives for database #2, of type ’other ’ (can be bdb too):

# Database specific directives apply to this databasse until another


185 #database <other >

# The base of your directory for database #2

#suffix "dc=debian ,dc=org"

#

190

TLSCipherSuite HIGH:MEDIUM:-SSLv2

TLSCACertificateFile /etc/ldap/ssl/server.pem

TLSCertificateFile /etc/ldap/ssl/server.pem

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


replica uri=ldaps :// nano.cct.urjc.es



C.5. Maquina sapientin

La maquina sapientin nos sirve para realizar copias de seguridad diarias de los directoriospersonales de los alumnos (servidos por la maquina lechuzo). Por tanto, la configuracion de NFSes muy similar (por no decir identica) a la de la maquina lechuzo. El fichero mas relevante en estecaso es el fichero /etc/exports, que es identico al de la maquina lechuzo.

C.6. Maquina minervo

La maquina minervo aloja las copias de seguridad de los directorios /etc/ y /root/ detodas las maquinas, de forma incremental. Cada dıa, se comprime este directorio y se sincronizautilizando rsync a la maquina minervo. En principio, esta maquina no tiene ficheros deconfiguracion relevantes.

C.7. Maquina espatula

La maquina espatula hospeda el servicio de monitorizacion Nagios. Debido a que los ficherosde configuracion de esta aplicacion son excesivamente largos y verbosos, no se listaran en estedocumento. En el soporte electronico adjunto se incluyen todos los ficheros de configuracion deesta herramienta.

C.8. Maquina bilo

La maquina bilo aloja para los Laboratorios del Campus de Fuenlabrada los servicios depagina web del Laboratorio, servidor de correo electronico para las cuentas @bilo.cct.urjc.esası como servidor de recogida de correo electronico (al igual que la maquina pantuflo.). Ademas,esta maquina aloja los ficheros personales o directorios HOME servidos para el Campus deFuenlabrada. Ademas, esta maquina aloja la pagina web para el Laboratorio de Fuenlabrada, el

A. Gutierrez Mayoral lv ETSI Informatica

C.9. MAQUINA NANO

servicio de transporte de correo (Postfix) para el dominio bilo.cct.urjc.es y los respectivosservicios de recogida de correo a traves de los protocolos POP3 e IMAP. Debido a queestos ultimos son muy similares a los de la maquina pantuflo (las aplicaciones que se usan sonexactamente las mismas, con las mismas configuraciones) redirigimos al lector del documento alsoporte electronico si tiene especial interes en la consulta de estos ficheros.

C.8.1. Servicio NFS en bilo

El servicio NFS proporciona los directorios personales de los alumnos a traves de la red.La configuracion de este servicio se encuentra en el fichero /etc/exports, el cual se muestra acontinuacion:

Listado C.14: Fichero de configuracion /etc/exports

# /etc/exports: the access control list for filesystems which may be exported

# to NFS clients. See exports (5).

/disks/raid/homes.fuenla/ *.cct.urjc.es(rw ,sync ,no_root_squash)\

5 193.147.57.0/24(rw ,sync ,no_root_squash)

C.9. Maquina nano

Por ultimo, la maquina nano, cuya funcion es muy parecida a la maquina sapientin delCampus de Mostoles (aloja copias de seguridad de los directorios personales de los alumnos) sirveunicamente el servicio NFS de disco en red. Si la maquina bilo deja de funcionar, serıa necesarioque la maquina nano comenzara a servir los directorios de los alumnos a traves de NFS. En estesentido, el fichero de configuracion de NFS, situado en /etc/exports, es el mismo que el de lamaquina bilo, mostrado en la seccion anterior.

Ademas, la maquina nano sirve de forma secundaria el arbol LDAP en el que se almacenan lascuentas de usuario de los alumnos y profesores del Laboratorio. El fichero de configuracion de esteservicio es exactamente el mismo que el de las maquinas zipi o zape mostrado anteriormente (lascuales sirven el directorio LDAP tambien de forma secundaria). Remitimos al lector al soporteelectronico adjuntado en caso de mostrar interes en su consulta.

Proyecto Fin de Carrera lvi Universidad Rey Juan Carlos

Bibliografıa

[1] Tom Adelstein, Administracion de Sistemas LinuxAnaya Multimedia, 2007

[2] Gerald Carter, LDAP System AdministrationO’Reilly, 2003

[3] Hal Stern, Managing NFS and NISO’Reilly, 2001

[4] Michael D. Baurer, Seguridad en Servidores LinuxO’Reilly, 2005

[5] Chris McNab, Seguridad de RedesO’Reilly, 2004

[6] Brian W. Kernighan, El Entorno de programacion UNIXPearson Educacion, 1987

lvii

BIBLIOGRAFIA

Proyecto Fin de Carrera lviii Universidad Rey Juan Carlos

memoria pfc superior

Documents