ر ز ×طض سز ث ×ط ر ×
Transcripción
ر ز ×طض سز ث ×ط ر ×
DEPARTAMENTO DE SISTEMAS INFORMATICOS Y COMPUTACION Administracion de Sistemas RedHat Linux 6.2 y Windows NT 4.0 Agust n Espinosa Minguet Andr es M. Terrasa Barrena Apuntes y Actividades Practicas de las Asignaturas CSO (FI) y AUW (EUI) Curso Academico 2000/2001 Valencia, 1 de febrero de 2001 Indice General 1 Introduccion 1 1.1 Profesorado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Horarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Pagina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Los Discos Duros 5 2.1 Geometra del Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Lmites a la Geometra de los Discos IDE . . . . . . . . . . . . . . . . . . . 6 2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE . . . . . 7 2.4 Particiones del Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Utilizacion de las Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1 DOS, Windows 95, 98 y NT . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6 Utilizacion de los Discos en el Laboratorio de Practicas . . . . . . . . . . . 10 3 Usuarios y Proteccion en Linux 13 3.1 La Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 La Extension de la Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . 14 3.3 La Tabla de Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 i INDICE GENERAL ii 3.4 Procedimientos para la Creacion de Grupos y Usuarios . . . . . . . . . . . . 15 3.5 Atributos de Proteccion de los Procesos . . . . . . . . . . . . . . . . . . . . 16 3.6 Atributos de Proteccion de los Ficheros . . . . . . . . . . . . . . . . . . . . 16 3.7 Las Reglas de Proteccion Basicas . . . . . . . . . . . . . . . . . . . . . . . . 18 3.8 Cambio de Atributos de Proteccion en Ficheros . . . . . . . . . . . . . . . . 18 3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables . . . . . . . . . . . . 19 3.10 El bit SETGID en Directorios . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.11 La Mascara de Creacion de Ficheros . . . . . . . . . . . . . . . . . . . . . . 20 3.12 La Estrategia de los Grupos Privados . . . . . . . . . . . . . . . . . . . . . . 20 3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados . . . . . . . 21 4 Usuarios y Proteccion en Windows NT 25 4.1 Conceptos de Usuario y de Cuenta de Usuario . . . . . . . . . . . . . . . . . 25 4.2 Grupos de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Permisos y Derechos (o Privilegios) . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 Asignacion de Permisos a Archivos y Directorios . . . . . . . . . . . . . . . 30 4.5 Mandatos NT para la creacion de usuarios y grupos . . . . . . . . . . . . . 33 5 Dominios en Windows NT 35 5.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Usuarios y Grupos en un Domino . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 Ordenadores Miembros de un Dominio . . . . . . . . . . . . . . . . . . . . . 39 5.4 Comparticion de Recursos entre Sistemas NT . . . . . . . . . . . . . . . . . 39 5.5 Conanzas entre Dominios NT . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.6 Mandatos NT para compartir recursos . . . . . . . . . . . . . . . . . . . . . 43 6 Niveles de ejecucion en Linux 45 6.1 Inicio y Detencion de un Sistema Linux . . . . . . . . . . . . . . . . . . . . 45 6.2 El Concepto de Nivel de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . 45 6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion . . . . . 47 6.4 Secuencia de Arranque de un Sistema Linux . . . . . . . . . . . . . . . . . . 47 c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV INDICE GENERAL iii 6.5 Secuencia de Entrada en un Nivel de Ejecucion . . . . . . . . . . . . . . . . 48 6.6 Conguracion de los Niveles de Ejecucion . . . . . . . . . . . . . . . . . . . 49 7 Montaje de Dispositivos en Linux 51 7.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.2 Utilizacion Basica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.3 La tabla de Montaje de Dispositivos . . . . . . . . . . . . . . . . . . . . . . 52 7.4 Montaje de directorios remotos va NFS . . . . . . . . . . . . . . . . . . . . 54 7.5 Otros mandatos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 54 8 Dominios en Linux 55 8.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.2 Network Information System (NIS) . . . . . . . . . . . . . . . . . . . . . . . 55 8.2.1 Instalacion de los Componentes NIS Server . . . . . . . . . . . . . . 56 8.2.2 Conguracion del Servidor de NIS . . . . . . . . . . . . . . . . . . . 56 8.2.3 Conguracion del Cliente de NIS . . . . . . . . . . . . . . . . . . . . 57 8.3 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.3.1 Como Funciona NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 8.3.2 Instalacion y Conguracion del Cliente NFS . . . . . . . . . . . . . . 59 8.3.3 Instalacion y Conguracion del Servidor NFS . . . . . . . . . . . . . 60 9 Conguracion de Samba 63 9.1 >Que es samba? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.2 Instalacion de Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 9.3 Conguracion de Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 9.4 Instalacion y Conguracion de swat . . . . . . . . . . . . . . . . . . . . . . 66 9.5 Niveles de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 9.6 Conguracion de Samba con el Nivel de Seguridad domain . . . . . . . . . . 68 9.7 Tratamiento de los Accesos como Invitado . . . . . . . . . . . . . . . . . . . 69 9.8 El Sistema de Ficheros SMB para Linux . . . . . . . . . . . . . . . . . . . . 70 9.9 Opciones del Servidor Samba . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 INDICE GENERAL iv 9.10 Opciones del Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 10 Servicio de Nombres de Internet de Windows 73 10.1 Descripcion Basica de WINS . . . . . . . . . . . . . . . . . . . . . . . . . . 73 10.2 Servidores de Duplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 10.3 El Proceso de Registro, Renovacion y Liberacion . . . . . . . . . . . . . . . 76 10.4 El Proceso de Resolucion de Nombres . . . . . . . . . . . . . . . . . . . . . 77 10.5 Instalacion del Servidor y de los Clientes WINS en NT . . . . . . . . . . . . 77 11 Servicio DHCP en Windows NT 79 11.1 Descripcion Basica de DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 79 11.2 Concepto de Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 11.3 Instalacion del Servidor y de los Clientes DHCP en NT . . . . . . . . . . . 81 11.4 El Administrador DHCP de NT . . . . . . . . . . . . . . . . . . . . . . . . . 82 11.5 La Utilidad ipconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 ANEXOS c Agust n Espinosa, Andr es Terrasa, 2001 85 Administraci on de Sistemas, DSIC, UPV Indice de Figuras 5.1 Ejemplo de relacion de conanza entre dominios NT. . . . . . . . . . . . . . 42 6.1 Editor de niveles de ejecucion (panel de control) de RedHat linux. . . . . . 49 9.1 Fichero /etc/smb.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 10.1 Servidores de Insercion y Extraccion en WINS. . . . . . . . . . . . . . . . . 76 11.1 Ejemplo de la utilidad ipconfig. . . . . . . . . . . . . . . . . . . . . . . . . 83 v Indice de Tablas 4.1 Derechos iniciales y habilidades preinstaladas de los gruos en NT . . . . . . 29 4.2 Permisos estandar sobre directorios en Windows NT . . . . . . . . . . . . . 31 4.3 Permisos estandar sobre archivos en Windows NT . . . . . . . . . . . . . . 32 5.1 Diferencias entre grupos globales y locales en Windows NT . . . . . . . . . 38 6.1 Niveles de ejecucion en RedHat Linux. . . . . . . . . . . . . . . . . . . . . . 46 7.1 Principales tipos de particiones utilizables desde Linux. . . . . . . . . . . . 52 7.2 Interpretacion del chero /etc/fstab. . . . . . . . . . . . . . . . . . . . . . 53 7.3 Opciones mas comunes en el montaje de dispositivos en Linux. . . . . . . . 54 8.1 Opciones mas usuales en la exportacion de directorios mediante NFS. . . . 61 9.1 Secciones globales en el chero /etc/smb.conf. . . . . . . . . . . . . . . . . 66 9.2 Principales opciones de la seccion [global] de Samba. . . . . . . . . . . . . 71 9.4 Principales opciones de recurso de Samba. . . . . . . . . . . . . . . . . . . . 72 vii Cap tulo 1 Introduccion Indice General 1.1 1.2 1.3 1.4 1.5 Profesorado Programa . Evaluacion . Horarios . . Pagina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Profesorado Agustn Espinosa Minguet ([email protected]) Andres Terrasa Barrena ([email protected]) Alvaro Alvarez Rodrguez ([email protected]) 1.2 Programa 1) Instalacion de RedHat Linux. 2) Instalacion de Windows NT. 3) Seguridad y Proteccion en RedHat Linux. 4) Seguridad y Proteccion en Windows NT. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 2 3 2 Introduccion 5) Dominios y Sistemas de Archivos en Red en Unix. 6) Dominios y Sistemas de Archivos en Red en Windows NT. 7) Interoperatividad entre Unix y Windows NT (Samba). 8) Conguracion de la red en Windows NT (Enrutamiento, Wins, DHCP). 9) Conguracion de la red en RedHat Linux (Enrutamiento, DNS). 10) Servidores de correo. 1.3 Evaluacion a) Convocatoria Ordinaria Actividad de laboratorio 70%. { Cada no asistencia a practicas resta un 10% de la nota de practicas. { Cada practica es evaluada con calicacion al grupo de Suspenso, Notable o Sobresaliente. { Deben aprobarse las practicas para aprobar la asignatura. Examen escrito 30% { Debe aprobarse el examen escrito para aprobar la asignatura b) Convocatoria Extraordinaria Examen escrito 30% Recupera el examen escrito de la convocatoria ordinaria. S olo pueden presentarse aquellos alumnos que hayan aprobado las practicas en la convocatoria ordinaria. 1.4 Horarios Teor a CSO Da Hora Aula Profesor Miercoles Jueves De 15 a 17 De 8:30 a 10:30 Aula 2.3 Facultad Aula 2.3 Facultad Andres Terrasa Andres Terrasa Martes Viernes Viernes Viernes De De De De Laboratorio CSO 15 10 10 15 a a a a 17 12 12 17 c Agust n Espinosa, Andr es Terrasa, 2001 Laboratorio 4 Laboratorio 4 Laboratorio 4 Laboratorio 4 DSIC DSIC DSIC DSIC Andres Terrasa Agustn Espinosa Agustn Espinosa Agustn Espinosa Administraci on de Sistemas, DSIC, UPV 3 1.5 Pagina Web Teor a AUW Da Hora Aula Profesor Lunes Miercoles De 10 a 12 De 12:30 a 14:30 Aula B-5 Escuela Aula B-5 Escuela Agustn Espinosa Agustn Espinosa Laboratorio AUW Martes Jueves Viernes Viernes De De De De 17 a 19 10:30 a 12:30 17 a 19 19 a 21 Laboratorio 4 Laboratorio 4 Laboratorio 4 Laboratorio 4 DSIC DSIC DSIC DSIC Andres Terrasa Andres Terrasa Alvaro Alvarez Alvaro Alvarez 1.5 Pagina Web http://www.dsic.upv.es/asignaturas/facultad/cso Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Cap tulo 2 Los Discos Duros Indice General 2.1 Geometra del Disco . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Lmites a la Geometra de los Discos IDE . . . . . . . . . . . . 2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Particiones del Disco . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Utilizacion de las Particiones . . . . . . . . . . . . . . . . . . . 2.5.1 2.5.2 . . 5 6 . . . 7 8 9 DOS, Windows 95, 98 y NT . . . . . . . . . . . . . . . . . . . . . Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 2.6 Utilizacion de los Discos en el Laboratorio de Practicas . . . . 10 2.1 Geometra del Disco Los discos duros son el medio de almacenamiento masivo y permanente por excelencia en los ordenadores. Existen dos grandes grupos de discos en funcion de su interfaz con el ordenador, IDE y SCSI. En esencia, ambos grupos son equivalentes, salvo en aspectos de rendimiento, abilidad y precio. Dieren, eso s, en las limitaciones que el software de sistemas ha impuesto de forma articial a los discos IDE en el mundo de los PCs. Un disco almacena su informacion en uno o mas platos, disponiendo de una cabeza lectora para cada una de las dos caras del plato (aunque en algunas ocasiones una cara no es utilizada). Cada cara esta dividida en varios anillos concentricos, denominados pistas. Esta division es debida a que el plato gira sobre su eje, y la cabeza lectora se desplaza longitudinalmente hacia o desde el eje. A su vez, cada pista esta subdividida en sectores, todos ellos de igual capacidad, 512 bytes en la gran mayora de los casos. Todos los platos 5 6 Los Discos Duros de un disco estan unidos y tambien lo estan entre si las cabezas lectoras. El conjunto de pistas que se encuentran bajo todas las cabezas lectoras recibe el nombre de cilindro. Resumiendo, la capacidad de un disco puede describirse indicando su numero de cilindros, cabezales y sectores por pista. Por ejemplo, un disco con 4096 cilindros, 16 cabezales y 63 sectores por pista alberga un total de: 4096 x 16 x 63 = 4.128.768 sectores de 512 bytes = 2.113.929.216 bytes = 2.064.384 Kbytes = 2.016 Mbytes = 1'96875 Gbytes. Hay que tener en cuenta que el fabricante del disco dira que su disco tiene 211 Gbytes. Los fabricantes de discos asumen que un Gbyte equivale a mil millones de bytes, no a 230 bytes. Por cierto, los nuevos estandares dan la razon a los fabricantes, y nos indican que deberamos utilizar los nuevos terminos Kibytes, Mibytes, Gibytes para expresar las correspondientes potencias de 2. Sin embargo, en este documento no vamos a utilizar este estandar. 2.2 Lmites a la Geometra de los Discos IDE Existen diferentes lmites a la geometra descrita que han sido impuestos (articialmente) por el hardware o el software. Los mas importantes son los siguientes: a) La especicacion ATA (127'5 Gbytes). Se calcula como: 65536 cilindros * 16 cabezales * 256 sectores por pista. En el momento de escribir estas lneas, este lmite aun no se ha alcanzado, pero ya estan a la venta discos IDE de mas de 30 Gbytes, as que no andamos muy lejos. b) La limitacion de las rutinas de disco \clasicas" de la BIOS (7,84 Gbytes). Se calcula como: 1024 cilindros * 255 cabezales * 63 sectores por pista. Esta es una seria limitacion para el software que requiere de la BIOS para acceder al disco, como, por ejemplo, el ancestral sistema DOS y LILO, el cargador por excelencia del sistema operativo Linux. c) La limitacion conjunta de las dos anteriores (504 Mbytes). En este caso, su calculo es de: 1024 cilindros * 16 cabezales * 63 sectores por pista. Es decir, como un disco no puede tener mas de 16, cabezales, la limitacion de la BIOS se limita aun mas al pasar de 255 cabezales (BIOS) a 16 cabezales (ATA). c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE 7 La aparicion de discos de mas de 504 Mb, con mas de 1024 cilindros, causo serios problemas, ya que millones de ordenadores con DOS instalado no podan utilizarlos directamente. Las BIOS fueron modicadas y se invento el truco de la traduccion de direcciones conocida como LBA (o Logical Block Addressing). La BIOS informa al sistema que el disco tiene menos de 1024 cilindros. Cuando el sistema accede al disco, la BIOS realiza la traduccion y accede al lugar correcto. Para llorar. Las BIOS incorporaron tambien nuevas rutinas de acceso al disco distintas de las \clasicas" para acceder a los discos grandes, con mas de 1024 cilindros en modo LBA. Un ejemplo de traduccion podra ser: Disco real: 20.928 cilindros, 16 cabezales, 63 sectores por pista. Disco con LBA: 1.313 cilindros, 255 cabezales, 63 sectores por pista. 2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE Estas limitaciones en los discos tpicos para PC han ocasionado limitaciones en algunos sistemas operativos. A continuacion se revisan los sistemas mas populares: a) DOS, Windows 3.x, Windows 95, Windows NT 3.x. DOS utiliza las rutinas \clasicas" de la BIOS para acceder al disco. Por tanto, DOS no puede utilizar mas de 1024 cilindros. El modo LBA es imprescindible y el tama~no maximo de disco soportado, tal como se ha explicado anteriormente, es de 7'84 Gbytes. Los sistemas Windows que aparecieron a continuacion heredaron esta restriccion de DOS por motivos de compatibilidad. b) Windows 95 OSR2, Windows 98. No tienen ningun problema. No utilizan las rutinas clasicas de la BIOS y por tanto pueden utilizar mas de 1024 cilindros. c) Linux. A partir de los nucleos 2.0.34 y 2.2.* Linux puede acceder sin problemas a discos con mas de 1024 cilindros LBA. Los nucleos anteriores no utilizaban la BIOS, pero entendan que era un error que un disco informase mas de 1024 cilindros LBA. No obstante, LILO, el cargador de Linux, utiliza las rutinas clasicas de la BIOS (Linux aun no esta en funcionamiento), con lo cual LILO no puede funcionar si el nucleo de Linux a cargar reside todo o en parte a partir de los 1024 cilindros. La estrategia para que LILO no cause problemas es simple. Hay que hacer que el chero que contiene el codigo del nucleo de Linux (/boot/vmlinuz generalmente) resida completamente en cilindros anteriores al 1024. Esto puede conseguirse instalando la particion raz de Linux antes del cilindro 1024 o creando una particion peque~na (unos 10 Mbytes es suciente) que contenga el directorio /boot, y haciendo que sea esta la particion que resida antes de los 1024 cilindros. d) Windows NT 4.0. Este sistema tiene soporte para discos grandes desde su aparicion. No obstante, el proceso de instalacion de NT esta basado en DOS, con lo cual, la particion donde reside NT debe estar antes de la barrera de los 1024 cilindros. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 8 Los Discos Duros En resumen, en nuestros das aun seguimos atados a las restricciones que impuso el dise~no original de la BIOS. Es de esperar que LILO sea modicado y Windows 2000 (sucesor de Windows NT) disponga de un mecanismo de instalacion que no dependa de DOS. Hasta entonces, el modo LBA debe seguir siendo utilizado salvo que en el ordenador vaya a utilizarse tan solo Windows 98 (y, >quien quiere tener solo eso?). 2.4 Particiones del Disco En el primer sector de un disco duro reside el denominado MBR (o Master Boot Record). En estos 512 bytes residen el codigo inicial de carga del sistema operativo, la tabla de particiones primarias y la rma del disco. El codigo de carga mas frecuente es el que dene el sistema operativo DOS, el cual se encarga de buscar la particion de arranque, cargar en memoria el primer sector de dicha es el metodo utilizado por todos los sistemas operativos particion y cederle el control. Este de Microsoft. Este codigo de carga puede recuperarse (reinstalarse) con el mandato DOS FDISK /MBR, el cual deja intacta la tabla de particiones. Otro codigo de carga bastante utilizado es LILO (mejor dicho, la primera fase de dicho cargador). Es mas complejo y exible que el codigo de carga de DOS, y utiliza la informacion que reside en el directorio /boot de Linux para determinar que sistema operativo debe cargarse. Existen otros codigos de carga con funcionamientos muy diversos, pero hoy en da son escasamente utilizados. Para restaurar (reinstalar) este codigo de arranque, basta con ejecutar el mandato Linux lilo, el cual utiliza el chero /etc/lilo.conf para congurar el mecanismo de carga de LILO. El codigo de carga se utiliza tan solo en el disco principal del sistema (es decir, el disco maestro del interfaz IDE primario). Hay BIOS que permiten arrancar de otros discos duros, pero generalmente aparecen numerosos problemas al utilizar esta opcion. La tabla de particiones esta formada por cuatro entradas, donde cada una de ellas describe una potencial particion primaria. Los detalles de cada entrada son algo oscuros, y su utilizacion vara sensiblemente de un sistema operativo a otro. No obstante, simplicando un poco, cada entrada indica, para la particion que describe, la siguiente informacion: El sector del disco donde comienza. Su tama~ no. Si es una partici on de arranque (activa). Su tipo. DOS, Windows 3.x y Windows 95 representan el inicio de la particion utilizando la tripleta <cilindro,cabezal,sector>, con lo cual el tama~no maximo de una particion es de 7'84 Gbytes (debido a la limitacion de los 1024 cilindros). El resto de sistemas c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 9 2.5 Utilizacion de las Particiones representan el inicio de la particion indicando cual es el sector logico donde comienza (viendo al disco como un vector de sectores logicos). Estos sistemas utilizan una palabra de 32 bits, lo que permite 232 sectores, equivalente a 2 Tbytes (2 x 1024 Gbytes). En este caso, aun estamos algo lejos de disponer de discos de estas caractersticas. El indicador de particion de arranque es utilizado tan solo por el codigo de carga de DOS. Linux ignora por completo esta informacion. Existen numerosos tipos de particiones, en funcion de su utilizacion o de su organizacion interna (establecida por el sistema operativo que la dena). Existe una convencion que establece el identicador de cada tipo de particion como un numero concreto en hexadecimal. La siguiente tabla expone los tipos de particiones mas habituales: Tipo Uso Limitacion 0 Particion vaca { 5 Particion extendida 1024 cilindros (7'84 Gbytes) 6 DOS FAT 16 2 Gbytes 7 OS2 o NTFS 2 Tbytes b Windows 95 FAT 32 2 Tbytes f Extendida Windows 95 2 Tbytes 80 Old Minix { 82 Linux swap { 83 Linux native 2 Tbytes Una particion extendida es un contenedor para otras particiones, a las cuales se les denomina particiones logicas. Solo una de las particiones primarias puede declararse como extendida. La representacion de las unidades logicas se realiza utilizando una lista enlazada que reside dentro de la particion extendida, por lo que no hay lmite en cuanto al numero de particiones logicas que se pueden crear. La particion extendida convencional ha tenido que ser cambiada por la nueva particion extendida Windows 95, ya que la primera no puede abarcar discos mayores de 7'84 Gbytes. 2.5 Utilizacion de las Particiones A continuacion se muestra a que tipos de particiones pueden acceder los distintos sistemas operativos. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 10 Los Discos Duros 2.5.1 DOS, Windows 95, 98 y NT Todos estos sistemas requieren una particion primaria en el disco principal marcada como de arranque para poder ser instalados. Ademas, presentan las siguientes caractersticas: En el caso de la familia Windows, pueden emplearse conjuntamente a la anterior particiones logicas ubicadas en cualquier disco o particiones primarias que residan en un disco no principal. Todos estos sistemas pueden acceder a particiones FAT16. Windows NT no puede acceder a particiones FAT32. Una consecuencia importante de esta restriccion es que Windows NT no puede ser instalado en un ordenador en el cual la particion primaria de arranque sea de tipo FAT32. DOS y Windows 95 no pueden acceder tampoco a particiones FAT32, las cuales s olo pueden ser utilizadas por Windows 95 OSR2 y Windows 98. DOS y Windows 9x no pueden acceder a particiones NTFS. 2.5.2 Linux Este sistema requiere al menos una particion de tipo Linux native para poder ser instalado. Esta particion puede ser primaria o logica y residir en cualquier disco; en esta particion residira el sistema de archivos raz (/). La particion de tipo Linux swap es necesaria si se requiere area de intercambio en disco; en este caso, pueden emplearse varias, ser logicas o primarias y residir en cualquier disco. La particion del sistema de archivos raz debe estar ntegramente ubicada antes del cilindro 1024 si se va a utilizar LILO. De no ser esto posible (o conveniente), puede crearse otra particion para que albergue al directorio /boot, la cual basta que tenga 10 Mbytes, y crearla antes del cilindro 1024. Linux puede acceder a particiones FAT16 y FAT32. El acceso a particiones NTFS es posible solo para lectura. 2.6 Utilizacion de los Discos en el Laboratorio de Practicas Los ordenadores del laboratorio de practicas disponen de dos discos, uno principal e interno y otro secundario y extrable. En el disco principal residen los sistemas Windows 98 y Linux utilizados en las practicas convencionales, siendo LILO el encargado de arrancar ambos sistemas. El disco extrable se utiliza exclusivamente en esta asignatura, y en el, tras las primeras sesiones de laboratorio, residiran varios sistemas Linux y Windows NT. El disco extrable tiene 10 Gbytes, con un total de 1313 cilindros en modo LBA. Esto supone algunos problemas para las instalaciones de NT y Linux, tal como se ha expuesto anteriormente en este documento. Como solucion se ha optado por instalar NT c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 11 2.6 Utilizacion de los Discos en el Laboratorio de Practicas en particiones ubicadas antes de los 1024 cilindros y utilizar la particion /boot para la instalacion de Linux. Cada grupo de laboratorio requiere cuatro particiones para instalar NT y Linux: FAT16 (NT), Linux swap, Linux native (raz) y otra Linux native (/boot). Dado que hasta siete grupos pueden utilizar el mismo ordenador, se requieren en total 32 particiones en cada disco extrable (o 25, si tenemos en cuenta que la particion Linux swap puede ser compartida). Aunque es factible crear tal numero de particiones en un disco, se ha observado que la instalacion de Linux no esta preparada para esta cifra. En cualquier caso, tambien resulta confusa la utilizacion de un disco particionado de este modo. Para solventar este problema, se ha escogido otra estrategia, la cual consiste en crear una tabla de particiones \a medida" cada vez que se inicia una sesion de practicas. Dicha tabla de particiones contiene tan solo las cuatro particiones necesarias, todas ellas primarias. La utilidad activa-hdc, instalada en el sistema Linux del disco principal, se encarga de crear esta tabla de forma que no se solapen particiones entre distintos turnos de practicas. Otro aspecto a destacar es relativo a la instalacion de Windows NT. Tal como se ha comentado, NT requiere utilizar la particion activa. En la particion activa de los ordenadores del laboratorio reside el sistema Windows 98 utilizado por las practicas convencionales, por lo cual no puede ser utilizada. Para poder instalar Windows NT es necesario \crear" una particion activa diferente, para lo cual existe una particion oculta en el disco principal (de tipo 80, Old Minix). Antes de la instalacion de NT, esta particion es convertida a FAT 16 y hecha activa, pasando la verdadera particion activa a ocultarse cambiando su tipo a Old Minix. Adicionalmente, la instalacion de Windows NT requiere el codigo de carga estandar de DOS en el MBR, y, en cambio, el codigo de carga utilizado actualmente es LILO. Por tanto, LILO debe ser sustituido antes de la instalacion de Window NT por el codigo de carga estandar. Una vez nalizada la instalacion de Windows NT debe recuperarse la situacion original, tras lo que se pierde la posibilidad de arrancar Windows NT desde disco duro, por lo que es necesario generar un disquete de arranque mientras se tiene acceso todava al sistema Windows NT instalado. Los documentos de instalacion de NT detallan los procedimientos a seguir para realizar estos cambios. Por contra, la instalacion de Linux puede realizarse mas facilmente, ya que no se requiere de la particion activa y la propia instalacion puede generar un disquete de arranque. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Cap tulo 3 Usuarios y Proteccion en Linux Indice General 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 La Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . La Extension de la Tabla de Usuarios . . . . . . . . . . . . . . . La Tabla de Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . Procedimientos para la Creacion de Grupos y Usuarios . . . . Atributos de Proteccion de los Procesos . . . . . . . . . . . . . . Atributos de Proteccion de los Ficheros . . . . . . . . . . . . . . Las Reglas de Proteccion Basicas . . . . . . . . . . . . . . . . . . Cambio de Atributos de Proteccion en Ficheros . . . . . . . . . Los Bits SETUID y SETGID en Ficheros Ejecutables . . . . . El bit SETGID en Directorios . . . . . . . . . . . . . . . . . . . . La Mascara de Creacion de Ficheros . . . . . . . . . . . . . . . . La Estrategia de los Grupos Privados . . . . . . . . . . . . . . . Sintaxis y Funcionamiento de los Mandatos Unix Relacionados 13 14 15 15 16 16 18 18 19 19 20 20 21 3.1 La Tabla de Usuarios Los usuarios de un sistema Unix son registrados en un chero denominado /etc/passwd. Cada lnea corresponde a un usuario y describe los atributos del mismo. Los atributos son separados por el caracter `:'. Por ejemplo, dada la siguiente lnea del chero /etc/passwd, a continuacion se describe cada elemento de la misma: usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:1002:2000:Usuario 1:/home/usu1: /bin/bash 13 14 Usuarios y Proteccion en Linux Elemento Signicado usu1 $1$ZtoHwEykKW/eCLH zSUigg5KAEyxa51 1002 2000 Nombre del usuario. Contrase~na cifrada. Usuario 1 /home/usu1 /bin/bash Identicador del usuario (UID). Indenticador del grupo primario al que pertenece el usuario (GID). Descripcion del usuario. Directorio de conexion inicial del usuario. Programa interprete de ordenes (shell). 3.2 La Extension de la Tabla de Usuarios Ademas de la tabla de usuarios descrita en el apartado anterior, en la mayora de sistemas Unix actuales se utiliza otra tabla, contenida en el chero /etc/shadow, en la que se almacena informacion adicional para los usuarios. Cada lnea de dicho chero corresponde a una lnea del chero /etc/passwd y la informacion que contiene es la siguiente (de acuerdo con el ejemplo anterior): usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:10989:0:99999:7:-1:-1:134538436 Elemento Signicado usu1 $1$ZtoHwEykKW/eC LHzSUigg5KAEyxa51 10989:0:99999:7: -1:-1:134538436 Nombre del usuario. Contrase~na cifrada. Informacion de caducidad de la contrase~na. Cuando el sistema emplea esta tabla, la contrase~na almacenada en el chero /etc/passwd se sustituye por una `x'. Dado que el chero /etc/passwd es legible por todos los usuarios mientras que /etc/shadow solo es legible por el administrador, mediante este cambio se consigue que ningun usuario tenga acceso a las contrase~nas cifradas. La informacion de caducidad de la contrase~na esta expresada en das, siendo su utilizacion e interpretacion compleja en algunos casos. Por este motivo, para modicar y consultar esta informacion no se recomienda en general trabajar directamente con el chero /etc/shadow, sino utilizar herramientas administrativas especcas, ya sea en forma de mandatos o mediante aplicaciones gracas. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 15 3.3 La Tabla de Grupos 3.3 La Tabla de Grupos Los grupos de un sistema Unix son registrados en un chero denominado /etc/group. Cada lnea corresponde a un grupo y describe los atributos del mismo. Los atributos son separados por el caracter `:' y su signicado se describe mediante el siguiente ejemplo: proy1::65534:usu1,usu2,usu3 Elemento Signicado proy1 Nombre del grupo. Contrase~na cifrada (vaca en el ejemplo). Esta contrase~na permite a un usuario cambiar de grupo primario si se conoce esta contrase~na. Esta funcionalidad esta en desuso. Identicador del grupo (GID). Lista de usuarios que pertenecen a este grupo. 65534 usu1,usu2,usu3 Como se deduce del ejemplo, un usuario puede gurar en la lista de distintos grupos, es decir, puede pertenecer a varios grupos. De todos esos grupos, aquel cuyo GID gura en la entrada correspondiente al usuario en el chero /etc/passwd se considera el grupo primario de dicho usuario. El resto de grupos se denominan grupos suplementarios. 3.4 Procedimientos para la Creacion de Grupos y Usuarios En la mayora de sistemas Unix System V pueden emplearse los siguientes mandatos para la gestion de usuarios y grupos: Mandato Uso useradd userdel usermod groupadd groupdel groupmod passwd chage A~nadir un usuario. Eliminar un usuario. Modicar los atributos de un usuario. A~nadir un grupo. Eliminar un grupo. Modicar los atributos de un grupo. Cambiar la contrase~na de un usuario. Gestionar la caducidad de la contrase~na. Estos mandatos son especialmente utiles cuando la gestion de usuarios debe realizarse Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 16 Usuarios y Proteccion en Linux desde scripts del shell, por ejemplo, cuando debe crearse una gran cantidad de usuarios de forma automatica. La sintaxis y opciones mas usuales de estos mandatos se citan en la Seccion 3.13, al nal de este captulo. Adicionalmente, cada vez es mas frecuente la disponibilidad de herramientas gracas que facilitan la labor del administrador. El programa linuxconf es el mas recomendable en entornos Linux, dado el amplio abanico de actividades administrativas que cubre. 3.5 Atributos de Proteccion de los Procesos Los atributos de un proceso que intervienen en el mecanismo de proteccion son: a) Identicadores del usuario propietario del proceso (rUID, eUID). La version real |rUID| corresponde al usuario que creo al proceso. La version efectiva | eUID| corresponde al usuario bajo el cual se comporta el proceso y es el utilizado en el mecanismo de proteccion. Ambos identicadores suelen ser iguales, salvo que intervenga el denominado bit SETUID en el chero ejecutable que esta ejecutando el proceso, tal como se describe mas adelante en este documento (ver Seccion 3.9). b) Identicadores del grupo propietario del proceso (rGID, eGID). La version real {rGID| corresponde al grupo primario al que pertenece el usuario que creo el proceso. La version efectiva |eGID| corresponde al grupo bajo el cual se comporta el proceso y es el utilizado en el mecanismo de proteccion. Ambos identicadores suelen ser iguales, salvo que intervenga el denominado bit SETGID en el chero ejecutable que esta ejecutando el proceso, tal como se describe mas adelante en este documento (ver Seccion 3.9). c) Lista de grupos suplementarios. Es la lista formada por los grupos suplementarios del usuario que creo el proceso. Estos atributos son asignados al proceso en el momento de su creacion, y heredados de su proceso padre. Cada usuario conectado a un sistema Unix posee un proceso de atencion denominado shell, el cual es el padre de todos los procesos que el usuario genera. Este proceso shell recibe sus atributos no por herencia, sino en el momento en el que un usuario se acredita al sistema mediante su nombre de usuario y contrase~na asociada. Los atributos rUID y rGID se extraen de la tabla de usuarios /etc/passwd. La lista de grupos suplementarios es confeccionada a partir de la tabla de grupos /etc/group. Los atributos eUID y eGID son asignados a los valores respectivos de rUID y rGID. Un mandato interesante al respecto es id, el cual muestra todos estos atibutos. 3.6 Atributos de Proteccion de los Ficheros Los atributos de un chero que intervienen en el mecanismo de proteccion son: c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 17 3.6 Atributos de Proteccion de los Ficheros OwnerUID. Identicador del usuario propietario del chero. b) OwnerGID. Identicador del grupo propietario del chero. a) c) Bits de permiso. Un total de 12 bits que expresan las operaciones del chero que son permitidas en funcion del proceso que acceda a este chero. En la tabla a continuacion se muestra el signicado de cada bit de permiso. Bit Signicado 11 10 9 8 7 6 5 4 3 2 1 0 SETUID. SETGID. Sticky. Lectura para el propietario. Escritura para el propietario. Ejecucion para el propietario. Lectura para el grupo propietario. Escritura para el grupo propietario. Ejecucion para el grupo propietario. Lectura para el resto de usuarios. Escritura para el resto de usuarios. Ejecucion para el resto de usuarios. Los bits SETUID y SETGID son tratados en apartados posteriores. El signicado de los bits de lectura, escritura y ejecucion es diferente en funcion del tipo de archivo que los dena. Para cheros regulares, su signicado es el esperable (permiten leer, modicar o ejecutar el chero). Evidentemente, el bit de ejecucion solo tiene sentido si el chero es un ejecutable o contiene un shellscript. En un directorio, su signicado es el siguiente: a) Lectura. Puede listarse el contenido del directorio. b) Escritura. Permite la creacion, eliminacion o renombrado de cheros o directorios dentro del directorio al cual se aplica este bit. c) Ejecucion. Permite la utilizacion del directorio al cual se aplica este bit para formar parte de un nombre de ruta, es decir, puede utilizarse el directorio para nombrar un chero. De lo anteriormente expuesto, puede observarse que no existe un bit de permiso especco para el borrado de un chero/directorio. Dicho permiso es controlado realmente Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 18 Usuarios y Proteccion en Linux desde el directorio donde reside el chero que quiere eliminarse. En algunos sistemas, el bit sticky es utilizado para modicar la regla de eliminacion de cheros: si se activa en un directorio, un usuario puede borrar un chero en el solo si es el propietario de dicho chero. El ownerUID puede modicarse con el mandato chown. El ownerGID puede modicarse con el mandato chgrp. Los bits de permiso pueden modicarse con el mandato chmod. Todos estos mandatos se describen en la Seccion 3.13. 3.7 Las Reglas de Proteccion Basicas Las reglas de proteccion basicas se activan cuando un proceso notica al sistema que desea utilizar un determinado chero. El proceso tambien notica al sistema que tipo de operacion u operaciones quiere realizar: lectura, escritura o ejecucion. Las reglas son: Si el eUID del proceso es 0 se concede el permiso (estamos en el caso en el que el proceso pertenece al superusuario). Si no. . . Si el eUID del proceso es igual al ownerUID del chero, se autoriza la operacion si esta permitida en el grupo de bits 6 al 8, los que corresponden al propietario. Si no. . . Si el eGID del proceso o alguno de los grupos suplementarios del proceso es igual al ownerGID del chero, se autoriza la operacion si esta permitida en el grupo de bits 3 al 5, los que corresponden al grupo. Si no. . . En cualquier otro caso, se autoriza la operacion si est a permitida en el grupo de bits 0 al 2, los que corresponden al resto de usuarios. Debe notarse que solo se aplica una regla, aquella que corresponde a la primera condicion que se cumple para los atributos del proceso. Es decir, el sistema determina primero que grupo de tres bits debe aplicar y despues autoriza (o deniega) la operacion en funcion del tipo de operacion requerida y del estado de dichos tres bits. 3.8 Cambio de Atributos de Proteccion en Ficheros Unix establece unas reglas de proteccion especcas para controlar los cambios de cualquier atributo de proteccion de un chero, dado que dichas modicaciones se consideran operaciones distintas de la de escritura, y por tanto no pueden ser concedidas/denegadas en funcion de los bits de permiso del chero. En concreto, las reglas establecidas al respecto son las siguientes: c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 19 3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables a) Cambio en los bits de permiso. Un proceso puede cambiar los bits de permiso de un chero solo si: el eUID del proceso es 0 (estamos en el caso en el que el proceso pertenece al superusuario), o bien el eUID del proceso es igual al ownerUID del chero. Es decir, solo el superusuario o el popietario de un chero pueden modicar sus bits de permiso. b) Cambio en el propietario. El cambio de propietario de un chero puede realizarlo tan solo el superusuario. c) Cambio de grupo propietario. El cambio del grupo propietario de un chero puede realizarse solo si: lo realiza el superusuario, o bien el nuevo grupo propietario del chero es igual a alguno de los grupos del usuario que realiza el cambio de grupo y este usuario es el propietario del chero. 3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables Estos bits se emplean para permitir que un programa se ejecute bajo los privilegios de un usuario distinto al que lanza la ejecucion del programa. Su funcionamiento es el siguiente: Si el chero ejecutable tiene el bit SETUID activo, el eUID del proceso que ejecuta el chero es hecho igual al ownerUID del chero. Si el chero ejecutable tiene el bit SETGID activo, el eGID del proceso que ejecuta el chero es hecho igual al ownerGID del chero. Normalmente estos programas pertenecen al superusuario, y permiten a los usuarios ejecutar tareas privilegiadas bajo ciertas condiciones. El cambio de la contrase~na de un usuario es un ejemplo de esta tecnica. La existencia de estos cheros en el sistema de archivos debe ser cuidadosamente supervisada por el superusuario. Muchos de los ataques de seguridad a Unix utilizan estos cheros para conseguir atentar contra la seguridad del sistema. 3.10 El bit SETGID en Directorios La utilizacion de este bit esta orientada a facilitar el trabajo en grupo cuando varios usuarios deben acceder a una coleccion comun de cheros y directorios. Su funcionamiento es el siguiente: si un directorio, llamemosle D, tiene el bit SETGID activo, entonces: Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 20 Usuarios y Proteccion en Linux si se crea un chero dentro de D, el ownerGID del nuevo chero es hecho igual al ownerGID del directorio D. si se crea un directorio dentro de D, el ownerGID del nuevo directorio es hecho igual al ownerGID del directorio D y su bit SETGID es activado. Puede observarse que se trata, en esencia, de un mecanismo de herencia. Cuando el bit SETGID no esta activo, el ownerGID de un chero o directorio se toma del eGID del proceso que lo crea. Utilizando el SETGID, aunque varios usuarios creen cheros dentro de un directorio, todos ellos perteneceran al menos al mismo grupo, con lo que una utilizacion adecuada de los bits de permiso puede hacer que todos ellos puedan, por ejemplo, leer y modicar dichos cheros. 3.11 La Mascara de Creacion de Ficheros Las utilidades de Unix que crean cheros utilizan por defecto la palabra de proteccion rw-rw-rw si se trata de cheros no ejecutables o rwxrwxrwx si se crea un directorio o un ejecutable. Puede observarse, por tanto, que todos los permisos son activados. Para modicar este funcionamiento, cada usuario puede especicar al sistema aquellos bits que no desea que sean activados mediante la mascara de creacion de cheros. La mascara se establece mediante el mandato umask. Cada bit activo en la mascara es un bit que sera desactivado cuando se cree un chero. Por ejemplo, una mascara 022 desactivara los bits de escritura para el grupo y el resto de usuarios. El administrador debera velar porque exista una mascara de creacion de cheros razonable por defecto para cualquier usuario. Esto puede conseguirse facilmente utilizando el chero /etc/profile, el cual sirve para personalizar el entorno de un usuario en el momento de su conexion. 3.12 La Estrategia de los Grupos Privados Esta estrategia, empleada por defecto en Redhat Linux, esta orientada a racionalizar y exibilizar la asignacion de usuarios a grupos. Las claves de esta estrategia son: Crear un grupo para cada usuario (utilizando para ello el mismo nombre del usuario), y hacer que este sea el grupo primario del usuario. Utilizar exclusivamente grupos suplementarios para agrupar usuarios. Utilizar el bit SETGID y un grupo suplementario en aquellos directorios donde varios usuarios tengan que colaborar. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados 21 Utilizar el grupo privado en el directorio de conexi on de cada usuario. Asignar como m ascara por defecto para todos los usuarios 00X, es decir, todos los permisos activos para el propietario y para el grupo y lo que se considere oportuno para el resto de usuarios. Se invita al lector a reexionar sobre las consecuencias de esta estrategia. 3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados useradd useradd [-u uid [-o]] [-g group] [-G group,...] [-d home] [-s shell] [-c comment] [-m [-k template]] [-f inactive] [-e expire mm/dd/yy] [-p passwd] [-n] [-r] name useradd -D [-g group] [-b base] [-s shell] [-f inactive] [-e expire mm/dd/yy] Crea un usuario. Opciones: -c -d -e -f Comentario sobre el usuario Directorio de conexion del usario Fecha en la cual la cuenta de usuario se desactiva D as que transcurrir an desde la caducidad de la contrase~na hasta la desactivaci on de la cuenta -g Nombre o numero del grupo primario -G Lista de los grupos suplementarios del usuario (separados por ,) (sin espacios) -m Crea el directorio de conexion. Si no se especifica la opcion -k, copia al directorio de conexion los ficheros del directorio /etc/skel -k Copia al directorio de conexion los ficheros del directorio template -p Asigna una contrase~ na cifrada al usuario -r Crea una cuenta del sistema -s Asigna el shell a utilizar por el usuario -u Asigna un UID concreto al usuario -o Permite crear un UID duplicado con la opcion -u -D Se asignan valores por defecto para las opciones indicadas. (No crea usuario) --------------------------------------------------------------------------userdel userdel [-r] name Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 22 Usuarios y Proteccion en Linux Elimina un usuario. Opciones: -r Elimina el directorio de conexi on del usario --------------------------------------------------------------------------usermod usermod [-u uid [-o]] [-g group] [-G group,...] [-d home [-m]] [-s shell] [-c comment] [-l new_name] [-f inactive] [-e expire mm/dd/yy] [-p passwd] [-L|-U] name Modifica atributos de un usuario. Opciones: -c -d -e -f Comentario sobre el usuario Directorio de conexion del usario Fecha en la cual la cuenta de usuario se desactiva D as que transcurrir an desde la caducidad de la contrase~ na hasta la desactivaci on de la cuenta -g Nombre o numero del grupo primario -G Lista de los grupos suplementarios del usuario (separados por ,) (sin espacios) -l Modifica el nombre de conexion del usuario -L Bloquea la contrase~ na del usuario -m Crea el directorio de conexion Si no se especifica la opci on -k, copia al directorio de conexion los ficheros del directorio /etc/skel -p Asigna una contrase~ na cifrada al usuario -s Asigna el shell a utilizar por el usuario -u Asigna un UID concreto al usuario -o Permite crear un UID duplicado con la opcion -u -U Desbloquea la contrase~ na del usuario --------------------------------------------------------------------------groupadd groupadd [-g gid [-o]] [-r] group Crea un grupo de usuarios. Opciones: -g Asigna un GID concreto al grupo -o Permite crear un GID duplicado con la opcion -g -r Crea una cuenta de grupo del sistema --------------------------------------------------------------------------groupmod groupmod [-g gid [-o]] [-n name] group c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados 23 Modifica los atributos de un grupo de usuarios. Opciones: -g Asigna un GID concreto al grupo -o Permite crear un GID duplicado con la opcion -g -n Cambia el nombre del grupo --------------------------------------------------------------------------groupdel groupdel group Elimina un grupo de usuarios. No tiene opciones. --------------------------------------------------------------------------passwd passwd [-l] [-u [-f]] [-d] [-S] [ username ] Modifica la contrase~na y el estado de la cuenta un usuario. Opciones: -d -f -l -S -u Elimina la contrase~na del usuario Fuerza el desbloqueo Bloquea la cuenta del usuario Informa sobre el estado de la cuenta de un usuario Desbloquea la cuenta del usuario Sin argumentos modifica la contrase~na del usuario que lo invoca. Si se especifica un nombre de usuario y no se especifican opciones, modifica la contrase~na del usuario indicado --------------------------------------------------------------------------chage chage [ -l ] [ -m min_days ] [ -M max_days ] [ -W warn ] [ -I inactive ] [ -E expire ] [ -d last_day ] user Modifica la informaci on de caducidad de la contrase~ na de un usuario. Opciones: -d -E -l -I Asigna la fecha del ultimo cambio de contrase~na Asigna la fecha en la cual la cuenta de usuario ser a desactivada Muestra la informacion de caducidad N umero de d as tras los cuales la cuenta sera desactivada si no se realiza el cambio de contrase~na exigido -m N umero de d as mnimo permitido entre cambios de contrase~na -M N umero de d as maximo permitido entre cambios de contrase~na -W N umero de d as previos al proximo cambio de contrase~ na exigido Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 24 Usuarios y Proteccion en Linux --------------------------------------------------------------------------chown chwon [ -R ] owner file Modifica el usuario propietario de un fichero o directorio. Opciones: -R Realiza la modificacion en todo el contenido del directorio --------------------------------------------------------------------------chgrp chgrp [ -R ] group file Modifica el grupo propietario de un fichero o directorio. Opciones: -R Realiza la modificacion en todo el contenido del directorio --------------------------------------------------------------------------chmod chmod -R MODE[,MODE]... FILE... chmod -R OCTAL_MODE FILE... Modifica los bits de permiso de un fichero o directorio. Opciones: -R Realiza la modificacion en todo el contenido del directorio MODE indica como deben modificarse los bits de permiso. Su sintaxis es: [ugoa][+-=][rwxXstugo] [ugoa] u propietario g grupo o otros [+-=] + a~nadir - eliminar = hacer igual a todos [rwxXstugo] r lectura w escritura x ejecucion X ejecucion si activo para el propietario s SETUID o SETGID t sticky u igual al propietario g igual al grupo o igual a otros --------------------------------------------------------------------------- c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Cap tulo 4 Usuarios y Proteccion en Windows NT Indice General 4.1 4.2 4.3 4.4 4.5 Conceptos de Usuario y de Cuenta de Usuario . . . . Grupos de Usuarios . . . . . . . . . . . . . . . . . . . . Permisos y Derechos (o Privilegios) . . . . . . . . . . Asignacion de Permisos a Archivos y Directorios . . Mandatos NT para la creacion de usuarios y grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26 28 30 33 4.1 Conceptos de Usuario y de Cuenta de Usuario Como muchos otros sistemas operativos, Windows NT permite tener un riguroso control de que personas pueden entrar en el sistema para trabajar en el, y de que forma pueden llevar a cabo dicho trabajo. Windows NT denomina usuario a cada persona que puede entrar en el sistema, y para poder controlar su entrada y sus acciones, utiliza basicamente el concepto de cuenta de usuario (user account). Una cuenta de usuario almacena toda la informacion que el sistema guarda acerca de cada usuario, es decir, es la imagen que el sistema tiene de el. Cada usuario ha de tener necesariamente una cuenta, y as el sistema puede distinguir unvocamente a dicho usuario del resto. En Windows NT son numerosos los datos que el sistema almacena en cada cuenta de usuario, y entre ellos los mas importantes son los siguientes: 25 26 Usuarios y Proteccion en Windows NT a) Nombre de usuario. Es el nombre mediante el cual el usuario puede entrar en el sistema. Cada usuario ha de tener un nombre de usuario distinto. b) Nombre completo. Es el nombre completo del usuario. c) Contrase~na. Palabra cifrada que permite autenticar el nombre de usuario. En Windows NT la contrase~na distingue entre mayusculas y minusculas. d) Directorio de conexion. Es el lugar donde (en principio) residiran los archivos personales del usuario. El directorio de conexion de cada usuario es privado: ningun otro usuario puede entrar en el, a menos que su propietario conceda los permisos adecuados. e) Horas de conexion. Se puede controlar a que horas un usuario puede conectarse para trabajar en el sistema. Inclusive se puede especicar un horario distinto para cada da de la semana. f) Activada. Esta caracterstica permite inhabilitar temporalmente una cuenta. Una cuenta desactivada sigue existiendo, pero no puede ser utilizada para acceder al sistema, ni siquiera conociendo su contrase~na. Existe un dato especial que se asocia a cada cuenta, pero que a diferencia de todos los expuestos arriba, no puede ser especicado manualmente cuando se da de alta la cuenta. Se trata del identicador seguro (Secure Identier, o SID). Este identicador es interno y el sistema lo genera automaticamente cuando se crea una nueva cuenta. NT utiliza el SID (y no el nombre de usuario) en cada accion realizada por el usuario, para controlar si este tiene o no permisos sucientes para llevarla a cabo. Ningun usuario (ni siquiera el administrador) puede conocer el SID de ninguna cuenta, y precisamente en este hecho radica su utilidad: nadie puede obtener un mayor grado de privilegio intentando suplantar la identidad de otro usuario. Cuando en un equipo se instala Windows NT, existen de entrada las cuentas de dos usuarios preinstalados (built-in users): el Administrador y el Invitado. El primero es un usuario especial, el unico que en principio posee lo que se denominan derechos administrativos en el sistema. Es decir, tiene la potestad de administrar el sistema en todos aquellos aspectos en que este es congurable: usuarios, grupos de usuarios, contrase~nas, recursos, derechos, etc. La cuenta de Administrador no puede ser borrada ni desactivada. Por su parte, la cuenta de Invitado es la que utilizan normalmente aquellas personas que no tienen un usuario propio para acceder al sistema. Habitualmente esta cuenta no tiene contrase~na asignada, puesto que se supone que el nivel de privilegios asociado a ella es mnimo. En cualquier caso, el Administrador puede desactivarla si lo considera oportuno. 4.2 Grupos de Usuarios La informacion de seguridad almacenada en una cuenta de usuario es suciente para establecer el grado libertad (o de otro modo, las restricciones) que cada usuario debe c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 27 4.2 Grupos de Usuarios poseer en el sistema. Sin embargo, resultara muchas veces tedioso para el administrador determinar dichas restricciones usuario por usuario, especialmente en sistemas con un elevado numero de ellos. El concepto de grupo de usuarios permite agrupar de forma logica a los usuarios de un sistema, y establecer permisos y restricciones a todo el grupo de una vez. Un usuario puede pertenecer a tantos grupos como sea necesario, poseyendo implcitamente la suma de los permisos de todos ellos. Esta forma de administrar la seguridad, que se detallara en el apartado 4.4, es mucho mas exible y potente que el establecimiento de permisos en base a usuarios individuales. Considerese, por ejemplo, que en una empresa un sistema es utilizado por empleados de distinto rango, y que cada rango posee un distinto nivel de privilegios. Supongamos que se desea cambiar de rango a un empleado, debido a un ascenso, por ejemplo. Si la seguridad estuviera basada en usuarios individuales, cambiar los privilegios de este usuario adecuadamente supondra modicar sus privilegios en cada lugar del sistema en que estos debieran cambiar (con el consiguiente trabajo, y el riesgo de olvidar alguno). Por el contrario, con la administracion de seguridad basada en grupos, esta operacion sera tan sencilla como cambiar al usuario de un grupo a otro. Por ello: En Windows NT, se recomienda que los permisos se asignen en base a grupos locales, y no en base a usuarios individuales. Al igual que existen cuentas preinstaladas, en todo sistema NT existen una serie de grupos preinstalados (built-in groups): Administradores, Operadores de Copia, Usuarios Avanzados, Usuarios, e Invitados. El grupo Administradores recoge a todos aquellos usuarios que deban poseer derechos administrativos completos. Inicialmente posee un solo usuario, el Administrador. De igual forma, el grupo Invitados posee al Invitado como unico miembro. Los otros tres grupos estan vacos inicialmente. Su uso es el siguiente: a) Usuarios. Son los usuarios normales del sistema. Tienen permisos para conectarse al sistema interactivamente y a traves de la red. b) Operadores de copia. Estos usuarios pueden hacer (y restaurar) una copia de todo el sistema. c) Usuarios avanzados. Son usuarios con una cierta capacidad administrativa. Se les permite cambiar la hora del sistema, crear cuentas de usuario y grupos, compartir cheros e impresoras, etc. El Administrador, al ir creando las cuentas de los usuarios, puede hacer que cada una pertenezca al grupo (o grupos) que estime conveniente. Asimismo, puede crear nuevos grupos que renen esta estructura inicial, conforme a las necesidades particulares de la organizacion donde se ubique el sistema. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 28 Usuarios y Proteccion en Windows NT 4.3 Permisos y Derechos (o Privilegios) La seguridad en NT se estructura a dos grandes niveles: por una parte, debe establecerse quien puede trabajar en el sistema, y para ello se utilizan los conceptos de cuenta de usuario y de grupo de usuarios. Por otra parte, debe establecerse que puede hacer cada usuario/grupo. Para esto ultimo existen, a su vez, dos conceptos complementarios: los permisos y los derechos. Un permiso (permission) es una caracterstica de cada objeto del sistema, que concede o deniega el acceso al mismo a un usuario/grupo concreto. En este contexto se puede asimilar el concepto de objeto al de recurso (normalmente, un archivo, directorio o impresora). Cada recurso del sistema posee una lista en la que se establece que usuarios/grupos pueden acceder a dicho recurso, y tambien que tipo de acceso puede hacer cada uno (lectura, modicacion, ejecucion, borrado, etc.). En el apartado 4.4 se profundiza mas acerca de los permisos que pueden asignarse a recursos en NT, concretamente a los archivos. Por su parte, un derecho o privilegio de usuario (user right) es una regla de proteccion establecida sobre una accion que afecta al sistema en su conjunto (y no a un objeto en concreto). Existe un conjunto jo y predenido de derechos, no pudiendose denir mas. Para determinar que usuarios poseen que derechos, cada derecho posee una lista donde se especican los grupos/usuarios que tienen concedido este derecho. Es preferible que, por los motivos que se exponen en el apartado anterior, los derechos sean concedidos a grupos en vez de a usuarios concretos (pero esto ultimo es tambien posible si resulta necesario). A continuacion se exponen algunos derechos existentes en NT que merecen una especial atencion: a) Inicio de sesion local. Permite a un usuario iniciar una sesion interactiva en el sistema. b) Acceder a este equipo desde la red. Un usuario con este derecho puede conec- tarse al equipo desde otro equipo en la red, y observar que recursos comparte. Este derecho no garantiza el poder utilizar dichos recursos, y debe complementarse con los permisos asociados a dichos recursos. c) Tomar posesion de cheros. Cuando un usuario posee este derecho, puede tomar posesion de cualquier archivo en el sistema. Tomar posesion implica pasar a ser el propietario, y por tanto, tener control total sobre el mismo. d) Apagar el sistema. Permite a un usuario apagar el equipo. La concesion de derechos a los grupos preinstalados, tal como existe al instalar NT, puede verse en la Tabla 4.1. Por otra parte, los distintos grupos poseen una serie de habilidades preinstaladas (built-in abilities), que junto con sus derechos constituyen su nivel de privilegios. La Tabla 4.1 muestra tambien las habilidades que posee cada grupo. Posteriormente, el administrador, a su criterio, puede conceder o denegar cada derecho a un grupo (o usuario) concreto, simplemente a~nadiendolo o eliminandolo de la lista asociada a ese derecho. Las habilidades asociadas a cada grupo no pueden modicarse. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 29 4.3 Permisos y Derechos (o Privilegios) Derecho Inicio de sesion local Acceder a este equipo desde la red Tomar posesion de cheros Cambiar el tiempo del sistema Apagar el sistema Apagar el sistema desde la red Hacer copias de seguridad Restaurar copias de seguridad Instalar manejadores de dispositivo Habilidad Preinstalada Crear y administrar cuentas de usuario Crear y administrar grupos locales Asignar derechos de usuario Bloquear la estacion Desbloquear la estacion Formatear el disco duro Compartir (y dejar de compartir) directorios Compartir (y dejar de compartir) impresoras Admin. Usu.Av. Usu. Inv. Op.Copia Todos p p p p p p p p p p p p p p p p p p p p p p p p Admin. Usu.Av. Usu. Inv. Op.Copia Todos p p p p p p p p p p p p p p p Tabla 4.1: Derechos iniciales y habilidades preinstaladas de los distintos grupos en Windows NT. Las abreviaturas corresponden a los siguientes grupos: Admin.=Administradores, Usu.Av.=Usuarios Avanzados, Usu.=Usuarios, Inv.=Invitados, y Op.Copia=Operadores de copia. Es importante hacer notar lo siguiente: cuando existe un conicto entre lo que concede un permiso y lo que concede un derecho, este ultimo tiene prioridad. Por ejemplo: los miembros del grupo Operadores de Copia poseen el derecho de realizar una copia de seguridad de todos los archivos del sistema. Es posible (y muy probable) que existan archivos sobre los que no tengan ningun tipo de permiso. Sin embargo, al ser el derecho mas prioritario, podran realizar la copia sin problemas. De igual forma, el administrador tiene el derecho de tomar posesion de cualquier archivo, inclusive de aquellos archivos sobre los que no tenga ningun permiso. Es decir: Los derechos o privilegios siempre prevalecen ante los permisos particulares de un objeto, en caso de conicto. Finalmente, existe en NT una serie de grupos especiales, cuyos (usuarios) miembros Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 30 Usuarios y Proteccion en Windows NT no se establecen de forma manual, sino que son determinados de forma automatica por el sistema. Estos grupos se utilizan normalmente para facilitar la labor de conceder permisos y derechos. De entre estos grupos, destacan: a) Usuarios Interactivos (Interactive). Este grupo representa a todos aquellos usuarios que tienen el derecho de iniciar una sesion local en la maquina. b) Usuarios de Red (Network). Bajo este nombre se agrupa a todos aquellos usuarios que tienen el derecho de acceder al equipo desde la red. c) Todos (Everyone). Agrupa a todos los usuarios que el sistema conoce. Puede agrupar a usuarios existentes localmente y de otros sistemas (conectados a traves de la red). Esto se expondra de forma mas rigurosa cuando se vean los dominios de NT, en el Captulo 5. 4.4 Asignacion de Permisos a Archivos y Directorios En primer lugar, es importante resaltar que en un sistema NT solo es posible establecer permisos a archivos y directorios que residan en una particion de tipo NTFS (NT File System), y no en una particion de tipo FAT (File Allocation Table). Los permisos que se pueden asignar a un archivo o directorio en una particion NTFS son combinaciones sobre seis permisos individuales, que se presentan a continuacion: 1) Lectura (Read, R). Permite abrir un archivo o directorio para consultar su contenido. 2) Escritura (Write, W). En el caso de un archivo, permite modicar su contenido. En el caso de un directorio, permite crear nuevos archivos (o directorios) dentro del mismo. 3) Ejecucion (Execution, X). Permite la ejecucion de un archivo. 4) Borrado (Delete, D). Permite el borrado de un archivo o directorio. 5) Cambiar los permisos (Change Permissions, P). Permite la accion de cambiar los permisos que actualmente posee un archivo o directorio. 6) Tomar posesion (Take Ownership, O). En NTFS, todo archivo o directorio tiene un propietario. Si un usuario no es el propietario de un archivo o directorio, pero posee este permiso sobre el, podra realizar una accion especial, denominada tomar posesion, que lo convertira automaticamente en su (nuevo) propietario. Consecuentemente, podra hacer con dicho archivo lo que desee, puesto que el propietario de un archivo siempre puede cambiar sus permisos. Normalmente, los permisos que se asignan a los archivos o directorios no son estos permisos individuales. En vez de eso, existe tambien una serie de permisos estandar, c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 31 4.4 Asignacion de Permisos a Archivos y Directorios que son combinaciones predenidas de estos permisos individuales, con un signicado bien denido. A continuacion se muestran los permisos estandar para directorios y para archivos. Nombre Permisos Directorio Permisos Archivos Signicado Sin acceso (Ninguno) (Ninguno) Lectura (RX) (RX) A~nadir (WX) (Sin determinar) A~nadir y leer (RWX) (RX) Cambio (RWXD) (RWXD) Control total (Todos) (Todos) El usuario no puede acceder al directorio de ninguna manera, aunque sea miembro de un grupo que tenga algun tipo de acceso al mismo. El usuario puede leer el contenido de archivos y ejecutar archivos ejecutables que haya en el directorio. El usuario puede a~nadir archivos al directorio, pero no puede leer el contenido de ningun archivo, ni siquiera del propio directorio. El usuario puede a~nadir nuevos cheros y leer el contenido de cualquier chero, pero no puede modicarlos. El usuario puede crear archivos nuevos, y leer y modicar cualquier archivo del directorio. El usuario tiene control total sobre el directorio y sobre todos sus archivos, as como los que se creen en el futuro. Tabla 4.2: Permisos estandar sobre directorios en Windows NT En la Tabla 4.2 guran los permisos estandar que se pueden establecer en los directorios. Cada la describe un permiso estandar, indicando su nombre y las dos listas de permisos individuales que lo denen: la primera es la lista de los permisos del propio directorio y la segunda es la lista de permisos iniciales con la que se crearan los nuevos archivos en ese directorio. De esta forma, cuando en un directorio padre se crea un nuevo archivo/directorio hijo, se aplican las siguientes reglas: Si el hijo es un archivo regular (no directorio), este se crea con los permisos especi- cados la segunda lista de permisos individuales del directorio padre. El permiso sin determinar signica ausencia de permisos. Si el hijo es un directorio, este se crea con las dos listas de permisos individuales del padre. En ambos casos, esta especie de herencia s olo tiene lugar en el momento de la creacion del archivo/directorio hijo (es decir, es una copia instantanea de permisos). A partir Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 32 Usuarios y Proteccion en Windows NT de ese momento, los permisos de padre e hijo se gestionan de forma completamente independiente. Los permisos estandar que se pueden establecer sobre un archivo individual se muestran en la Tabla 4.3. Por otra parte, cuando se desea establecer los permisos de un directorio o archivo, NT muestra, ademas de las listas que guran en ambas tablas, una opcion denominada Acceso Especial. Esta opcion permite denir la lista de permisos individuales que se desea aplicar a un archivo, o las dos listas que se desea aplicar sobre un directorio. De esta forma, se puede llegar a una granularidad na en las ocasiones que sea necesario. Nombre Permisos Signicado Sin acceso (Ninguno) Lectura (RX) Cambio (RWXD) Control Total (Todos) El usuario no puede acceder chero de ninguna manera, aunque sea miembro de un grupo que tenga algun tipo de acceso al mismo. El usuario puede leer el contenido del chero, y ejecutarlo si es un archivo ejecutable. No puede modicarlo ni borrarlo. El usuario puede leer, ejecutar, modicar y borrar el archivo. El usuario tiene el control total sobre el archivo. Tabla 4.3: Permisos estandar sobre archivos en Windows NT Ademas de poder establecer los permisos citados sobre cualquier archivo o directorio (sobre el que podamos hacerlo, evidentemente), es importante tener en mente las siguientes reglas: Los usuarios pueden acceder de una determinada manera a un archivo o directorio solo si tienen concedido el permiso correspondiente, bien de forma individual, bien perteneciendo a un grupo que posea dicho permiso. Los permisos son acumulativos, es decir, si un usuario pertenece a varios grupos, que tienen distintos permisos sobre algun archivo o directorio, dicho usuario obtendra la suma de todos ellos. Sin embargo, si para algun grupo (o para el personalmente) se establece el permiso Sin Acceso, este ultimo tiene prioridad, y no podra acceder de ninguna manera al archivo. En otras palabras, el permiso Sin Acceso es un permiso negativo, que tiene prioridad sobre el resto. Todo nuevo archivo recibe como permisos iniciales los que en ese momento posea su directorio padre. El archivo recibira una o dos listas de permisos en funcion de si es un archivo regular o un directorio. A partir del momento de la creacion de un archivo, la gestion de permisos del nue- vo archivo y del directorio donde se ha creado se realiza de forma completamente independiente. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 33 4.5 Mandatos NT para la creacion de usuarios y grupos Cuando un usuario crea un archivo o directorio, se convierte en el propietario del mismo. El propietario de un archivo siempre puede cambiar los permisos del archivo. Un usuario puede tomar posesi on de un archivo o directorio (que no sea suyo ya) siempre que tenga Control Total sobre dicho archivo (o bien el permiso individual O). Los miembros del grupo de Administradores tienen el derecho de tomar posesion de cualquier archivo del sistema. En realidad el concepto de objeto como entidad que posee permisos es mas amplio (tambien son objetos los procesos, los semaforos, los hilos de ejecucion, etc.). 4.5 Mandatos NT para la creacion de usuarios y grupos La creacion de usuarios y grupos en Windows NT puede realizarse utilizando los mandatos net user y net group. La sintaxis de ambos mandatos es la siguiente: Mandato net user Agrega o modica cuentas de usuario o muestra informacion acerca de ellas. net user [nombre_usuario [contrase~na | *] [opciones]] [/domain] net user nombre_usuario {contrase~na | *} /add [opciones] [/domain] net user nombre_usuario [/delete] [/domain] opciones: /active:{no | yes} /comment:"texto" /countrycode:nnn /expires:{fecha | never} /fullname:"nombre" /homedir:ruta_acceso /homedirreq:{yes | no} /passwordchg:{yes | no} /passwordreq:{yes | no} /profilepath[:ruta_acceso] /scriptpath:ruta_acceso /times:{horas | all} /usercomment:"texto" /workstations:{nombre_equipo [,...] | *} Mandato net group Agrega, muestra o modica grupos. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 34 Usuarios y Proteccion en Windows NT net group [nombre_grupo [/comment:"texto"]] [/domain] net group nombre_grupo {/add [/comment:"texto"] | /delete} [/domain] net group nombre_grupo nombre_usuario[...] {/add | /delete} [/domain] c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Cap tulo 5 Dominios en Windows NT Indice General 5.1 5.2 5.3 5.4 5.5 5.6 Concepto de Dominio . . . . . . . . . . . . . . . Usuarios y Grupos en un Domino . . . . . . . Ordenadores Miembros de un Dominio . . . . Comparticion de Recursos entre Sistemas NT Conanzas entre Dominios NT . . . . . . . . . Mandatos NT para compartir recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 37 39 39 41 43 5.1 Concepto de Dominio Hoy en da, los ordenadores existentes en cualquier organizacion se encuentran muy frecuentemente formando parte de redes de ordenadores. En una red, los ordenadores se encuentran interconectados, de forma que pueden intercambiar informacion. No es necesario que un ordenador con Windows NT participe de una red. Sin embargo, si desea hacerlo, tiene que ser de alguna de las dos formas siguientes: a) En un grupo de trabajo (workgroup). Un grupo de trabajo es una agrupacion logica de maquinas, sin ningun otro n. Los ordenadores que forman parte del mismo grupo aparecen juntos cuando se explora el Entorno de Red. La administracion de cada ordenador es local e independiente del resto. Para poder acceder a los recursos que exporta un ordenador concreto, el usuario remoto tiene que disponer necesariamente de una cuenta en dicho ordenador, y permisos sucientes sobre el recurso que se comparte. 35 36 Dominios en Windows NT b) Formando parte de un dominio (domain). Es la forma en que se recomienda que se dena una red de maquinas NT. En un dominio, la informacion administrativa se encuentra centralizada, y por ello resulta mas facil y segura de gestionar. Todo este tema se centrara en denir y exponer los conceptos relacionados con los dominios en NT. Mas formalmente: Se puede denir dominio como una agrupacion logica de servidores de red y otros ordenadores, que comparten informacion comun sobre cuentas (de usuarios, grupos, etc.) y seguridad. Es importante matizar que el termino dominio no incluye ninguna informacion acerca de la ubicacion de las maquinas. No es necesario que se encuentren fsicamente cercanas, ni que esten interconectadas mediante una red de algun tipo especco. De hecho, las maquinas que forman un dominio pueden estar conectadas a traves de una red de area amplia o WAN (Wide Area Network), aunque lo mas normal es que formen una red de area local o LAN (Local Area Network). Precisamente en el ambito de las redes de sistemas NT cobra sentido el hecho de que existan dos versiones de este sistema operativo: NT server y NT workstation. Habitualmente, un NT server (o servidor NT) tiene un papel especial en una red NT, y se utiliza para proporcionar servicios centralizados de red en un dominio NT. Por su parte, un NT workstation (o estacion NT) es una maquina que, aunque puede formar parte de un dominio, no proporciona ningun servicio al resto de maquinas, siendo una estacion de trabajo de proposito general. Concretamente, en un domino NT: Existe necesariamente un servidor NT con funciones de Controlador Principal de Dominio (Primary Domain Controller, o PDC). Este servidor posee toda la informacion centralizada sobre cuentas de usuarios y grupos del domino, as como la informacion acerca de que maquinas pertenecen al mismo. Pueden existir uno o varios servidores NT con funciones de Controladores de Copia de Dominio (Backup Domain Controller, o BDC). Si existen, conservan una copia de la informacion de cuentas y seguridad del PDC, y regularmente se reenvan copias actualizadas de las mismas. Cualquier peticion de informacion por parte de un ordenador (cliente) puede ser contestada por el PDC o por uno de los BDCs indistintamente. Por otra parte, si el PDC deja de estar disponible de forma permanente, cualquiera de los BCDs puede promocionarse a PDC mediante una sencilla accion por parte del administrador. Pueden existir uno o varios servidores NT sin funciones especiales de administraci on dentro del dominio. A estos ordenadores se les llama servidores miembro (Member Servers). Habitualmente estas maquinas s proporcionan algun servicio especco c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 37 5.2 Usuarios y Grupos en un Domino dentro del dominio (servicios de impresion, servicios de acceso a datos, etc.), pero no guardan ninguna informacion administrativa. Pueden existir una o varias estaciones NT, que se utilizar an para trabajo habitual. Tanto los servidores miembro como las estaciones NT son clientes del PDC (y BDCs) respecto a la informacion relativa a usuarios, grupos, contrase~nas y autenticacion, etc. 5.2 Usuarios y Grupos en un Domino En el Captulo 4 se ha visto como en NT pueden crearse cuentas de usuarios y grupos, y como se utilizan ambos para controlar el acceso de las personas a un sistema NT, y para administrar los derechos y permisos que estas poseen en dicho sistema. Por lo tanto, si una persona tiene que trabajar en varios sistemas, debe poseer una cuenta de usuario en cada uno. En un dominio, el servidor NT que actua de PDC puede crear usuarios y grupos especiales, denominados usuarios globales y grupos globales. En este caso, el termino global se interpreta como global al dominio. Esto quiere decir que un usuario global existe en todos los ordenadores pertenecientes al dominio, poseyendo no una cuenta en cada maquina, sino una cuenta unica para todas ellas, y por lo tanto un unico SID. Las cuentas de los usuarios globales residen solo en el PDC, habiendo copias en todos los BDCs. Por este motivo: Cuando una persona se conecta a cualquier ordenador miembro de un dominio utilizando para ello una cuenta de usuario global, dicho ordenador contacta con el PDC (o BDCs) del domino para que este ultimo valide la cuenta y la contrase~na. El resultado de esta validacion es enviado al ordenador miembro, y de este al usuario (concediendo o rechazando la conexion). Un ordenador miembro de un dominio (una estacion NT, por ejemplo), ademas de poder ver a los usuarios globales del dominio, puede crear tambien sus propios usuarios locales, que son unicamente visibles en dicho ordenador. Cuando una persona desea entrar en el sistema utilizando una cuenta local, dicha cuenta se valida contra la base de datos local de ese ordenador. Ademas, es importante notar que a dicho usuario local no se le pueden asignar permisos sobre recursos que residan en otro sistema NT (puesto que all no existe). Por el contrario, a un usuario global se le pueden conceder permisos sobre cualquier recurso (archivo, directorio, impresora, etc.) de cualquier ordenador miembro del dominio, puesto que es visible (y posee el mismo SID) en todos ellos. De forma analoga a los usuarios globales, los grupos globales existentes en un PDC son visibles en todos los miembros del dominio. Todo usuario global pertenece a (al menos) un grupo global. Los mas importantes grupos globales preinstalados en un PDC son los siguientes: Administradores, Operadores de Copia, Operadores de Cuentas, Operadores Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 38 Dominios en Windows NT de Impresion, Usuarios e Invitados. Inicialmente, el grupo de Administradores lo forma la cuenta global Administrador (del dominio), as como el grupo de Invitados lo forma la cuenta de Invitado. Los distintos grupos de Operadores pueden considerarse como administradores con funciones mas especcas (quedando otras fuera de su alcance). La cuenta de Usuarios (del dominio) es a la que pertenecen por defecto los nuevos usuarios globales que se crean en un PDC. En un ordenador miembro de un dominio tambien se pueden denir grupos locales. Existen importantes diferencias entre los grupos locales de un miembro y los grupos globales de un dominio. La Tabla 5.1 recoge las principales diferencias. Un grupo global. . . Un grupo local. . . Existe en todos los miembros de un dominio. Existe en el ordenador donde ha sido creado. Solo puede poseer usuarios globales. Puede poseer usuarios y grupos globales, y usuarios locales. No puede poseer otros grupos locales. Puede utilizase para concederle (o denegarle) permisos sobre recursos (archivos) en cualquier miembro del dominio Puede utilizase para concederle (o denegarle) permisos sobre recursos (archivos) solo en el ordenador donde esta denido. Se utiliza normalmente para a~nadir usuarios al dominio, agrupandolos en funcion del trabajo que realizan. Se utiliza normalmente para asignar a usuarios y grupos globales los derechos de cada ordenador miembro, as como los permisos sobre los recursos que residen en dicho ordenador. Tabla 5.1: Diferencias entre grupos globales y locales en Windows NT Tal como pone de maniesto la tabla anterior, en cada ordenador (miembro) se puede seguir estableciendo la seguridad como se expona en el Captulo 4, es decir, en base a grupos locales. De hecho, sigue siendo valida la recomendacion de que la concesion de derechos y la asignacion de permisos sobre los objetos/recursos del sistema se haga en base a grupos locales. La diferencia cuando existe un dominio es que en estos grupos locales, el administrador puede incluir tanto usuarios locales como grupos y usuarios globales del dominio. En relacion con esto, es importante saber que cuando un ordenador pasa a ser miembro de un dominio (existente), el grupo global Administradores se incluye automaticamente en el grupo local Administradores de dicho ordenador. De igual forma, el grupo global Usuarios se incluye dentro del grupo local Usuarios. De esta forma, los administradores y usuarios normales del dominio tienen en cada miembro los mismos derechos y permisos que los que tengan ya denidos los administradores y usuarios locales, respectivamente. El administrador local puede, si lo desea, invalidar esta accion automatica, extrayendo posteriormente los grupos globales de los locales. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 39 5.3 Ordenadores Miembros de un Dominio 5.3 Ordenadores Miembros de un Dominio Como hemos visto, en el PDC se conserva toda la informacion relativa a cuentas de usuarios y grupos globales. En concreto, esta informacion se guarda en la denominada Security Account Manager (SAM) database, o base de datos del Gestor de Cuentas de Seguridad. Esta misma base de datos recoge tambien una cuenta de ordenador por cada uno de los ordenadores miembro de un dominio. Entre otras informaciones, en cada una de estas cuentas se almacena el nombre del ordenador, as como un identicador unico y privado que lo identica unvocamente. Este identicador es analogo al SID de cada cuenta de usuario, y solo lo conocen el PDC y el propio ordenador miembro. Es por tanto, un dato interno del sistema operativo, y ni siquiera el administrador puede consultarlo. Mediante este identicador privado a ambos se establece lo que se conoce como un canal de comunicacion seguro (secure communication channel) cada vez que un ordenador miembro y el PDC necesitan comunicarse. Un ejemplo de dicha comunicacion sera la autenticacion de una cuenta de usuario global que desea conectarse a un ordenador miembro. Este canal se considera seguro puesto que se alcanza mediante una negociacion en la que el ordenador miembro utiliza su identicador privado, con lo que no puede ser suplantado por otra maquina. Los canales de comunicacion seguros se utilizan para: Administrar remotamente los recursos de un ordenador miembro desde cualquier otro (incluso del PDC desde una estacion NT). Para ello, el usuario debe tener los derechos y permisos sucientes en la maquina remota. Autenticar usuarios, como se expone arriba. Validar las relaciones de conanza entre dominios, que se explican mas adelante. Y, en general, siempre que informaci on relativa a aspectos de seguridad se intercam- bia entre maquinas NT pertenecientes a algun dominio. 5.4 Comparticion de Recursos entre Sistemas NT Cuando un sistema NT participa en una red de ordenadores (grupo de trabajo o dominio), puede compartir sus recursos con el resto de ordenadores. En este contexto, solo vamos a considerar como recurso a compartir los directorios que existen en un sistema NT1 . Cualquier sistema NT puede compartir directorios, tanto si es un servidor como si es una estacion de trabajo. Para poder compartir un directorio, basta con desplegar su menu contextual desde una ventana o desde el explorador de archivos, y seleccionar 1 La comparticion de otros recursos (tales como impresoras, por ejemplo) queda fuera del ambito del presente captulo. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 40 Dominios en Windows NT Compartir.... En la ventana asociada a esta opcion se determina el nombre que tendra el recurso (que no tiene por que coincidir con el nombre del directorio), as como que usuarios van a poder acceder al mismo. En relacion con esto, existe una gran diferencia entre que el directorio resida en una particion FAT y que resida en una NTFS. Si el directorio reside en una particion FAT, este ltro de acceso sera el unico que determine los usuarios que van a poder acceder al contenido del directorio, puesto que no es posible determinar permisos sobre el propio directorio o sus archivos. Es decir, el ltro solo se establece para poder acceder al recurso. Si un usuario tiene permisos sucientes para conectarse a un recurso, tendra acceso sobre todos los archivos y subdirectorios del recurso. El tipo de acceso sobre todos ellos sera el que le permita el permiso sobre el recurso (Lectura, Escritura, Control Total, etc.). Por el contrario, si el directorio se encuentra en una particion NTFS, este tendra unos permisos establecidos (as como sus subdirectorios y archivos), al margen de ser un directorio compartido. En este ultimo caso tambien es posible establecer un ltro desde la ventana de Compartir..., pero entonces solo los usuarios que puedan pasar ambos ltros podran acceder al directorio compartido. En este caso se recomienda lo siguiente: Cuando se comparte un directorio que reside en una particion NTFS, se recomienda dejar Control Total sobre Todos en los permisos asociados al recurso (opcion por defecto), y controlar quien (y como) puede acceder al recurso y a su contenido mediante los permisos asociados a dicho directorio y a sus archivos y subdirectorios. Esta recomendacion es muy util, si tenemos en cuenta que de esta forma para cada directorio (y archivo) del sistema no utilizamos dos grupos de permisos sino uno solo, independientemente de que el directorio sea o no compartido. Este forma de trabajar obliga al administrador a asociar los permisos correctos a cada objeto del sistema (aunque no este compartido), pero por otra parte se unica la vision de la seguridad de los archivos, con lo que a la larga resulta mas segura y mas sencilla. Ademas, hay que tener en cuenta lo siguiente: Si un usuario ha iniciado una sesion interactiva en un ordenador NT denominado A, y desea conectarse a un recurso de red que exporta otro ordenador NT denominado B, ademas de poseer los permisos sucientes sobre el recurso, sobre el propio directorio y sobre su contenido, tiene que tener concedido en B el derecho de acceder a este equipo desde la red. Por ultimo, cuando un sistema NT forma parte de un dominio, al margen de los recursos que el administrador desee compartir, se comparten por defecto otros recursos para usos del propio sistema y administrativos. Estos recursos no deben modicarse ni prohibirse: a) (letra de unidad)$. Por cada particion existente en un sistema NT (C:, D:, etc.) se crea un recurso compartido denominado C$, D$, etc. Los administradores del c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 41 5.5 Conanzas entre Dominios NT dominio, as como los operadores de copia del domino, pueden conectarse por defecto a estas unidades. b) ADMIN$. Es un recurso utilizado por el propio sistema durante la administracion remota de un ordenador NT. c) IPC$. Recurso que agrupa los tubos (colas de mensajes) utilizados por los programas para comunicarse entre ellos. Se utiliza durante la administracion remota de un ordenador NT, y cuando se observa los recursos que comparte. d) NETLOGON. Recurso que exporta un servidor NT (normalmente un PDC) para proporcionar a los ordenadores miembros del dominio el servicio de validacion de cuentas globales a traves de la red (Net Logon service). En relacion con los nombres de estos recursos, es interesante saber que a~nadir el caracter '$' al nal de cualquier nombre de recurso tiene un efecto especco: prohibe que dicho recurso se visualice dentro de la lista de recursos que una maquina exporta al resto. Es decir, convierte un recurso en \invisible" para al resto del mundo. En este caso, un usuario remoto solo podra conectarse al recurso si conoce su nombre de antemano (y tiene sucientes permisos, obviamente). 5.5 Conanzas entre Dominios NT Una relacion de conanza (trust relationship) es una relacion que une a dos dominios NT, mediante la cual los usuarios (y grupos) globales de uno de ellos pueden utilizar los recursos que exporta el segundo. Mas formalmente: Cuando se establece una relacion de conanza entre dos dominios NT, los usuarios y grupos globales del dominio de conanza (trusted domain) son visibles en los ordenadores miembro del dominio que confa (trusting domain), y por tanto se les puede conceder permisos sobre los recursos este ultimo. En realidad, las relaciones de conanza entre dominios se establecen entre los PDCs de ambos, de forma que el PDC del dominio que confa valida usuarios en el PDC del dominio de conanza. Cuando existe una relacion de conanza entre dos dominios, los usuarios del dominio de conanza aparecen en las listas de usuarios conocidos en los ordenadores del dominio que confa, y en particular cuando se trata de conceder algun derecho o algun permiso. De acuerdo con esta vision, resulta evidente que siempre existe una relacion de conanza implcita entre todo miembro de un domino NT y su PDC. Las relaciones de conanza entre dominios son estables, siendo necesario establecerlas manualmente (mediante una contrase~na pactada entre los administradores de ambos dominios) y siguen vigentes hasta que se rompen explcitamente (por un administrador). Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 42 Dominios en Windows NT Otro aspecto importante de las relaciones de conanza es que siempre se establecen entre dos dominios, y por tanto no son relaciones recprocas ni transitivas. Si se desea que el dominio A confe en el dominio B y que B confe en A, es necesario establecer dos relaciones de conanza (recprocas). Y por otra parte, si A confa en B, y B confa en C, entonces no es cierto que A confe en C. Se va a ilustrar el concepto de conanzas mediante el ejemplo de la Figura 5.1. En el se muestran dos dominios denominados DominioA y DominioB. Cada dominio tiene un PDC y tres estaciones NT, con nombres ilustrativos. La relacion de conanza establecida entre ambos se representa mediante una echa de color gris oscuro, indicando que DominioA confa en DominioB (esta es la forma habitual de representar gracamente una relacion de conanza). De forma analoga, se representan mediante echas de color gris claro las relaciones de conanza implcitas entre cada estacion y su PDC. PDC_B PDC_A DominioB WksB1 DominioA WksB2 WksB3 WksA1 WksA2 WksA3 Figura 5.1: Ejemplo de relacion de conanza entre dominios NT. Siguiendo con el ejemplo, supongamos que en DominioA existe un usuario global denominado UsuA, y que en DominioB existe el usuario UsuB. Para evitar ambiguedades, NT establece que cuando se nombra a un usuario global de otro dominio se antepone el nombre del dicho dominio al del usuario, con lo que el usuario se denomina de la siguiente forma: dominionusuario. Por tanto, supongamos que existen DominioAnUsuA y DominioBnUsuB. En estas circunstancias, se van a plantear varias situaciones, indicando para cada una si es posible o no, y en su caso, las circunstancias necesarias para que se produzca: Si el usuario UsuB desea iniciar una sesi on interactiva en WksA1, podra hacerlo siem- pre que en dicho ordenador se le haya concedido el derecho de Inicio de sesion local (a el o a algun grupo al que pertenezca). Para validar la cuenta y su contrase~na, WksA1 preguntara a PDC A, y este, viendo que el usuario pertenece a DominioB (en el cual se confa) preguntara a su vez a PDC B. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 43 5.6 Mandatos NT para compartir recursos Si el usuario UsuB est a trabajando en WksB1, e intenta conectarse al recurso de red nnWksA2nProyectos, podr a hacerlo siempre que tenga permisos sucientes sobre el recurso (y sobre el directorio) en WksA2, y siempre que en dicho ordenador se le haya concedido el derecho Acceder a este equipo desde la red. Si el usuario UsuA desea iniciar una sesion interactiva en WksB1, no podr a hacerlo, ya que en este equipo no aparece como usuario. De igual forma, si el usuario UsuA esta trabajando en WksA2, e intenta conectarse al recurso de red nnWksB1nProyectos, no podra hacerlo, ya que no aparece como usuario, y no se le pueden conceder derechos o permisos. 5.6 Mandatos NT para compartir recursos La comparticion de recursos en Windows NT puede realizarse utilizando los mandatos net share y net use. La sintaxis de ambos mandatos es la siguiente: Mandato net share Crea, elimina o muestra recursos compartidos. net share net share recurso_compartido net share recurso_compartido=unidad:ruta_de_acceso [/users:numero | /unlimited] [/remark:"texto"] net share recurso_compartido [/users:numero | unlimited] [/remark:"texto"] net share {recurso_compartido | unidad:ruta_de_acceso} /delete Mandato net use Conecta o desconecta un equipo de un recurso compartido o muestra informacion acerca de las conexiones del equipo. Tambien controla las conexiones de red persistentes. net use [nombre_dispositivo] [\\nombre_equipo\recurso_compartido[\volumen]] [contrase~ na | *]] [/user:[nombre_dominio\]nombre_usuario] [[/delete] | [/persistent:{yes | no}]] net use nombre_dispositivo [/home[contrase~ na | *]] [/delete:{yes | no}] net use [/persistent:{yes | no}] Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Cap tulo 6 Niveles de ejecucion en Linux Indice General 6.1 Inicio y Detencion de un Sistema Linux . . . . . . . . . . . . . 6.2 El Concepto de Nivel de Ejecucion . . . . . . . . . . . . . . . . 6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Secuencia de Arranque de un Sistema Linux . . . . . . . . . . 6.5 Secuencia de Entrada en un Nivel de Ejecucion . . . . . . . . 6.6 Conguracion de los Niveles de Ejecucion . . . . . . . . . . . . . 45 . 45 . . . . 47 47 48 49 6.1 Inicio y Detencion de un Sistema Linux Un sistema Linux se inicia desde el cargador del sistema (habitualmente LILO) tecleando una simple etiqueta. Un sistema Linux debe detenerse de forma correcta, nunca apagando directamente el ordenador. Para ello se utiliza el mandato shutdown. Este mandato se emplea habitualmente en dos situaciones: a) shutdown -h now: detiene el sistema ahora. b) shutdown -r now: reinicia el sistema ahora. 6.2 El Concepto de Nivel de Ejecucion Linux esta programado para ejecutarse en un determinado nivel de ejecucion. El numero de niveles y sus nombre estan predeterminados. En cambio, las acciones a realizar en 45 46 Niveles de ejecucion en Linux cada nivel son congurables por el superusuario tal como se explica mas tarde en este documento. La conguracion de niveles en Redhat Linux se presenta en la Tabla 6.1 a continuacion. Nivel Nombre Descripcion 0 halt Este nivel detiene el sistema. 1 single user mode Modo de administracion. El sistema crea un shell con los privilegios del superusuario sin solicitar nombre de usuario o contrase~na. 2 multiuser Modo de funcionamiento normal sin algunos servicios de red. 3 multiuser + network Como el modo 2 pero con todos los servicios de red activos, NFS por ejemplo. 4 No utilizado por Redhat. 5 X11 El servidor X se inicia desde el primer momento. 6 reboot Se reinicia el sistema. emergency single user Igual al nivel 1 pero sin acceder a los cheros de conguracion de inicio. s,S Tabla 6.1: Niveles de ejecucion en RedHat Linux. Bajo esta perspectiva, un sistema Linux no se arranca o detiene, simplemente se cambia su nivel de ejecucion. Algunas consideraciones importantes sobre los niveles son: Durante un arranque normal, el sistema se coloca en el nivel 3 (multiusuario con red) o en el nivel 5 (analogo al 3 pero con el sistema de ventanas activo desde el inicio). shutdown -h now cambia el nivel actual al nivel 0, halt. shutdown -r now cambia el nivel actual al nivel 6, reboot. /sbin/telinit cambia al nivel especicado. /sbin/runlevel indica el nivel de ejecuci on previo y el actual Desde LILO puede expresarse el nivel de ejecuci on deseado tras la etiqueta del sis- tema operativo (Linux) a cargar. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion 47 6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion El administrador puede congurar las acciones que deben realizarse al entrar en un determinado nivel de ejecucion. Los directorios y cheros relevantes para esta conguracion son: Directorio /etc/rc.d. En el residen todos los scripts de inicializacion. Fichero /etc/inittab Fichero base de conguracion del arranque de la maquina. Fichero /etc/rc.d/rc.sysinit Script de inicializacion del ordenador, independiente del nivel . Directorios /etc/rc.d/rc?.d Un directorio por cada nivel de ejecucion. Contiene enlaces simbolicos a los scripts que conguran la entrada a este nivel. Directoiro /etc/rc.d/init.d Aqu residen los scripts que son ejecutados desde algun nivel de ejecucion. 6.4 Secuencia de Arranque de un Sistema Linux Cuando arranca un sistema Linux se producen las acciones siguientes: 1. Se carga e inicializa el nucleo del sistema. 2. El nucleo crea el primer proceso del sistema, denominado init. 3. Init realiza las acciones especicadas en el chero /etc/inittab. 4. Init ejecuta el script /etc/rc.d/rc.sysinit. 5. Init hace que el sistema entre en el nivel especicado en /etc/initab. No es normal tener que congurar esta secuencia de arranque, dictaminada por los cheros /etc/inittab y /etc/rc.d/rc.sysinit. Estos cheros son congurados en origen por quien distribuye el sistema operativo. No obstante, pueden ser necesarios para congurar sistemas Linux con requerimientos muy especcos. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 48 Niveles de ejecucion en Linux 6.5 Secuencia de Entrada en un Nivel de Ejecucion Cuando se entra en un determinado nivel de ejecucion, se realizan las siguientes acciones: 1. Se ejecutan, por orden de nombre, todos los scripts que comienzan por 'K' en el directorio correspondie nte al nivel, utilizando como argumento para dicho script stop. 2. Se ejecutan, por orden de nombre, todos los scripts que comienzan por 'S' en el directorio correspondiente al nivel, utilizando como argumento para dicho script start. A ttulo de ejemplo, a continuacion se muestra un listado del directorio /etc/rc.d/rc3.d, el cual corresponde al nivel multiusuario con red. ls -l rc3.d/ total 0 lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx 1 1 1 1 1 1 1 1 1 1 1 root root root root root root root root root root root root root root root root root root root root root root 13 13 15 17 17 16 16 13 15 18 11 Apr Apr Apr Apr Apr Apr Apr Apr Apr Apr Apr 1 1 1 1 1 1 1 1 1 1 1 1998 1998 1998 1998 1998 1998 1998 1998 1998 1998 1998 K15gpm -> ../init.d/gpm K60lpd -> ../init.d/lpd K95nfsfs -> ../init.d/nfsfs S01kerneld -> ../init.d/kerneld S10network -> ../init.d/network S20random -> ../init.d/random S30syslog -> ../init.d/syslog S40atd -> ../init.d/atd S40crond -> ../init.d/crond S75keytable -> ../init.d/keytable S99local -> ../rc.local Puede observarse como en este directorio tan solo existen enlaces simbolicos a los verdaderos scripts que residen en el directorio /etc/rc.d/init.d. Cada uno de estos scripts aceptan dos parametros, start y stop, en funcion del cual inician o detienen el servicio. En este ejemplo, la secuencia de entrada al nivel 3 sera: gpm stop lpd stop nfsfs stop kerneld start network start random start syslog start atd start crond start keytable start rc.local start c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 49 6.6 Conguracion de los Niveles de Ejecucion 6.6 Conguracion de los Niveles de Ejecucion La conguracion mas usual de los niveles de ejecucion se limita a indicar que scripts deben ejecutarse al entrar en cada nivel, bien para detener o para activar un determinado servicio. Para ello, basta crear los enlaces simbolicos adecuados o, mejor todava, utilizar alguna herramienta graca que simplique esta labor, tal como el editor de niveles de ejecucion que se encuentra accesible en el panel de control de RedHat. La Figura 6.1 muestra el aspecto de dicha herramienta. Figura 6.1: Editor de niveles de ejecucion (panel de control) de RedHat linux. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Cap tulo 7 Montaje de Dispositivos en Linux Indice General 7.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.2 Utilizacion Basica . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.3 La tabla de Montaje de Dispositivos . . . . . . . . . . . . . . . . 52 7.4 Montaje de directorios remotos va NFS . . . . . . . . . . . . . 54 7.5 Otros mandatos relacionados . . . . . . . . . . . . . . . . . . . . 54 7.1 Introduccion Unix ofrece al usuario una vision jerarquica del sistema de archivos, donde los directorios pueden ser creados en cualquier nivel para organizar as los cheros. A diferencia de otros sistemas, Unix ofrece una sola jerarqua, es decir, un solo directorio raz. En sistemas tipo MS-DOS o Windows, hay varias jerarquas, tantas como unidades de almacenamiento (particiones, disquetes, cd-roms, unidades de red) tenga el ordenador. Cada una de estas jerarquas es identicada por una letra de unidad seguida del caracter ':', por ejemplo, D:. Unix, en cambio, encadena todos los dispositivos que contienen sistemas de archivos en una unica jerarqua, siendo por tanto este acceso transparente al usuario. A esta tecnica se le denomina montaje de dispositivos. 51 52 Montaje de Dispositivos en Linux 7.2 Utilizacion Basica Para utilizar un dispositivo que contiene un sistema de archivos se utiliza el mandato mount, el cual utiliza dos argumentos, un nombre de dispositivo y un nombre de directorio. Por ejemplo: mount /dev/hdb6 /mnt En el ejemplo anterior, el directorio raz del sistema de archivos que reside en el dispositivo /dev/hdb6 (la segunda particion logica del disco duro primario esclavo) se monta en el directorio /mnt. De esta forma, cualquier acceso que indique /mnt hace que Unix acceda a la particion que ha sido montada. Linux reconoce muchos tipos de sistemas de archivos, algunos nativos del propio Linux y otros propios de otros sistemas operativos o estandares internacionales. Los mas relevantes son: Tipo Descripcion ext2 swap Sistema de archivos nativo Linux. Area de intercambio en disco de Linux. proc Jerarqua de informacion sobre el nucleo. msdos Sistema FAT 16 o FAT 31 con nombres cortos. vfat Sistema FAT 16 o FAT 32 con nombres largos. nfs Directorio remoto accesible va NFS. Tabla 7.1: Principales tipos de particiones utilizables desde Linux. Para indicar a mount el tipo del sistema de archivos, se utiliza la opcion -t . Adicionalmente puede utilizarse el tipo auto, el cual indica a mount que reconozca de forma automatica el tipo del sistema de archivos, opcion que resulta especialmente util en el chero /etc/fstab, el cual se describe a continuacion. Cuando se utiliza mount sin la opcion -t, se asume la opcion -t auto. Debe tenerse en cuenta que lo anteriormente expuesto incluye a todo tipo de dispositivos. Por tanto, el acceso a medios no jos como cd-rom o disquete se realiza igualmente utilizando mount. 7.3 La tabla de Montaje de Dispositivos Con el n de simplicar y unicar la gestion de los dispositivos montados, el administrador puede establecer en el chero /etc/fstab aquellos dispositivos que son conocidos por el c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 53 7.3 La tabla de Montaje de Dispositivos sistema, llegando incluso a indicar si algunos de ellos deben ser montados durante el momento del arranque del ordenador. Un ejemplo de este chero es el siguiente: /dev/hda3 /dev/hda2 none /dev/hdb1 /dev/hdb2 /dev/fd0 /dev/fd0 / swap /proc /e700l /e700 /A /B ext2 swap proc ext2 msdos msdos ext2 defaults defaults defaults noauto,user noauto,user noauto,user noauto,user 1 0 0 0 0 0 0 1 0 0 0 0 0 0 Cada lnea de dicho chero establece un dispositivo a montar junto con sus opciones. Por ejemplo, la Tabla 7.2 interpreta el signicado de los parametros de la primera lnea. Parametro Descripcion /dev/hda3 Dispositivo a montar. / Directorio donde montarlo. ext2 Tipo del sistema de archivos. defaults Opciones de montaje. 1 Volcado. 1 Orden de vericacion por fsck en el arranque del sistema. Solo debe aplicarse a los dispositivos locales que se montan durante el arranque. Tabla 7.2: Interpretacion del chero /etc/fstab. Existe una gran cantidad de opciones de montaje, algunas de las cuales son dependientes del tipo del sistema de archivos (consultese el mandato mount en el manual). Las opciones mas comunes y su signicado se presentan en la Tabla 7.3. Una de las ventajas de este chero es que simplica la utilizacion del mandato mount, el cual puede utilizar un solo argumento, bien sea el nombre del dispositivo o, mejor aun, el nombre del directorio. En estos casos, mount utiliza el tipo de sistema de archivos especicado en el chero. Por ejemplo: mount /A mount /e700 Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 54 Montaje de Dispositivos en Linux Opcion Descripcion defaults Opciones por defecto. Incluye montar el dispositivo durante el arranque del ordenador auto/noauto Si/No montar el dispositivo durante el arranque user/nouser Si/No permitir a un usuario convencional montar este dispositivo ro Montar el dispositivo en modo de solo-lectura rw Montar el dispositivo en modo de lectura-escritura dev/nodev Si/No interpretar cheros especiales de dispositivo suid/nosuid Si/No permitir la ejecucion de cheros con bits SETUID o SETGID activos Tabla 7.3: Opciones mas comunes en el montaje de dispositivos en Linux. 7.4 Montaje de directorios remotos va NFS El protocolo NFS permite utilizar un directorio de un ordenador remoto como si se tratase de un dispositivo, lo cual permite por tanto su montaje en el ordenador local. Puede utilizarse directamente el mandato mount o bien crear una entrada en el chero /etc/fstab. La forma de nombrar el dispositivo remoto es: nombre_de_ordenador:directorio_remoto A continuacion se muestra un ejemplo de mandato mount y la entrada correspondiente en /etc/fstab. mount 158.42.54.224:/diremoto /dirlocal 158.42.54.224:/diremoto /dirlocal nfs defaults 0 0 7.5 Otros mandatos relacionados mkfs Crea un sistema de archivos vaco en un dispositivo. fsck Verica la consistencia de un sistema de archivos. df Informa sobre el espacio libre y ocupado de un sistema de archivos c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Cap tulo 8 Dominios en Linux Indice General 8.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.2 Network Information System (NIS) . . . . . . . . . . . . . . . . 55 8.2.1 8.2.2 8.2.3 Instalacion de los Componentes NIS Server . . . . . . . . . . . . Conguracion del Servidor de NIS . . . . . . . . . . . . . . . . . Conguracion del Cliente de NIS . . . . . . . . . . . . . . . . . . 56 56 57 8.3.1 8.3.2 8.3.3 Como Funciona NFS . . . . . . . . . . . . . . . . . . . . . . . . . Instalacion y Conguracion del Cliente NFS . . . . . . . . . . . . Instalacion y Conguracion del Servidor NFS . . . . . . . . . . . 59 59 60 8.3 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . 57 8.1 Concepto de Dominio En el mundo Linux no existe un concepto de dominio tan elaborado como en el mundo de Windows NT. Sin embargo, se consigue un efecto similar al activar un servicio en una maquina Linux (que actuara como \servidor" de cuentas y grupos) y otro servicio que permite la exportacion de directorios a maquinas remotas. En concreto, dichos servicios se denominan NIS y NFS, respectivamente. Ambos son explicados a continuacion. 8.2 Network Information System (NIS) NIS (desarrollado por SUN Microsystems) es un sistema de informacion basado en red que permite centralizar en un solo ordenador datos administrativos que son comunes a toda 55 56 Dominios en Linux una red de area local. Para que esto sea posible, debe denirse un nombre de dominio NIS (no confundir con el dominio DNS), instalar el servidor de NIS en un ordenador de la red, y congurar el resto de ordenadores como clientes NIS. De ser necesario, es posible instalar servidores NIS adicionales (a los cuales se les denomina esclavos), los cuales actuan como replicas del servidor principal (maestro). En principio, NIS puede ofrecer a la red cualquier tipo de tabla de informacion. No obstante, su funcionalidad principal es centralizar las tablas de usuarios y grupos en un solo ordenador, facilitando as las tareas del administrador, el cual, si no utilizase NIS, debera mantener sincronizados de forma manual estos cheros. Otra de las tablas importantes que NIS ofrece a la red es el chero /etc/hosts, tabla que asocia direcciones IP a nombres de ordenadores. Este es el metodo preferido para crear una base de datos comun de ordenadores cuando no se emplea el servicio DNS, el cual es mas comun aplicarlo cuando la red local que se esta administrando esta conectada a Internet. Los clientes NIS, por su parte, pueden congurarse para dar preferencia a sus tablas locales o a las que el servidor NIS ofrece. Estas preferencias se establecen en el chero /etc/nsswitch.conf. 8.2.1 Instalacion de los Componentes NIS Server Para instalar el servicio NIS Server, se han de realizar los siguientes pasos (exclusivamente en el servidor): 1. Iniciar el equipo que sera el servidor del dominio NIS. 2. Montar el directorio /home/ftp/pub de adserver en el directorio local /mnt. 3. Cambiar al directorio /mnt/Redhat62/RedHat/RPMS para iniciar la instalacion 4. Instalar los componentes que constituyen el NIS server: rpm -ih ypserv-1.3.9-3.i386.rpm 8.2.2 Conguracion del Servidor de NIS Una vez instalados los componentes, estos deben ser congurados. Esencialmente, esto consiste en dar de alta los servicios de NIS Server y servicios de los que depende en el arranque de la maquina, congurar el nombre del dominio NIS y construir las bases de datos que seran exportadas desde el servidor de NIS. 1. Instalar los servicios: (a) Iniciar el panel de control. (b) Iniciar, desde el panel de control, el editor de niveles de ejecucion. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 57 8.3 Network File System (NFS) (c) De ser necesario, incorporar los siguientes servicios para que se inicien en los niveles 3 y 5: portmap, ypserv y yppasswd 2. Nombre del dominio. Utilizando linuxconf, dar de alta el dominio NIS escogido y la direccion IP del propio servidor de NIS (un servidor NIS debe ser cliente de si mismo). 3. Reiniciar la maquina en este punto. 4. Construir la base de datos: /usr/lib/yp/ypinit -m Esta utilidad solicitara nombres de servidores secundarios. No hay ninguno disponible. 5. Reiniciar la maquina. A partir de este punto, siempre que se produzca algun cambio en los cheros que gestiona NIS, deben reconstruirse las bases de datos. Para ello, ejecutar: cd /var/yp make 8.2.3 Conguracion del Cliente de NIS La conguracion de cualquier maquina Linux que tenga que ser cliente del servidor que se ha congurado arriba se realiza de la siguiente forma: 1. Iniciar el panel de control. 2. Iniciar, desde el panel de control, el editor de niveles de ejecucion. 3. Incorporar, si es necesario, los siguientes servicios para que se inicien en los niveles 3 y 5: portmap, ypbind. 4. Utilice linuxconf para indicar al sistema el dominio NIS y el servidor asociado a dicho dominio. 5. Reiniciar el equipo. 8.3 Network File System (NFS) Tal como se explica en el documento \Montaje de dispositivos en Linux" (de esta misma editorial :) un sistema Linux puede trabajar unicamente con una jerarqua de directorios, de tal forma que si se desea acceder a distintos sistemas de archivos (particiones de discos, Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 58 Dominios en Linux cd-roms, disquetes, etc.), todos ellos deben montarse primero en algun punto de dicha jerarqua. Siguiendo la misma losofa, Network File System (NFS) es un servicio de red que permite a un ordenador cliente montar y acceder a un sistema de archivos (en concreto, un directorio) remoto, exportado por otro ordenador servidor. Por ejemplo, supongase que una maquina denominada faemino desea acceder al directorio /home/ftp/pub de la maquina cansado. Para ello, debera invocarse el siguiente mandato (en faemino): mount -t nfs cansado:/home/ftp/pub /mnt Este mandato indica que el directorio /home/ftp/pub que es exportado por el ordenador cansado debe ser montado en el directorio local /mnt de faemino. Este directorio local debe existir previamente. La opcion -t nfs indica a mount el tipo de sistema de archivos que va a montar, aunque en este caso podra omitirse, ya que mount detecta por el caracter `:' que se trata de un montaje remoto. Una vez el montaje se ha realizado, cualquier acceso a archivos o directorios dentro de /mnt (lectura, escritura, cambio de directorio, etc.) se traducen de forma transparente a peticiones al ordenador servidor (cansado), que las resolvera y devolvera su respuesta al cliente, todo a traves de la red. Es decir, el montaje de directorios mediante NFS permite trabajar con archivos remotos exactamente igual que si fueran locales, aunque logicamente con una menor velocidad de respuesta. En general, NFS es muy exible, y admite diversos escenarios: Un servidor NFS puede exportar m as de un directorio y atender simultaneamente a varios clientes. Un cliente NFS puede montar directorios remotos exportados por diferentes servi- dores. Cualquier ordenador puede ser a la vez cliente y servidor NFS. Teniendo esto en cuenta, existen dos usos tpicos de NFS donde este servicio muestra su utilidad: a) Directorios de conexion (home) centralizados. Cuando en una red local de maquinas Linux se desea que los usuarios puedan trabajar indistintamente en cualquiera de ellas, es apropiado ubicar los directorios de conexion de todos ellos en una misma maquina y hacer que las demas monten esos directorios mediante NFS. b) Comparticion de directorios de uso comun. Si varios usuarios (desde distintas maquinas) trabajan con los mismos archivos (de un proyecto comun, por ejemplo) tambien resulta util compartir (exportar+montar) el/los directorio/s donde se ubican dichos archivos. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 59 8.3 Network File System (NFS) 8.3.1 Como Funciona NFS El funcionamiento de NFS esta basado, por una parte, en dos servicios de red presentes en el ordenador servidor (mountd y nfsd) y por otra en la capacidad del cliente de traducir los accesos de las aplicaciones a un sistema de archivos en peticiones al servidor correspondiente a traves de la red. Esta funcionalidad del cliente se encuentra normalmente programada en el nucleo de Linux, por lo que no necesita ningun tipo de conguracion. Respecto al servidor, el servicio mountd se encarga de atender las peticiones remotas de montaje, realizadas por la orden mount del cliente (como la del ejemplo anterior). Entre otras cosas, este servicio se encarga de comprobar si la peticion de montaje es valida y de controlar bajo que condiciones se va a acceder al directorio exportado (solo lectura, lectura/escritura, etc.). Una peticion se considera valida cuando el directorio solicitado ha sido explcitamente exportado y el cliente tiene permisos sucientes para montar dicho directorio. Esto se detalla mas adelante en el documento. Una vez un directorio remoto ha sido montado con exito, el servicio nfsd se dedica a atender y resolver las peticiones de acceso del cliente a archivos situados en el directorio. 8.3.2 Instalacion y Conguracion del Cliente NFS Como se ha expresado anteriormente, el cliente NFS no requiere ni instalacion ni conguracion. Los directorios remotos pueden importarse utilizando el mandato mount y el chero asociado /etc/fstab, segun se muestra en el documento \Montaje de Dispositivos en Linux". Recuerdese que en cada invocacion al mandato mount (y/o en cada lnea de /etc/fstab) se pueden establecer opciones de montaje. En ellas se particulariza el comportamiento que tendra el sistema de archivos una vez se haya montado en el directorio correspondiente. En el caso de NFS, las opciones mas importantes son las que gobiernan el modo de fallo de las peticiones remotas, es decir, como se comporta el cliente cuando el servidor no responde: a) soft. Con esta opcion, cuando una peticion no tiene respuesta del servidor el cliente devuelve un codigo de error al proceso que realizo la peticion. El problema es que muy pocas aplicaciones esperan este comportamiento y ello puede provocar situaciones en las que se pierda informacion. Por tanto, no es aconsejable. b) hard. Mediante esta opcion, cuando el servidor no responde el proceso que realizo la peticion en el cliente se queda suspendido indenidamente. Esta es la opcion que se recomienda normalmente, por ser la que esperan las aplicaciones, y por tanto mas segura desde el punto de vista de los datos. Se puede combinar con la opcion intr, que permite matar el proceso mediante el envo de una se~nal (de la forma tradicional en Linux). Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 60 Dominios en Linux A continuacion se muestra un ejemplo, en el que se ve la lnea del archivo (/etc/fstab de la maquina faemino) relacionada con el ejemplo de la seccion 8.3: #device mountpoint fs-type options dump fsckorder ... cansado:/home/ftp/pub /mnt nfs hard,intr 0 0 8.3.3 Instalacion y Conguracion del Servidor NFS El servidor necesita, ademas de los dos servicios mountd y nfsd (ambos se aunan en el servicio comun demominado nfs, uno mas denominado portmap (del ingles portmapper), sobre el cual ambos basan su funcionamiento. Por tanto, la conguracion de un servidor NFS necesita unicamente tener disponibles dichos servicios e iniciarlos en el nivel de ejecucion 3 (o 5, o ambos) de la maquina (ver documento \Niveles de ejecucion en Linux"). Una vez activos los servicios NFS, el servidor tiene que indicar explcitamente que directorios desea que se exporten, a que maquinas y con que opciones. Para ello existe un chero de conguracion denominado /etc/exports. A continuacion se muestra uno de ejemplo, sobre el que se explican las caractersticas mas relevantes: # Directory ... /tmp /home/ftp/pub / /pub /pub/nopublic Clients and (options) pc02??.dsic.upv.es(rw) *.disca.upv.es() 158.42.54.1(rw,root_squash) mio.dsic.upv.es(rw,no_root_squash) (rw,all_squash,anonuid=501,anongid=601) (noaccess) Es importante destacar que cada vez que se modica este chero, para que se activen los cambios, el servidor NFS debe ser actualizado ejecutando el mandato exportfs -ra. Cada lnea especica un directorio que se a exportar, junto con una lista de autorizaciones, es decir, que ordenadores podran montar dichos directorios y con que opciones (desde el punto de vista del servidor). Cada elemento de la lista de ordenadores puede especicar un solo ordenador (mediante nombre simbolico o direccion IP) o un grupo de ordenadores (mediante el uso de caracteres comodn como `*' o `?'). Cuando el ordendor/rango no se especica (por ejemplo, en las ultimas dos lneas), esto signica que el directorio correspondiente se exporta a todos los ordenadores del mundo (conectados a Internet). Por su parte, de entre las posibles opciones de montaje que, entre parentesis, pueden especicarse para cada ordenador/grupo, las mas importantes se resumen en la tabla 8.1. Una lista completa de las opciones de montaje y su signicado pueden encontrarse en la pagina de manual exports (5) de Linux. La mayora de estas opciones establecen como quien se comporta el proceso cliente cuando su peticion de acceso llega al servidor. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 61 8.3 Network File System (NFS) Opcion Signicado () ro rw root squash Esta opcion establece las opciones que NFS asume por defecto. Solo lectura. Lectura/escritura. Los accesos desde el cliente con UID=0 (root) se convierten en el servidor en accesos con UID de un usuario anonimo (opcion por defecto). Se permite el acceso desde un UID = 0 sin conversion. Es decir, los accesos de root en el cliente se convierten en accesos de root en el servidor. Todos los accesos se transforman en accesos de usuario anonimo. Cuando se activa la opcion root squash o all squash, los accesos anonimos utilizan norlmalmente el usuario nobody, si existe en el servidor (defecto). Estos dos parametros establecen que uid y gid tendra la cuenta anonima que el servidor utilizara para acceder contenido del directorio. Impide el acceso al directorio especicado. Esta opcion es util para impedir que se acceda a un subdirectorio de un directorio exportado. no root squash all squash anonuid, anongid noaccess Tabla 8.1: Opciones mas usuales en la exportacion de directorios mediante NFS. En principio, cada peticion lleva asociada el UID y GID del proceso cliente, es decir, se comporta como s mismo. No obstante, si esta activa la opcion all squash (o bien el UID es cero y root squash esta activado), entonces el UID/GID se convierten en los del usuario anonimo. De todas formas, hay que tener en cuenta que los permisos sobre cada acceso del cliente se evaluan mediante los UID/GID que nalmente son validos en el servidor (es decir, los originales o los anonimos, segun el caso). Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Cap tulo 9 Conguracion de Samba Indice General 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 >Que es samba? . . . . . . . . . . . . . . . . . . . . . . . . . Instalacion de Samba . . . . . . . . . . . . . . . . . . . . . . Conguracion de Samba . . . . . . . . . . . . . . . . . . . . Instalacion y Conguracion de swat . . . . . . . . . . . . . Niveles de Seguridad . . . . . . . . . . . . . . . . . . . . . . Conguracion de Samba con el Nivel de Seguridad domain Tratamiento de los Accesos como Invitado . . . . . . . . . El Sistema de Ficheros SMB para Linux . . . . . . . . . . Opciones del Servidor Samba . . . . . . . . . . . . . . . . . Opciones del Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 64 65 66 67 68 69 70 70 70 9.1 >Que es samba? Samba es un producto1 que se ejecuta en sistemas Unix, permitiendo al sistema Unix conversar con sistemas Windows a traves de la red de forma nativa. De esta forma, el sistema Unix aparece en el "Entorno de red", y clientes Windows pueden acceder a sus recursos de red e impresoras compartidas como si de otro sistema Windows se tratase. Para ello, Samba implementa los protocolos NetBIOS y SMB. NetBIOS es un protocolo de nivel de sesion que permite establecer sesiones entre dos ordenadores. SMB (Server Message Block), implementado sobre NetBIOS, es el protocolo que permite a los sistemas Windows compartir cheros e impresoras. 1 Samba se distribuye gratuitamente para varios versiones de Unix, de acuerdo con los terminos de la General Public License de GNU. 63 64 Conguracion de Samba Esencialmente, Samba consiste en dos programas, denominados smbd y nmbd. Ambos programas utilizan el protocolo NetBIOS para acceder a la red, con lo cual pueden conversar con ordenadores Windows. Haciendo uso de estos dos programas, Samba ofrece los siguientes servicios, todos ellos iguales a los ofrecidos por los sistemas Windows: Servicios de acceso remoto a cheros e impresoras. Autenticaci on y autorizacion. Resoluci on de nombres. Anuncio de servicios. El programa smbd se encarga de ofrecer los servicios de acceso remoto a cheros e impresoras (implementando para ello el protocolo SMB), as como de autenticar y autorizar usuarios. smbd ofrece los dos modos de comparticion de recursos existentes en Windows, basado en usuarios o basado en recursos. En el modo basado en usuarios (propio de los dominios NT) la autorizacion de acceso al recurso se realiza en funcion de nombres de usuarios registrados en un dominio, mientras que en el modo basado en recursos (propio de Windows 3.11/95) a cada recurso se le asigna una contrase~na, estando autorizado el acceso en funcion del conocimiento de dicha contrase~na. El programa nmbd permite que el sistema Unix participe en los mecanismos de resolucion de nombres propios de Windows, lo cual incluye el anuncio en el grupo de trabajo, la gestion de la lista de ordenadores del grupo de trabajo, la contestacion a peticiones de resolucion de nombres y el anuncio de los recursos compartidos. De esta forma, el sistema Unix aparece en el "Entorno de Red", como cualquier otro sistema Windows, publicando la lista de recursos que ofrece al resto de la red. Adicionalmente a los dos programas anteriores, Samba ofrece varias utilidades. Algunas de las mas relevantes son las siguientes: smbclient. Una interfaz similar a la utilidad ftp, que permite a un usuario de un sistema Unix conectarse a recursos SMB y listar, transferir y enviar cheros. swat (Samba Web Administration Tool). Esta utilidad permite congurar Samba de forma local o remota utilizando un navegador de web. Sistema de cheros SMB para Linux. Linux puede montar recursos SMB en su jerarqua, al igual que sucede con directorios compartidos va NFS. 9.2 Instalacion de Samba Los pasos que hay que seguir para instalar Samba en RedHat Linux son los siguientes: 1. Montar el directorio /home/ftp/pub de adserver en el directorio local /mnt. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 65 9.3 Conguracion de Samba 2. Cambiar al directorio /mnt/redhat62/RedHat/RPMS para iniciar la instalacion. 3. Instalar Samba: rpm -ih Samba-2.0.6-9.i386.rpm Una vez instalado Samba, hay que vericar que el servicio smb esta activo en el niveles de ejecucion 3 y/o 5, y despues reiniciar el sistema. 9.3 Conguracion de Samba La conguracion de Samba se realiza en el chero /etc/smb.conf. En este chero se establecen las caractersticas del servidor Samba, as como los recursos que seran compartidos en la red. La utilizacion de este chero es bastante sencilla, ya que aunque existe un gran numero de opciones, muchas de ellas pueden obviarse dado que siempre existe una valor por defecto para cada opcion, que suele ser apropiado. A ttulo de ejemplo, en la Figura 9.1 se muestra un chero de conguracion simple, que exporta el directorio de conexion de cada usuario como un recurso de red distinto, y el directorio /espacio/pub como el recurso de red pub. [global] ... [homes] comment = Home Directories ... [pub] path = /espacio/pub Figura 9.1: Fichero /etc/smb.conf Como se ve en el ejemplo, el chero /etc/smb.conf se encuentra divido en secciones, encabezad s por una palabra entre corchetes. Dentro de cada seccion guran opciones de conguracion, de la forma etiqueta = valor, que determinan las caractersticas del recurso exportado por la seccion. En los apartados 9.9 y 9.10 del presente documento se citan las opciones mas importantes que se pueden establecer en cada seccion. Existen tres secciones predenidas, denominadas global, homes y printers, y tantas secciones adicionales como recursos extra se quieran compartir. El cometido de dichas secciones predenidas se describe en la Tabla 9.1, a continuacion. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 66 Conguracion de Samba Seccion Cometido [global] Dene los parametros de Samba a nivel global del servidor, as como los parametros que se estableceran por defecto en el resto de las secciones. Dene automaticamente un recurso de red por cada usuario conocido por Samba. Este recurso, por defecto, esta asociado al directorio de conexion de cada usuario en el ordenador en el que Samba esta instalado. Dene un recurso compartido por cada nombre de i mpresora conocida por Samba. [homes] [printers] Tabla 9.1: Secciones globales en el chero /etc/smb.conf. Para cualquier otro recurso (directorio o impresora) que se quiera compartir hay que denir una seccion adicional en el chero de conguracion. El encabezamiento de dicha seccion (pub en el ejemplo anterior) correspondera al nombre que el recurso tendra en la red. Por otra parte, Samba ofrece una interfaz de edicion de este chero basada en web denominada swat. Esta herramienta permite congurar Samba utilizando un navegador de red, tanto de forma local como remota. 9.4 Instalacion y Conguracion de swat swat es un programa que atiende peticiones http en el puerto tcp 901. Para activar swat es necesario seguir los pasos siguientes: 1. Instalar el servicio inetd. rpm -ih inetd-0.16-4.i386.rpm 2. Declarar el servicio swat. Incluir o vericar que ya existe la siguiente lnea en el chero /etc/services: swat 901/tcp 3. Asociar el programa swat al nuevo servicio. Descomentar la siguiente lnea en el chero /etc/inetd.conf: #swat stream nowait.400 root /usr/sbin/swat swat c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 67 9.5 Niveles de Seguridad 4. Activar el servicio swat: /etc/rc.d/init.d/inet start A partir de este momento, la conguracion de Samba puede realizarse va Web. Para ello, basta con acceder a la direcion http://nombre de ordenador:901/ mediante cualquier navegador. 9.5 Niveles de Seguridad Una de las consideraciones mas importantes a la hora de congurar Samba es la seleccion del nivel de seguridad. Desde la perspectiva de un cliente, Samba ofrece dos modos de seguridad, denominados share y user, al igual que sucede en los sistemas Windows: a) Modo Share. En el modo share, cada vez que un cliente quiere utilizar un recurso ofrecido por Samba, debe suministrar una contrase~na de acceso asociada a dicho recurso. b) Modo User. En el modo user, el cliente debe establecer en primer lugar una sesion con el servidor Samba, para lo cual le suministra un nombre de usuario y una contrase~na. Una vez Samba valida al usuario, el cliente obtiene permiso para acceder a los recursos ofrecidos por Samba. En cualquiera de ambos, Samba tiene que asociar un usuario del sistema Unix en el que se ejecuta Samba con la conexion realizada por el cliente. Este usuario es el utilizado a la hora de comprobar los permisos de acceso a los cheros y directorios que el sistema Unix/Samba comparte en la red. La seleccion del nivel de seguridad se realiza con la opcion security, la cual pertenece a la seccion [global]. Sus alternativas son las siguientes: security = share | user | server | domain Desde la perspectiva del cliente, el nivel share corresponde al modo de seguridad share y los niveles user, server y domain corresponden todos ellos al modo de seguridad user. A continuacion se describen someramente los cuatro niveles. El nivel share es utilizado normalmente en entornos en los cuales no existe un dominio NT, dado que es complejo y costoso el mantenimiento de una tabla de usuarios global para la red. En este caso, se asocia una contrase~na por cada recurso, que debe proporcionarse correctamente desde el cliente cuando se pide la conexion. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 68 Conguracion de Samba En el nivel user, el encargado de validar al usuario es el sistema Unix donde Samba se ejecuta. La validacion es identica a la que se realizara si el usuario iniciase una sesion local en el ordenador Unix. Para que este metodo sea aplicable, es necesario que existan los mismos usuarios y con identicas contrase~nas en los sistemas Windows y en el sistema Unix donde Samba se ejecuta. Recientemente, la utilizacion de este nivel se ha vuelto complicada, ya que en Windows 98 y en Windows NT (Service Pack 3 y posteriores), las contrase~nas de los usuarios se transmiten cifradas por la red. Puesto que el tipo de cifrado no es conocido por Samba, el sistema Unix ya no pue de realizar la validacion. Existen dos metodos para resolver este problema. El primero consiste en modicar el registro del sistema Windows para permitir la transferencia de contrase~nas sin cifrar por la red. El segundo metodo obliga a utilizar una tabla de contrase~nas adicional en el sistema Unix, en la cual se almacenan las contrase~nas cifradas de los usuarios Windows. En el nivel server, Samba delega la validacion del usuario en otro ordenador, normalmente un sistema Windows NT. Cuando un cliente intenta iniciar una sesion con Samba, este ultimo intenta iniciar una sesion en el ordenador en el cual ha delegado la validacion con la misma acreditacion (usuario+contrase~na) recibidos del cliente. Si la sesion realizada por Samba es satisfactoria, entonces la solicitud del cliente es aceptada. Este metodo aporta la ventaja de no necesitar que las contrase~nas se mantengan sincronizadas entre los sistemas Windows y Unix, ya que la contrase~na Unix no es utilizada en el proceso de validacion. Adicionalmente, no hay inconveniente en utilizar contrase~nas cifradas, ya que la validacion la realiza un sistema NT. Por ultimo, existe la posibilidad de utilizar el nivel domain. Este nivel es similar al nivel server, aunque en este caso el ordenador en el que se delega la validacion debe ser un PDC (o un a lista de ordenadores PDC y BDC). La ventaja de este metodo estriba en que el ordenador Samba pasa a ser un verdadero miembro del dominio NT, lo que implica, por ejemplo, que puedan utilizarse las relaciones de conanza establecidas por el dominio. Esto signica, en pocas palabras, que usuarios pertenecientes a otros dominios en los que el PDC confa son conocidos por Samba. Por otra parte, como comentan los creadores de Samba, este metodo permitira en un futuro cercano eliminar la necesidad de mantener una tabla de usuarios en el sistema Unix sincronizada con la tabla de usuarios del dominio NT. En n, tal como dicen ellos, watch for this code soon!. Dadas las ventajas de el nivel domain, este documento se centra fundamentalmente en este metodo. Para detalles especcos de los otros niveles, se recomienda la consulta de la documentacion original de Samba. 9.6 Conguracion de Samba con el Nivel de Seguridad domain Los pasos a seguir para congurar Samba con el nivel de seguridad domain son los siguientes: 1. Dar de alta en el PDC al sistema Unix donde se ejecuta Samba como miembro del c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 69 9.7 Tratamiento de los Accesos como Invitado dominio. Esta accion se realiza desde el "Administrador de Servidores". 2. Detener el servidor Samba: /etc/rc.d/init.d/smb stop 3. Agregar el sistema Unix al dominio. smbpasswd -j DOMINIO -r PDC_DEL_DOMINIO 4. Congurar el nivel en el chero /etc/smb.conf. En la seccion [global] incorporar: security = domain workgroup = DOMINIO encrypt passwords = yes password server = PDC_DEL_DOMINIO 5. Iniciar el servidor Samba: /etc/rc.d/init.d/smb start 9.7 Tratamiento de los Accesos como Invitado Cuando se utiliza el nivel de seguridad domain, el tratamiento de los accesos como usuario invitado requiere algunas consideraciones. En primer lugar, Samba considera a un usuario como invitado solo cuando este usuario esta dado de alta en el dominio NT al cual pertenece Samba pero no esta dado de alta en el sistema Unix donde Samba se ejecuta. De esta forma, usuarios de otros dominios (en los que no se confa) no pueden acceder a Samba, ni siquiera como invitados. Para conseguir que usuarios ajenos al dominio NT se consideren invitados, es necesario activar la siguiente opcion en la seccion [global]: map to guest = Bad User De esta forma, cualquier usuario no conocido sera tratado como invitado. Samba considerara que los accesos al sistema de cheros Unix los realizara el usuario especicado en la opcion global guest account. En cualquier caso, el acceso como invitado debe permitirse expresamente para cada recurso con la opcion guest ok. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 70 Conguracion de Samba 9.8 El Sistema de Ficheros SMB para Linux Linux dispone de soporte para el sistema de cheros SMB. De esta forma, Linux, al igual que puede montar un directorio exportado va NFS en un directorio local, puede montar un recurso SMB ofrecido por un servidor SMB (un sistema Windows o un servidor Samba, por ejemplo). No obstante, existe una diferencia signicativa entre NFS y SMB. En NFS no se requiere autenticar al usuario que realiza la conexion; el servidor NFS utiliza el UID del usuario del ordenador cliente para acceder a los cheros y directorios exportados. Un servidor SMB, por contra, requiere autenticar al usuario, para lo que necesita un nombre de usuario y una contrase~na. Por ello, para montar un recurso SMB se utiliza el mandato mount indicandole un tipo de sistema de archivos especco, denominado smbfs: mount -t smbfs -o username=NOMBRE_DE_USUARIO,passwd=CONTRASE~NA,workgroup= GRUPO o DOMINIO //ORDENADOR/RECURSO DIRECTORIO\_LOCAL Si se omite la opcion passwd, se solicita al usuario que introduzca una contrase~na. Si el servidor SMB valida al usuario, a partir del directorio directorio local se consigue el acceso al recurso //ordenador/recurso. El recurso puede desmontarse utilizando el mandato umount, cuya utilizacion es la siguiente: umount directorio_local 9.9 Opciones del Servidor Samba En la Tabla 9.2 a continuacion se describen algunas opciones del servidor Samba. Estas opciones tan solo son aplicables a la seccion [global]. 9.10 Opciones del Recurso En la Tabla 9.4 al nal del captulo se describen algunas opciones aplicables a cada recurso compartido. Pueden establecerse tambien en la seccion global, siendo en este caso utiliz das como valores por defecto para cada recurso compartido. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 71 9.10 Opciones del Recurso Opcion Signicado Valor por defecto netbios name Nombre NetBIOS del ordenador Primer componente de su nombre DNS log level Detalle en la auditora de Samba. Es un numero que indica la cantidad de informacion a auditar. A mayor valor, mas cantidad de informacion. Se establece en el script que inicia el servicio Samba. log file Nombre del chero donde se almacenan mensajes de auditora de Samba. Se establece en el script que inicia el servicio Samba. wins server Ordenador servidor de WINS. El sistema Samba se convierte en cliente WINS. nulo. wins support fyes/nog El ordenador Samba se convierte en servidor WINS (funcionalidad limitada). no. Tabla 9.2: Principales opciones de la seccion [global] de Samba. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 72 Conguracion de Samba Opcion Signicado Valor por defecto read only fyes/nog Recurso de solo lectura. yes browseable fyes/nog El servicio aparece en la lista de recursos compartidos. yes path Directorio asociado al servicio. | comment Descripcion del servicio. | guest ok fyes/nog Permitir los accesos en modo invitado. no guest account Si un acceso se realiza como invitado (usuario no conocido) se utiliza el usuario indicado para representar la conexion. nobody guest only Cualquier acceso se realiza en modo invitado. no copy Duplica un servicio ya declarado | force user Los accesos al recurso se realizan como si el usuario que accede es el usuario indicado. Se utiliza el mismo usuario que ha realizado la conexion. force group Los accesos al recurso se realizan como si el usuario que accede pertenece al grupo indicado. Se utiliza el grupo primario del usuario que ha realizado la conexion. hosts allow Lista ordenadores a los que se permite acceder. lista vaca (i.e., todos los ordenadores). hosts deny Lista ordenadores a los que no se les permite acceder. En caso de conicto, prevalece lo indicado en hosts allow. ningun ordenador. valid users Lista de usuarios que pueden acceder a este recurso. lista vaca (i.e., todos los usuarios). follow symlinks fyes/nog Permitir el seguimiento de los enlaces simbolicos. yes Tabla 9.4: Principales opciones de recurso de Samba. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Cap tulo 10 Servicio de Nombres de Internet de Windows Indice General 10.1 10.2 10.3 10.4 10.5 Descripcion Basica de WINS . . . . . . . . . . . . . Servidores de Duplicacion . . . . . . . . . . . . . . . El Proceso de Registro, Renovacion y Liberacion . El Proceso de Resolucion de Nombres . . . . . . . . Instalacion del Servidor y de los Clientes WINS en ... ... ... ... NT . . . . . . . . . . . . . . . . . . . . 73 75 76 77 77 10.1 Descripcion Basica de WINS El Servicio de Nombres de Internet de Windows o WINS (Windows Internet Naming Service) es un servicio de red, especco de Windows NT Server, que proporciona una traduccion de nombres (de equipo) NetBIOS a direcciones IP. NetBIOS es un protocolo de sesion que utilizan los programas basados en Windows1 cuando se comunican con otros equipos a traves de la red. Por debajo, este protocolo puede estar soportado por distintos protocolos de transporte, como por ejemplo NetBeui, IPX o TCP/IP. En este ultimo caso, cuando NetBIOS se implementa encima de TCP/IP, es necesario traducir de alguna manera los nombres simbolicos de maquinas en direcciones IP, para que los mensajes lleguen a su destino. Un equipo con Windows NT tiene cuatro alternativas para realizar esta traduccion: 1 Entiendase cualquier version de Windows (3.11, 95, 98, NT, etc.). 73 74 Servicio de Nombres de Internet de Windows 1) Difusion de direcciones IP (broadcast). Es decir, se emite un mensaje a toda la red local, y la maquina cuyo nombre simbolico coincide con el que gura en el mensaje, se comunica con el emisor, diciendole su IP. 2) Ficheros locales. Estos cheros cuentan con asociaciones estaticas del tipo nombre/direccion IP. En Windows NT, dichos cheros se denominan LMHOSTS y HOSTS. 3) Consultar a un servidor DNS (Domain Name Service). Estos servidores poseen cheros estaticos de asociacion de nombres/direcciones IP, y son capaces de resolver peticiones en este sentido. Estos cheros tienen que ser generados manualmente por el administrador del servidor. 4) Consultar a un servidor WINS, tambien denominado servidor de nombres NetBIOS. La alternativa de utilizar un servidor WINS para la resolucion de nombres tiene ventajas importantes respecto a las otras tres: Las difusiones provocan un gran traco en la red, que sera mayor cuantos mas equipos esten conectados a la misma. Este traco no lleva informacion de aplicacion, con lo que el rendimiento del acceso a la red se degrada. Los cheros est aticos LMHOSTS y HOSTS son difciles de mantener, puesto que han de ser editados manualmente, y ademas tienen que residir en cada equipo. Los servidores DNS son una soluci on aceptable cuando las asociaciones entre nombres de equipo y direcciones IP son jas. Sin embargo, si hay frecuentes cambios en dichas asociaciones es difcil mantener consistente la base de datos de asociaciones con la situacion real en cada momento. Esto ocurre, por ejemplo, cuando esta activo el servicio DHCP (ver captulo 11). Frente a la solucion aportada por DNS, WINS plantea una aproximacion diferente: Un servidor WINS posee una base de datos (de asociaciones) en donde se van registrando dinamicamente las maquinas Windows conforme van arrancando y conectandose a la red. Cuando una de estas maquinas (o clientes WINS ) va a apagarse, lo comunica a su servidor WINS, el cual lo elimina de la base de datos. De esta forma, la base de datos se encuentra siempre actualizada con los nombres de los equipos (y sus IPs) conectados en cada momento a la red. Cuando un cliente WINS desea averiguar la direccion IP de otro equipo, simplemente se lo pregunta a su servidor WINS. Esta forma de trabajar es la solucion mas natural en redes Windows, tanto si tenemos activo el servicio DHCP como si no. El motivo de ello es que para WINS es indiferente la forma en que un equipo haya recibido su direccion IP (manualmente o a traves de DHCP), as como si esta direccion es siempre la misma, o cambia cada vez que arranca el equipo. Ademas, este servicio resuelve otro grave problema de las redes NetBIOS: la duplicidad de nombres de equipo en la red. Cuando en una misma red local existen dos equipos con c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 75 10.2 Servidores de Duplicacion el mismo nombre, el conicto provoca habitualmente que las aplicaciones encuentren uno u otro aleatoriamente (o incluso que no se encuentre ninguno de ambos). Al estar activo WINS, cuando un equipo intenta registrarse con un nombre ya en uso, la operacion de registro es rechazada, y el equipo no puede conectarse a la red. 10.2 Servidores de Duplicacion Si se desea activar el servicio WINS en una red Windows, es necesario que al menos un NT Server conectado a la misma ofrezca el servicio WINS al resto de equipos (NT Workstation no puede ofrecer este servicio). Sin embargo, en redes con un numero de equipos medio o alto es deseable tener mas de un servidor WINS, puesto que de esta forma: Se reparte entre todos los servidores la carga provocada por el registro de equipos y la consulta de direcciones IP. Se replica la informaci on que cada servidor tiene, lo que produce una cierta tolerancia a fallos en la resolucion de nombres en la red. Adicionalmente los servidores WINS pueden utilizarse para la resolucion de nombres NetBIOS entre ordenadores que pertenecen a redes fsicas diferentes. En estos casos, en cada red se instala un servidor WINS, el cual registra los ordenadores de su red. A su vez, se conguran todos los servidores WINS para que repliquen su informacion, consiguiendo as que cada servidor WINS conozca tambien a los ordenadores que no forman parte de su red, suministrando esta informacion a sus clientes. Cuando en una red hay varios servidores WINS, todos ellos han de intercambiar la informacion que contienen sus bases de datos, para que la informacion acerca de los equipos conectados sea completa y consistente, y para que sea accesible a cualquier cliente. Para ello, cada servidor WINS tiene que congurarse como servidor de extraccion y como servidor de insercion de otro u otros servidores WINS. En concreto: a) Servidor de Extraccion (Pull Partner). Si un servidor WINS A se congura como servidor de extraccion de otro servidor B, entonces A le solicitara a B cada cierto tiempo que le enve su base de datos (o en cualquier momento, a peticion del administrador). La Figura 10.1 muestra el sentido en que uira la informacion en el caso de que el servidor WINS 2 actuara como servidor de extraccion del WINS 1. b) Servidor de Insercion (Push Partner). Si un servidor WINS A se congura como servidor de insercion de otro servidor B, entonces A le enviara a B su base de datos cuando se produzca en ella un numero determinado de cambios (o en cualquier momento, a peticion del administrador). La Figura 10.1 muestra el sentido en que uira la informacion en el caso de que el servidor WINS 1 actuara como servidor de insercion del WINS 2. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 76 Servicio de Nombres de Internet de Windows WINS_1 WINS_2 Servidor de Insercion Servidor de Extraccion (Push Partner) (Pull Partner) Figura 10.1: Servidores de Insercion y Extraccion en WINS. 10.3 El Proceso de Registro, Renovacion y Liberacion Cuando un cliente WINS se inicia, enva un mensaje directo a su servidor WINS principal, informandole de (entre otros) su direccion IP y su nombre NetBIOS. Cuando es recibido por el servidor, este busca en su base de datos y comprueba si dicho nombre de equipo ya ha sido registrado. Si no hay conicto, registra el nombre e informa positivamente al cliente, que puede entonces nalizar su arranque. Por el contrario, si ya existe otro equipo registrado con el mismo nombre, el servidor intenta contactar con el, para comprobar que se encuentra efectivamente conectado. Si recibe respuesta del propietario actual del nombre, entonces enva un mensaje negativo al aspirante, que no podra conectarse utilizando este nombre. De forma similar a lo que ocurre con DHCP, un registro positivo se considera como una concesion, teniendo un tiempo de validez denominado tiempo de vida o TTL (Time To Live). Cuando la mitad de dicho tiempo de vida ha transcurrido, el cliente empieza a enviar mensajes de renovacion del nombre al servidor WINS primario cada cierto tiempo, hasta que este le contesta positivamente. Por ultimo, cuando un cliente WINS es apagado correctamente, este enva un mensaje de liberacion al servidor WINS. El servidor WINS comprueba si dicho cliente era el propietario del nombre, y en ese caso le devuelve un mensaje positivo. Si ocurre algun error, el mensaje del servidor al cliente sera negativo. Sin embargo, el cliente no comprueba el contenido del mensaje, y en cualquier caso continua con el proceso de detencion del equipo. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 77 10.4 El Proceso de Resolucion de Nombres 10.4 El Proceso de Resolucion de Nombres En el contexto de las redes TCP/IP, se denomina resolucion de nombres al proceso de averiguar la direccion IP de un equipo, dado su nombre simbolico. Los equipos Windows (en general) pueden caracterizarse en cuatro clases, en funcion de como realizan la resolucion de nombres: a) Clase b-node (broadcast node). Utiliza unicamente difusiones IP para averiguar la direccion IP de un equipo. b) Clase p-node (point-to-point node). Utiliza comunicacion directa (punto a punto) con un servidor de nombres NetBIOS, es decir, un servidor WINS en redes NT. c) Clase m-node (mix node). Utiliza una mezcla de las dos primeras, pero primero intenta resolver el nombre mediante una difusion, y si no lo consigue, trata de contactar con un servidor WINS. d) Clase h-node (hybrid node). Utiliza una combinacion hbrida de las dos primeras para la resolucion de nombres, pero solo realiza una difusion cuando falla la solicitud al servidor WINS (por ejemplo, si no esta disponible en ese momento). En concreto, el orden que sigue un nodo hbrido para resolver un nombre es: contactar con servidor(es) WINS, difusion IP, chero LMHOSTS, chero HOSTS, y por ultimo, contactar con servidor(es) DNS. Cuando un sistema NT es congurado como cliente WINS, por defecto se establece como nodo hbrido. Por otra parte, el tipo de nodo es uno de los parametros de conguracion que un servidor DHCP puede asociar a un cliente. Un equipo cualquiera puede saber de que tipo es mediante el mandato ipconfig /all. 10.5 Instalacion del Servidor y de los Clientes WINS en NT Para instalar este servicio, se debe ir al Panel de Control de Windows NT Server, y dentro del mismo, abrir la conguracion de red. Entonces se nos presenta en pantalla un cuadro con diversas pesta~nas (Identificacion, Servicios, Protocolos, etc.). En la pesta~na Servicios se puede observar que servicios de red proporciona el sistema actualmente. Entonces se debe pinchar en el boton Agregar..., y buscar en la lista el Servicio de Nombres de Internet de Windows. Una vez hecho esto, se nos pedira (como no) que reiniciemos el equipo. A partir de ese momento se a~nade al menu Herramientas Administrativas (comun) la aplicacion Adminstrador WINS, con la que podremos empezar a congurar el servicio. Respecto a los clientes, lo unico que se debe hacer es ir a Panel de control/ Red/ Protocolos, seleccionar el protocolo TCP/IP, y pinchar en el boton Propiedades. En Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 78 Servicio de Nombres de Internet de Windows el cuadro de dialogo que se muestra entonces hay que pinchar en la pesta~na Direccion WINS, y all especicar la direccion IP del servidor WINS principal (y del secundario, si existe). c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Cap tulo 11 Servicio DHCP en Windows NT Indice General 11.1 11.2 11.3 11.4 11.5 Descripcion Basica de DHCP . . . . . . . . . . . . . . . . Concepto de Ambito . . . . . . . . . . . . . . . . . . . . . Instalacion del Servidor y de los Clientes DHCP en NT El Administrador DHCP de NT . . . . . . . . . . . . . . La Utilidad ipconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 81 81 82 83 11.1 Descripcion Basica de DHCP DHCP (Dynamic Host Conguration Protocol) o Protocolo Dinamico de Conguracion de Equipos no es un protocolo especco de Windows NT, sino que se trata de un estandar para cualquier tipo de sistema conectado a una red TCP/IP. La funcion basica de este protocolo es evitar que el administrador tenga que congurar manualmente las caractersticas propias del protocolo TCP/IP en cada equipo. Para ello, existe en la red un sistema especial, denominado servidor DHCP, que es capaz de asignar la conguracion TCP/IP al resto de maquinas presentes en la red, o clientes DHCP, cuando estos arrancan. Entre los datos que mas habitualmente proporciona el servidor a los clientes se incluyen: Una direcci on IP por cada tarjeta de red o NIC (Network Interface Card) que posea el cliente. La m ascara de subred. La puerta de enlace o gateway. 79 80 Servicio DHCP en Windows NT Otros parametros adicionales, como el sujo del dominio DNS (Domain Name Sys- tem), o el propio servidor DNS. En una red pueden convivir equipos que sean clientes DHCP con otros cuya conguracion se haya establecido manualmente1 . Aquellos que esten congurados como clientes DHCP necesitaran encontrar en la red local un servidor DHCP para que les proporcione sus parametros TCP/IP. Cuando un cliente DHCP arranca por primera vez, lanza por la red un mensaje de difusion2, solicitando una direccion IP. Si en la red existe un solo servidor DHCP, cuando este reciba el mensaje contestara al cliente asociandole una direccion IP (junto con el resto de parametros). En concreto, el servidor DHCP puede estar congurado para asignar al cliente una direccion IP cualquiera de las que tenga disponibles, o bien para asignarle una direccion en concreto (o direccion reservada), en funcion de la direccion fsica ethernet del cliente. En cualquiera de ambos casos, una vez el cliente recibe el mensaje del servidor, ya tiene una conguracion IP con la que poder acceder a la red de forma normal. Si en la red hay mas de un servidor DHCP, es posible que dos o mas servidores escuchen la peticion, y le contesten. Entonces, el primer mensaje que recibe el cliente es aceptado, y el resto son rechazados. Es muy importante resaltar que cuando hay varios servidores DHCP en una misma red local, estos no se comunican entre ellos para saber que direcciones IP debe asignar cada uno. Es responsabilidad de los administradores que sus conguraciones sean independientes y consistentes. Es decir: Cuando en una misma red TCP/IP existe mas de un servidor DHCP, es imprescindible que esten congurados de manera que no puedan asignar la misma direccion IP a dos ordenadores distintos. Para ello basta que los rangos de direcciones IP que puedan proporcionar no tengan direcciones comunes, o, si las tienen, que estas sean direcciones reservadas. En cualquiera de los casos anteriores, desde el punto de vista del cliente los parametros que ha recibido se consideran una concesion, es decir, son validos durante un cierto tiempo. Cada vez que el cliente arranca, o bien cuando se alcanza el lmite de la concesion (lease time) el cliente tiene que solicitar su renovacion. Cuando el servidor recibe este mensaje de renovacion puede hacer dos cosas: a) Renovar la concesion al cliente durante otro intervalo de tiempo, o bien b) Denegar la concesion, con lo que la direccion IP del cliente pasa al conjunto de direcciones disponibles del servidor, y el cliente es forzado a solicitar otra direccion, de nuevo mediante una difusion. 1 Siempre que no haya repeticiones entre las IPs que reciben los clientes DHCP y las que poseen los equipos congurados manualmente. 2 Una difusion (o broadcast) es un mensaje que se enva de una sola vez a todas las maquinas presentes en la red local. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 81 11.2 Concepto de Ambito A criterio del administrador, existe la posibilidad de que la concesion de ciertos equipos (o de todos) se especique como \sin lmite", con lo que la direccion pasa a estar asociada a la maquina (que la adquiera) para siempre. El protocolo DHCP es especialmente util cuando el parque de equipos de una organizacion se distribuye en varias subredes fsicas, y ademas los equipos cambian de ubicacion (de subred) con cierta frecuencia. En este caso, cambiar el equipo de sitio no supone nunca recongurar manualmente sus parametros de red, sino simplemente conectarlo a la nueva red y arrancarlo. 11.2 Concepto de Ambito En el contexto de DHCP, un ambito (scope) se dene como una agrupacion administrativa de direcciones IP que posee una serie de parametros de conguracion comunes y que se utiliza para asignar direcciones IP a clientes DHCP situados en una misma red fsica. Es decir, para que un servidor DHCP pueda asignar direcciones IP a sus potenciales clientes, es necesario que dena al menos un ambito en cada red fsica en la que haya clientes que atender. El administrador debe establecer para dicho ambito sus parametros de conguracion, tales como el rango de direcciones IP que puede asignar, las direcciones excluidas, la mascara de red3 , el lmite de tiempo que los equipos pueden disfrutar de la concesion, etc. En cualquier caso, para que un servidor DHCP pueda atender varias redes fsicas distintas interconectadas, es necesario que este conectado a dichas redes, o bien que los encaminadores utilizados tengan la capacidad de encaminar los mensajes del protocolo DHCP entre dichas redes. De no ser as, es necesario utilizar un servidor DHCP distinto en cada red. En cada ambito solo se admite un rango consecutivo de direcciones IP. Si todas las direcciones de dicho rango no deben ser asignadas, es posible tambien denir subrangos (o direcciones individuales) que deban ser excluidos del rango. 11.3 Instalacion del Servidor y de los Clientes DHCP en NT Para instalar este servicio, se debe ir al Panel de Control de Windows NT Server, y dentro del mismo, abrir la conguracion de red. Entonces se nos presenta en pantalla un cuadro con diversas pesta~nas (Identificacion, Servicios, Protocolos, etc.). En la pesta~na Servicios se puede observar que servicios de red proporciona el sistema actualmente. Entonces se debe pinchar en el boton Agregar..., y buscar en la lista el servicio DHCP. 3 Puesto que cada ambito solo puede servir para congurar clientes situados en una misma red fsica, la mascara de subred de cada ambito es unica. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 82 Servicio DHCP en Windows NT Una vez hecho esto, se nos pedira que reiniciemos el equipo. A partir de ese momento se a~nade al menu Herramientas Administrativas (comun) la aplicacion Adminstrador DHCP, con la que podremos empezar a congurar el servicio. Respecto a los clientes, lo unico que se debe hacer es ir a Panel de control/ Red/ Protocolos, seleccionar el protocolo TCP/IP, y pinchar en el boton Propiedades. En el cuadro de dialogo que se muestra entonces hay que especicar \obtener una direccion IP de un servidor DHCP". Habra que eliminar entonces el resto de parametros de la conguracion del protocolo, puesto que el cliente los adquirira del servidor. 11.4 El Administrador DHCP de NT El administrador DHCP es la herramienta administrativa que permite congurar el servicio DHCP en NT. Este servicio solo puede ser instalado en Windows NT Server. El servicio DHCP en Windows NT permite examinar cada uno de los casi 70 parametros relacionados con TCP/IP denidos en el protocolo, pero en realidad solo se pueden especicar (y proporcionar a los clientes) los siguientes ocho parametros: 1) Direccion IP. 2) Mascara de subred. 3) Puerta de enlace. 4) Servidor(es) DNS. 5) Nombre (sujo) del dominio DNS. 6) Tipo de nodo WINS/NBT (ver Captulo 10). 7) Servidor WINS (ver Captulo 10). 8) Tiempo de concesion (lease time), tiempo de renovacion (renewal time), y tiempo de reconexion (rebinding time). Estos tiempos especican cuando un cliente debe solicitar la renovacion de su concesion al servidor DHCP. Los dos ultimos tiempos se calculan en funcion del primero. La mayora de las opciones de DHCP anteriores pueden establecerse a nivel global, o bien para un ambito en particular, o incluso para un equipo concreto. Es posible tambien asignar una direccion IP ja a cada equipo, asociando dicha direccion a una direccion fsica ethernet (asignada por el fabricante de la tarjeta, y que es por denicion distinta para cada una). c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 83 11.5 La Utilidad ipconfig 11.5 La Utilidad ipconfig Existe un mandato en Windows NT que permite observar la conguracion IP de un equipo: ipconfig. Esta orden se ejecuta normalmente con la opcion /all, que permite ver todas las caractersticas de la conguracion. La Figura 11.1 muestra un ejemplo de la ejecucion de esta utilidad. Figura 11.1: Ejemplo de la utilidad ipconfig. En el caso de un cliente DHCP, mediante ipconfig tambien se puede solicitar manualmente la renovacion de la concesion, y la liberacion de la direccion actual (lo que provoca una difusion para solicitar una nueva direccion IP). Para ello se utilizan las opciones /renew y /release, respectivamente. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 Anexo I: Documentacion de DNS Captulo 2 Cuestiones sobre redes TCP/IP Vamos a entrar en los detalles que deben tenerse en cuenta cuando se conecta una maquina Linux a una red TCP/IP. De este modo, hablaremos de direcciones IP, nombres y cuestiones sobre el encaminamiento. Este captulo le ense~nara la base con la que podra entender los pasos para su conguracion particular, pasos que son cubiertos exhaustivamente en otros captulos. 2.1 Interfaces de Red Para ocultar la diversidad de hardware que puede usarse en una red, TCP/IP dene una interfaz a traves de la que accedemos al hardware. Esta interfaz ofrece un conjunto de operaciones identicas en cualquier tipo de hardware y que basicamente consisten en operaciones para enviar y recibir paquetes. Para cada dispositivo que quiera utilizarse para conectarse a la red, se mantendra en el nucleo del sistema la correspondiente interfaz. Por ejemplo, las interfaces con Ethernet en Linux son eth0 y eth1, mientras que las interfaces SLIP se llaman sl0, sl1, etcetera. Estos nombres de interfaz se deben conocer durante la conguracion de la red, cuando queramos referirnos a un dispositivo hardware concreto. Para que podamos usarlo en una red TCP/IP, la interfaz debera tener asignada una direccion IP que sirva como identicacion de esta ante los demas ordenadores de la red. Esta direccion es diferente del nombre de interfaz considerado anteriormente; puede realizarse la siguiente analoga: la interfaz sera la \puerta" de su sistema, mientras que la direccion vendra a ser un numero enmarcado y colgado de la \puerta". Por supuesto, hay otros parametros congurables para cada dispositivo, como el numero maximo de datagramas que pueden ser procesados por el dispositivo, conocido como Unidad 19 2.2. Direcciones IP 20 de Transferencia Maxima o MTU1 . Otros parametros seran introducidos mas tarde. 2.2 Direcciones IP Como se dijo en el captulo anterior, las direcciones utilizadas en el protocolo de red IP la forman numeros de 32 bits, cada maquina debe tener una direccion propia. Si las maquinas se encuentran en una red TCP/IP que no se conecta a otras redes, dichas direcciones podran asignarse a las maquinas librememente. Sin embargo, si las maquinas se conectan a Internet, las direcciones de los ordenadores seran asignadas por una autoridad principal, el NIC o Centro de Informacion de la Red2 . Para facilitar la lectura, las direcciones IP se dividen en cuatro numeros de 8 bits llamados octetos. Por ejemplo, si la maquina quark.physics.groucho.edu tiene una direccion IP 0x954C0C04, normalmente la escribiremos con la notacion de puntos divisorios, que separa cada octeto, de esta forma: 149.76.12.4. Otra razon para usar esta notacion es que las direcciones IP se pueden dividir en el numero de red y el numero de nodo. Cuando pedimos al NIC un conjunto de direcciones, este organismo nos concedera, no una direccion para nuestra maquina, sino un rango de direcciones validas, que en realidad es un numero de red concreto (el numero de nodo lo pondremos nosotros, contando con todos esos nodos disponibles). Dependiendo del tama~no de la red, la parte de la direccion correspondiente al nodo puede ser mas o menos grande. Para adaptarse a diferentes necesidades, se conceden diferentes clases de redes, que denen diferentes maneras de dividir la direccion IP en parte de red y parte del nodo. Clase A La clase A comprende redes desde 1.0.0.0 hasta 127.0.0.0. El numero de red esta en el primer octeto, con lo que solo hay 127 redes de este tipo, pero cada una tiene 24 bits disponibles para identicar a los nodos, lo que se corresponde con poder distinguir en la red unos 1.6 millones de nodos distintos. Clase B La clase B comprende redes desde 128.0.0.0 hasta 191.255.0.0; siendo el numero de red de 16 bits (los dos primeros octetos. Esto permite 16320 redes de 65024 nodos cada una. Clase C Las redes de clase C tienen el rango de direcciones desde 192.0.0.0 hasta MTU son las siglas de \Maximum Transfer Unix" Frecuentemente, las direcciones IP le seran asignadas directamente por el proveedor que le conecte a la red. No obstante, se puede contactar directamente con el NIC para obtener direcciones, escribiendo a [email protected]. 1 2 2.3. Resolucion de direcciones 21 223.255.255.0, contando con tres octetos para identicar la red. Por lo tanto, hay cerca de 2 millones de redes de este tipo con un maximo de 254 nodos cada una. Clases D, E, y F Comprenden las direcciones entre 224.0.0.0 y 254.0.0.0, y estan reservadas para uso futuro, o con nes experimentales. No especican, pues, ninguna red de Internet. Volviendo al ejemplo del captulo anterior, veremos que en la direccion 149.76.12.4 de la maquina quark, 12.4 es el identicativo del nodo dentro de la red de clase B 149.76.0.0. Se puede observar que en la lista anterior no se consideraban todas las posibilidades en la parte que identica al nodo, concretamente, se excluan siempre el identicador 0 y el 255. Estos dos identicadores se reservan con proposito especial. Una direccion con los bits del nodo a cero identica a la red, mientras que si tiene todos los bits a uno, identica a todos los nodos de la red (lo que se conoce como direccion de broadcast, lo que indica que un mensaje enviado a esa direccion sera interpretado por todos los nodos de la red). As pues, en nuestro ejemplo la direccion de la red sera 149.76.0.0 y la de broadcast, la 149.76.255.255. Ademas, otras dos direcciones de red estan reservadas: la 0.0.0.0 y la 127.0.0.0. La primera se conoce como direccion de encaminamiento por defecto, y la segunda, como direccion de loopback. El encaminamiento por defecto se utiliza para saber a donde enviar los datagramas por defecto, tema que abordaremos despues. La red 127.0.0.0 se reserva para el traco local, dirigido al propio nodo. Normalmente, se asigna la direccion 127.0.0.1 a un dispositivo de la maquina llamado interfaz de loopback o de circuito cerrado. Cualquier paquete enviado a esa direccion sera recibido por el propio nodo, esto permite probar aplicaciones de red con uno mismo, sin estar conectado a una red \real". Otra aplicacion util es la de ejecutar aplicaciones de red que afectan solo al nodo local, por ejemplo, muchos sistemas UUCP no tienen conexion IP pero ejecutan un sistema de noticias INN. Para que esto funcione, INN utiliza la interfaz de loopback. 2.3 Resolucion de direcciones Ahora que conocemos que son las direcciones IP, nos preguntamos como se utilizan en una red Ethernet. Despues de todo, en una red de este tipo, el protocolo Ethernet usa direcciones identicativas de seis octetos que no tienen que ver con los numeros IP. En efecto, se necesita un mecanismo de traduccion de direcciones IP a direcciones Et- 2.4. Encaminamiento IP 22 hernet o fsicas. Esto se hace con el Protocolo de Resolucion de Direcciones o ARP3 . De hecho, ARP no se limita a las redes Ethernet, sino que se extiende a otros tipos de redes como las de radio paquetes. La idea es la misma que tendramos para localizar al se~nor X entre 150 personas: preguntar por su nombre a todo el mundo; y el se~nor X nos respondera. Cuando queremos localizar la direccion fsica correspondiente a una direccion IP, haremos uso de una caracterstica de la red Ethernet que es la posibilidad de enviar mensajes a escuchar por todos los nodos, o mensajes broadcast. En el mensaje ARP, que es de este tipo, se incluye la direccion IP cuyo propietario estamos buscando. El nodo que posea esa direccion enviara una respuesta ARP al nodo llamante, con la direccion fsica suya. Por supuesto, le preocupara saber como puede funcionar esto para localizar un nodo entre millones de Ethernets conectadas en el mundo. Esto se trata en la proxima seccion: se trata del encaminamiento. Sigamos hablando, de momento, sobre ARP. Una vez que se conoce la direccion fsica del nodo, el que hizo la peticion guardara la informacion obtenida en una cache ARP, para as no preguntar por lo mismo cada vez que enve un paquete a ese nodo. Sin embargo, no podemos guardar esa direccion para siempre ya que puede perder su validez (por ejemplo, si cambiamos la tarjeta de red a los nodos por avera, sus nuevas direcciones fsicas seran distintas). Por ello, cada cierto tiempo, lo que hay en la cache ARP pierde su validez, obligando a realizar de nuevo la pregunta ARP. A veces, un nodo necesita tambien conocer su direccion IP a partir de su direccion fsica. Por ejemplo, en terminales X o PCs sin disco, que cuando arrancan solo saben la direccion de su tarjeta pues esta grabada en memoria no volatil. Para ello, se usa el protocolo de Resolucion Inversa de Direcciones o RARP4 : la peticion RARP la hace el nodo cuando arranca, mediante mensaje broadcast, y es contestado por un servidor de direcciones que, a partir de la direccion fsica, consulta su base de datos y conoce la direccion IP correspondiente. Existe ademas otro protocolo, el BOOTP o protocolo de arranque, que permite a las maquinas sin disco conocer como ponerse en marcha en la red. 2.4 Encaminamiento IP 2.4.1 Redes IP 3 Cuando escribimos una carta a alguien, normalmente incluimos la direccion completa en el sobre: pas, provincia, codigo postal, etc. De este modo el servicio de correos podra llevar la carta a su destino: un servicio la enviara al del pas que corresponda, y este ultimo la 3 4 Address Resolution Protocol Reverse Address Resolution Protocol 2.4. Encaminamiento IP 23 entregara al de la provincia o ciudad de destino. La ventaja de este esquema jerarquico es que el servicio postal del remitente apenas tiene que saber acerca del destino nal, sino solo a que pas entregarla. Las redes IP se organizan de manera similar. Internet consta de varias redes, conocidas como sistemas autonomos y cada una realiza por su cuenta el encaminamiento interno entre sus nodos miembro. Cuando un paquete tiene como destino un nodo de otra red, se entregara al encaminador correspondiente, sin preocuparse del destino nal del paquete. 2.4.2 Subredes La estructura de subredes se obtiene al dividir las direcciones IP en parte del nodo y parte de la red, como ya hemos explicado. Por defecto, la red de destino se deriva de la parte de red de la direccion IP. Es decir, los nodos con la misma direccion de red se encontraran en la misma red TCP/IP5 . Pero en una red puede interesar hacer una division en cientos de peque~nas redes, por ejemplo segmentos de Ethernet. Para ello se subdivide la red en subredes. Una subred tiene la responsabilidad de la entrega de los datagramas a un determinado rango de direcciones IP de la red en la que se encuentra. Como sucede con las clases A, B o C, se identica en la parte del numero IP correspondiente a la red. Sin embargo, esa parte incluira ahora algunos bits de la parte del nodo. Los bits que se interpretan como direccion de subred se obtienen con la llamada mascara de red. Es un numero de 32 bits que especica una mascara para identicar los bits de la subred. Parte de la Red Parte del Nodo 149 76 12 4 149 76 12 4 Parte de la Red Parte del Nodo Figura 2.1: Division de una red clase B en subredes La red del campus de la Universidad de Groucho Marx es un ejemplo de red de clase B, poseedora de la red 149.76.0.0, con mascara 255.255.0.0. Internamente, la red de la UGM se divide en peque~nas subredes, como las LAN de cada 5 Los sistemas autonomos son algo mas generales. Pueden tener mas de una red IP. 2.4. Encaminamiento IP 24 departamento. Concretamente se divide en 254 subredes, desde la 149.76.1.0 hasta la 149.76.254.0. Por ejemplo, el Departamento de Fsica Teorica tendra asignada la subred 149.76.12.0. La dorsal del campus es en s mismo una subred, la 149.76.1.0. Las subredes comparten el msmo numero de red, pero se usa el tercer octeto de esta para distinguir las distintas subredes. Por lo tanto, tendran una mascara de subred igual a 255.255.255.0. En la gura 2.1 se muestra como el nodo quark (149.76.12.4) se ve de distinta forma segun se vea desde el punto de vista de la red de clase B, o desde el punto de vista de las subredes. Debe notarse que la division en subredes es visible solo internamente a la red. Normalmente, las organiza el administrador de red para reejar diferentes ubicaciones geogracas, distinguir segmentos de red, o bien por motivos administrativos (departamentos, redes de alumnos, etc). Pero esta division es totalmente invisible desde fuera de la organizacion. 2.4.3 Pasarelas La organizcion en subredes no solo se hace por motivos administrativos, tambien es consecuencia de cuestiones del hardware. Lo que ve un nodo en una red es limitado: solo ve los nodos con los que directamente este conectado (por ejemplo, en la Ethernet), mientras que a los demas los accede a traves de lo que se conoce como pasarela o gateway. Una pasarela es un nodo conectado a dos o mas redes fsicas, congurado para pasar paquetes de una red a otra. Para reconocer si una direccion IP se encuentra en la red local fsica, cada LAN debe tener una direccion de red IP diferente. Por ejemplo, las maquinas de la (sub)red 149.76.4.0 seran las que estan en la LAN del Departamento de Matematicas. Cuando se enva un datagrama a la maquina quark, el software de red de erdos ve que su direccion de red es otra (149.76.12.4) con lo que sabe que tiene que enviar los datagramas a traves de la pasarela (sophus por defecto). sophus se encuentra conectado a dos subredes: la del Departamento de Matematicas y la de la dorsal del campus, accediendo a cada una a traves de una interfaz diferente, respectivamente eth0 y fddi0. Nos preguntaremos entonces, que direccion IP debe tener la pasarela, una de la subred de Matematicas o bien una de la dorsal. Pues bien, la respuesta es ambas. Cuando la pasarela comunique con un nodo de la LAN de Matematicas, usara la direccion 149.76.4.1, mientras que si lo hace con un nodo de la dorsal, usara 149.76.1.4. Es decir, la pasarela tiene tantas direcciones IP como conexiones a redes fsicas tenga. En denitiva, este sera el esquema de interfaces, direcciones y mascara de sophus, nuestra pasarela: 2.4. Encaminamiento IP 25 interfaz direccion mascara eth0 149.76.4.1 255.255.255.0 fddi0 149.76.1.4 255.255.255.0 lo 127.0.0.1 255.0.0.0 La ultima entrada describe el dispositivo loopback, que se comento anteriormente. En la gura 2.2 se muestra una parte de la topologa de la red de la Universidad de Groucho Marx (UGM). Los nodos que estan en dos subredes tendran dos direcciones IP. Departamento de Matematicas 4.23 gauss Departamento de Fsica Teorica 4.17 4.0 12.4 12.0 erdos 4.1 sophus 1.4 Dorsal del Campus quark 12.1 1.12 1.1 niels gcc1 2.1 1.0 Centro de Calculo de la UGM Figura 2.2: Vista parcial de la topologa de la red de la UGM. 2.4.4 Tablas de Encaminamiento Vamos ahora a centrarnos en como se selecciona una pasarela para entregar un datagrama a una red remota. Hemos visto que erdos, cuando enva un datagrama para quark, comprueba que la direccion destino no se encuentra en la red local, por lo que lo enva a la pasarela, sophus, 2.4. Encaminamiento IP 26 quien basicamente hace lo mismo: ve que quark no esta en una de las redes a las que se conecta directamente y busca otra pasarela a quien entregarle el paquete. La eleccion correcta es niels, la pasarela del Departamento de Fsicas. sophus necesita informacion para poder tomar estas decisiones. La informacion de encaminamiento que se usa en IP es basicamente una tabla donde se relacionan (sub)redes y pasarelas. Ademas, debe incluirse una entrada de encaminamiento por defecto, que se asocia en la tabla a la red 0.0.0.0. Todos los paquetes que van a una red desconocida, se enviaran a la pasarela del encaminamiento por defecto. As pues, esta sera la tabla para sophus: Red Pasarela 149.76.1.0 - Interfaz ... ... fddi0 149.76.2.0 149.76.1.2 fddi0 149.76.3.0 149.76.1.3 fddi0 149.76.4.0 eth0 149.76.5.0 149.76.1.5 fddi0 0.0.0.0 ... 149.76.1.2 fddi0 Las rutas a una red a la que sophus este directamente conectado no necesitan pasarela, sino que los datagramas se entregan directamente. Esto se indica en la tabla anterior cuando en lugar de la pasarela aparece un \-". Las tablas de encaminamiento pueden construirse de varias formas. Para redes peque~nas, sera mas eciente construirlas a mano usando el comando route del Linux (vease el captulo 5). Para redes mas grandes, las tablas se mantienen y modican automaticamente mediante los demonios de encaminamiento. E stos corren en nodos centrales e intercambian informacion de encaminamiento entre ellos para tener en todo momento las rutas \optimas" entre subredes. Dependiendo del tama~no de la red, se utilizan distintos protocolos de encaminamiento. Dentro de los sistemas autonomos (como la Universidad Groucho Marx) se utilizan los protocolos internos o IGP6 . El mas utilizado es RIP7 o protocolo de informacion de encaminamiento, que implementa el demonio routed de BSD. Para encaminamiento entre redes se usan protocolos EGP8 , como BGP. Se implementan en programas como gated de la Universidad de Cornell.9. Internal Gateway Protocol Routing Information Protocol 8 External Gateway Protocol 9 gated tambien implementa RIP y en general se recomienda usarlo en lugar de routed 6 7 2.5. Protocolo de Mensajes de Control de Internet (ICMP) 27 2.4.5 Metricas de Encaminamiento El encaminamiento dinamico basado en RIP elige la mejor ruta a un determinado nodo o red a partir del numero de \saltos", es decir, las pasarelas que tiene que atravesar el datagrama hasta llegar a su destino. La ruta mas corta sera la elegida, y si hay 16 o mas saltos se descartara por exceso de distancia. Para usar RIP tiene que ejecutar gated en todas las maquinas. Al arrancar, gated comprueba cuantas interfaces estan activas. Si hay mas de una (sin contar la de loopback) asumira que el nodo es una pasarela. Si no, entrara en modo pasivo, dedicandose a recibir cualquier actualizacion RIP y cambiando sus tablas en consecuencia. Para enviar a las demas pasarelas la informacion de su tabla local de rutas, gated cuenta la longitud de cada una a partir de una metrica especca (que es decidida por el administrador del sistema y debe reejar el coste de esa ruta). As, la metrica de una ruta a una subred con conexion directa sera siempre cero, mientras que una ruta que atraviese dos pasarelas debera tener un coste de dos. 2.5 Protocolo de Mensajes de Control de Internet (ICMP) IP tiene otro protocolo aun no mencionado. Es el protocolo de mensajes de control de Internet o ICMP10 , y lo usa el software de gestion de red para comunicar mensajes de error entre nodos. Por ejemplo, si estamos en la maquina erdos y hacemos un telnet al puerto 12345 del nodo quark y no hay procesos escuchando en ese puerto, recibira un mensaje ICMP de \puerto inalcanzable". Hay mas mensajes ICMP, muchos de ellos referidos a condiciones de error. Sin embargo, hay uno interesante que es el de redireccion. Lo genera el modulo de encaminamiento al detectar que otro nodo esta usandolo como pasarela, a pesar de existir una ruta mucho mas corta. Por ejemplo, tras congurarse la tabla de encaminamiento de sophus, esta puede estar incompleta, conteniendo rutas a traves del encaminador por defecto gcc1. Por lo tanto, los paquetes enviados inicialmente a quark iran por gcc1 en lugar de niels. En este caso gcc1 noticara a sophus que esta usando una ruta costosa y reenviara el datagrama a niels, al mismo tiempo que devolvera un mensaje ICMP de redireccion a sophus informandole de la nueva ruta. Con lo visto, queda claro que se puede evitar tener que establecer las rutas a mano. Sin embargo, usar solo esquemas de encaminamiento dinamico no es siempre una buena idea. La redireccion de ICMP y el protocolo RIP no incluyen mecanismos de vericacion de la autenticidad de los mensajes. Esto permite a los piratas corromper el traco de la 10 Internet Control Message Protocol 2.6. El sistema de nombres DNS 28 red mediante mensajes ICMP. Por ello, algunas versiones del codigo de Linux tratan los mensajes de redireccion que afectan a rutas de red como si fueran redirecciones de rutas a nodos. 2.6 El sistema de nombres DNS 2.6.1 Resolucion de nombres 3 Como se comento antes, el direccionamiento en TCP/IP se basa en numeros de 32 bits. Evidentemente, esos numeros no son faciles de recordar, mientras que s lo es el nombre que se le asigna a cada maquina, como gauss o strange. Existe una aplicacion que es capaz de traducir nombres a direcciones IP, es conocida como sistema de resolucion de nombres o DNS11 . Una aplicacion que desee encontrar la direccion IP correspondiente a una maquina de la que conoce su nombre, no tiene que incluir rutinas para ello, ya que en las libreras estandares (libc ) existen ya rutinas preparadas, como gethostbyname(3) o gethostbyaddr(3). En otros sistemas se encuentran en otras libreras distintas de la libc pero esto no sucede en Linux. Al conjunto de rutinas que hacen estas tareas se les conoce como \sistema de resolucion". En una red peque~na no es difcil mantener una tabla /etc/hosts en cada maquina, y modicarla al agregar, eliminar o modicar nodos. Aunque resulta complicado cuando hay muchas maquinas ya que, en principio, cada una necesita una copia de /etc/hosts. Una solucion a esto es compartir esta y otras bases de datos con el NIS, o sistema de informacion de red 12 , desarrollado por Sun Microsystems y conocido tambien como paginas amarillas. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS central y los clientes accederan a ellas de forma transparente al usuario. En todo caso, esta solucion solo es aconsejable para redes peque~nas o medianas, ya que implican mantener un chero central /etc/hosts que puede crecer mucho, y luego distribuirlo entre los servidores NIS. En Internet, se comenzo almacenando la informacion en un chero similar al hosts, mantenido por el NIC, y obtenido regularmente por los demas servidores. Cuando la red crecio comenzaron los problemas de sobrecarga de servidores, ademas de que el NIC tena que ocuparse de todos los nombres de los nodos de internet, y evitar la duplicidad de los mismos. 11 12 Domain Name System Network Information System 2.6. El sistema de nombres DNS 29 Por esto, en 1984 se dise~no y adopto ocialmente un nuevo sistema, el DNS o sistema de nombres por dominios, dise~nado por Paul Mockapetris. 2.6.2 Introduccion al DNS DNS organiza los nombres de los nodos en una jerarqua de dominios. Un dominio es una coleccion de nodos relacionados de alguna manera, como estar en la misma red o pertenecer a una misma organizacion o pas. Por ejemplo, las universidades norteamericanas se agrupan en el dominio edu, y cada universidad mantiene un subdominio dentro de edu. Nuestro ejemplo, la Universidad de Groucho Marx, mantendra el dominio gmu.edu y las maquinas del departamento de Matematicas se encontraran dentro del dominio maths.gmu.edu. De modo que el nombre completo de la maquina erdos sera erdos.maths.gmu.edu. El nombre completo se conoce como nombre totalmente cualicado o FQDN13 , e identica a ese nodo en todo el mundo. . com edu net groucho maths gauss erdos physics sophus quark theory otto collider niels up down strange Figura 2.3: Parte del espacio de dominios En la gura 2.3 se muestra una seccion del espacio de dominios. La entrada de la raz del arbol, que se indica con un punto, se puede denominar dominio raz, y agrupa al resto de los dominios. Para indicar que un nodo se expresa en notacion FQDN, se puede terminar el nombre en un punto, indicando as que el nombre incluye al del dominio raz. Dependiendo de su localizacion en la jerarqua, un dominio puede ser de primer, segundo o tercer nivel. Pueden existir otros niveles pero no son frecuentes. Por ejemplo, algunos dominios de primer nivel muy usuales son los siguientes: 13 Fully Qualied Domain Name 2.6. El sistema de nombres DNS 30 edu Aqu se incluyen casi todas las universidades o centros de investigacion norteamericanos. com org Compa~nas u organizaciones con nes comerciales. net mil gov uucp Pasarelas y otros nodos administrativos de la red. Organizaciones no comerciales. Las redes UUCP privadas se encuentran aqu. Nodos militares norteamericanos. Nodos del gobierno norteamericano. Ocialmente, todos los nombres de nodos UUCP sin dominio han sido movidos a este nuevo dominio .uucp. En general, los dominios anteriores pertenecen a redes norteamericanas. Algo especialmente cierto con los dominios mil o gov. Fuera de los Estados Unidos, existe un dominio de primer nivel para cada pas, de dos letras segun se dene en la norma ISO-3166. Finlandia, por ejemplo, usa el dominio ; el dominio de corresponde a Alemania y el dominio es corresponde a Espa~na. Cada pas organiza por debajo del primer nivel, los dominios de segundo nivel, de manera parecida a los americanos en algunos casos (por ejemplo, con dominios com.au o edu.au) o directamente por organizaciones, como sucede en Espa~na (con dominios como upm.es para la Universidad de Politecnica de Madrid). Por supuesto, un nodo dentro del dominio de un pas puede no estar fsicamente en el. El dominio unicamente identica al nodo como registrado en el NIC de ese pas. As, un comerciante sueco puede tener una delegacion en Australia, y tener sus nodos australianos registrados dentro del dominio de primer nivel sueco, se. Esta organizacion por dominios soluciona el problema de la unicidad de nombres. Ademas, los nombres totalmente cualicados no son difciles de recordar. Pero DNS tiene otras ventajas: permite delegar la autoridad sobre un determinado subdominio a sus administradores. Por ejemplo, los subdominios maths y physics de la UGM son creados y mantenidos por el Centro de Calculo de dicha universidad. Y si el mantenimiento del subdominio maths.gmu.edu fuese complicado (por numero elevado de nodos, existencia de subdominios internos, etc), el Centro de Calculo de la UGM puede delegar la autoridad sobre ese subdominio al departamento de Matematicas. La delegacion de un subdominio implica el control total del mismo por parte de la organizacion en la que se delego, con total libertad para crear nuevos subdominios internos, asociar nombres 2.6. El sistema de nombres DNS 31 a nodos, etc. Para este n, el espacio de nombres se divide en zonas, cada una asociada a un dominio. Notese que existe una diferencia entre zona y dominio: el dominio groucho.edu incluye todos los nodos de la UGM, mientras que la zona groucho.edu incluye solo los nodos que mantiene directamente el Centro de Calculo, ya que los nodos del subdominio physics.groucho.edu pertenecen a la zona controlada por el Departamento de Fsicas. En la gura 2.3 se marca el inicio de una zona con un peque~no crculo a la derecha del nombre del dominio. 2.6.3 Busquedas de nombres con DNS Trataremos aqu el problema de como resolver el nombre de un determinado nodo. DNS es una gigantesca base de datos distribuda. Se implementa a traves de los llamados servidores de nombres. Cada uno de estos mantiene la informacion de uno o varios dominios. Para cada zona hay al menos dos (o mas) servidores de nombres que mantienen informacion autorizada sobre los nodos de esa zona. Para obtener la direccion IP del nodo erdos, lo que hay que hacer es contactar con el servidor de nombres de la zona para groucho.edu y este nos devolvera los datos pedidos. Esto parece facil de decir pero difcil de implementar pues nos preguntaremos como localizar al servidor de nombres de la UGM. Si su ordenador no implementa un adivino, le ayudara el DNS. Cuando su aplicacion desea encontrar informacion acerca de erdos, contactara en primer lugar con un servidor de nombres local, quien realizara una busqueda por otros servidores. Empieza por preguntar a un servidor de nombres raz por erdos.maths.groucho.edu. Al comprobar este ultimo que el no mantiene ese dominio, contactara con los servidores del dominio edu y les preguntara las direcciones de los servidores de nombres, que retornara al servidor local. Ahora nuestro servidor preguntara a estos ultimos y estos a su vez iran haciendo llegar a nuestro servidor hasta los que mantienen la zona groucho.edu. Finalmente, se preguntara a uno de estos ultimos por el nodo erdos y se enviara la respuesta al usuario. Aparentemente esto provoca mucho traco, aunque en todo caso siempre sera menor que preguntar siempre a los mismos servidores que mantenan el chero HOSTS.TXT antes de que se dise~nara el DNS. Sin embargo, aun se puede mejorar algo mas. La informacion obtenida en una busqueda puede que se necesite despues. Por ello, el servidor de nombres local la guardara en una cache local. As, cuando volvamos a preguntar por un nodo de groucho.edu, el servidor local ya podra dirigirse directamente el servidor de nombres de esa zona sin pasar por los servidores raz. 2.6. El sistema de nombres DNS 32 Por supuesto, el servidor de nombres no puede mantener la cache eternamente, sino descartarla cada cierto tiempo. Este tiempo de expiracion se conoce como TTL14 o tiempo de vida. En la base de datos del DNS queda especicado este parametro. 2.6.4 Servidores de Nombres Cuando un servidor de nombres mantiene toda la informacion acerca de una zona se le llama autorizado para esa zona. Cualquier peticion para esa zona sera enviada a uno de esos servidores maestros. Para tener una representacion coherente de la zona, sus servidores maestros deben estar sincronizados. Para ello, a uno de ellos se le nombra servidor primario, que obtiene la informacion de zona a partir de unos cheros locales, y a los demas se les nombra servidores secundarios. Estos ultimos cargan la informacion de la zona pidiendosela al primario cada cierto tiempo. Las razones para que existan varios servidores autorizados por cada zona son dos: repartir la carga de trabajo y lograr tolerancia a fallos. As, si un servidor cae, todas las peticiones se repartiran entre los demas servidores autorizados que haya. Por supuesto, esto no protege contra fallos internos o bugs del propio software DNS. Por supuesto, tambien es posible tener servidores de nombres que no mantengan informacion autorizada de ningun dominio15. Este tipo de servidores es util pues, al mantener una cache con los nombres que resuelven disminuye la carga de la red y de otros servidores. 2.6.5 La Base de Datos DNS En las bases de datos del DNS se mantiene mas informacion que la necesaria para traducir nombres a direcciones IP. Dicho de otra forma, en DNS se mantienen distintos tipos de registros. Un elemento simple de informacion en el DNS se conoce como registro de recurso o RR. Cada registro tiene un tipo asociado a el, describiendo que clase de datos contiene, y una clase indicando el tipo de red al que se aplica. Se trata de acomodarse a diferentes esquemas de red, aunque para direcciones IP se usa siempre la clase IN (INternet), pero hay otras como las redes Hesiod (que se usan en el MIT16 ). El registro mas habitual es el de tipo A, que relaciona un nombre totalmente cualicado con una direccion IP. 15 Time To Live Aunque al menos debera tener informacion autorizada para el localhost y la resolucion inversa de 16 Instituto Tecnologico de Massachusets 14 127.0.0.1 2.6. El sistema de nombres DNS 33 Un nodo puede admitir mas de un nombre. Pero solo uno de ellos sera \ocial" o canonico, mientras que los demas son alias del primero. La diferencia es que el canonico se dene en un registro de tipo A, mientras que los alias se denen en registros CNAME que apuntan al nombre canonico. En un captulo posterior se trata todo esto en profundidad. Aqu nos vamos a limitar a ver algunos ejemplos. En la gura 2.4 se muestra una parte de la base de datos para la zona physics.groucho.edu. ; ; Informacion Autorizada de physics.groucho.edu @ IN SOA ( niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 1034 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl ) ; ; Servidores de nombres autorizados IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23 ; ; Fisica Teorica (subred 12) niels IN IN A A 149.76.12.1 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 ... ; Laboratorio Collider (subred 14) boson IN A 149.76.14.1 muon IN A 149.76.14.7 bogon IN A 149.76.14.12 ... Figura 2.4: Extracto del chero named.hosts del departamento de Fsicas. Ademas de los registros A y CNAME, se puede ver que hay un registro especial al principio del chero, con varias lneas. Se trata del registro SOA o de inicio de autoridad, que mantiene informacion general sobre el servidor de nombres. Por ejemplo, el tiempo de 2.6. El sistema de nombres DNS 34 vida por defecto de todos los registros que mantiene. Notese que aquellos nombres que no nalicen en un punto seran interpretados como relativos al dominio en cuestion. El nombre especial \@" usado en el registro SOA representa al dominio completo. Hemos visto que los servidores para el dominio groucho.edu deben tener conocimiento sobre los servidores de la zona physics para poder reenviarles las peticiones para esta. Esto se suele incluir en los registros NS que incluyen el nombre de los servidores en notacion FQDN, y un registro A que da la direccion IP para ese servidor. Vease, por ejemplo, la gura 2.5. ; ; Datos de zona para groucho.edu. @ IN SOA ( vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl ) .... ; ; Registros de la zona. physics IN IN NS NS niels.physics.groucho.edu. gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ... Figura 2.5: Extracto del chero named.hosts de la UGM. 2.6.6 Resolucion inversa Ademas de la obtencion de una direccion IP a partir del nombre, a veces interesa lo contrario: conocida la direccion, obtener el nombre canonico. Esto se conoce como traduccion inversa y la utilizan algunas aplicaciones de red para vericar la identidad del llamante. Cuando se usa un chero hosts, la resolucion inversa supone una simple busqueda en el mismo. En cambio, para el DNS se ha creado un dominio especial, el in-addr.arpa, que contiene direcciones de los nodos en notacion de puntos divisorios invertida. Por ejemplo, a la direccion IP 149.76.12.4 le corresponde el nombre 4.12.76.149.in-addr.arpa. El tipo de 2.6. El sistema de nombres DNS 35 registro para estos datos se llama PTR. Cuando se crea una zona de autoridad suele signicar que sus administradores tienen control total sobre como asignan sus nombres. Pero a una subred se le puede delegar un subdominio. Esto sucede con la UGM, donde se delega la zona de Fsicas (subdominio physics) al correspondiente Departamento. Las direcciones de resolucion inversa tambien se delegan. En la gura 2.6 se muestra el contenido del chero de zona para el servidor de la subred 12. Los registros \importantes" de delegacion se muestran en la gura 2.7. ; ; Dominio 12.76.149.in-addr.arpa @ IN SOA ( niels.physics.groucho.edu. hostmaster.niels.physics.groucho.edu. 233 360000 3600 3600000 3600 ) 2 IN PTR otto.physics.groucho.edu. 4 IN PTR quark.physics.groucho.edu. 5 IN PTR down.physics.groucho.edu. 6 IN PTR strange.physics.groucho.edu. Figura 2.6: Extracto del chero named.rev de la subred 12. Una importante consecuencia de esto es que las zonas solo pueden crearse como superconjuntos de redes IP, y ademas, las mascaras de red deberan redondearse a nivel de octeto. Es decir, las subredes de la UGM tendran una mascara 255.255.255.0, y para cada subred debera existir una zona in-addr.arpa. Sin embargo, si la mascara fuese 255.255.255.128, la creacion de zonas para la subred 149.76.12.128 sera imposible ya que no hay forma de decir en DNS que el dominio 12.76.149.in-addr.arpa ha sido dividido en dos zonas de autoridad, con nombres de nodos desde el 1 al 127, y desde el 128 al 255, respectivamente. 2.6. El sistema de nombres DNS 36 ; ; Dominio 76.149.in-addr.arpa domain @ IN SOA ( vax12.gcc.groucho.edu. hostmaster.vax12.gcc.groucho.edu. 233 360000 3600 3600000 3600 ) ... ; subred 4: Departamento de Matematicas 1.4 IN PTR sophus.maths.groucho.edu. 17.4 IN PTR erdos.maths.groucho.edu. 23.4 IN PTR gauss.maths.groucho.edu. ... ; subred 12: Departamento de fisicas, zona separada 12 IN IN NS NS niels.physics.groucho.edu. gauss.maths.groucho.edu. niels.physics.groucho.edu. IN gauss.maths.groucho.edu. IN A 149.76.12.1 A 149.76.4.23 ... Figura 2.7: Extracto del chero named.rev de la red 149.76. Legal Notice UNIX is a trademark of Univel. Linux is not a trademark, and has no connection to UNIXTM or Univel. c 1994 Olaf Kirch Copyright Kattreinstr. 38, 64295 Darmstadt, Germany [email protected] \The Linux Network Administrators' Guide" may be reproduced and distributed in whole or in part, subject to the following conditions: 0. The copyright notice above and this permission notice must be preserved complete on all complete or partial copies. 1. Any translation or derivative work of \The Linux Network Administrators' Guide" must be approved by the author in writing before distribution. 2. If you distribute \The Linux Network Administrators' Guide" in part, instructions for obtaining the complete version of \The Linux Network Administrators' Guide" must be included, and a means for obtaining a complete version provided. 3. Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. 4. If you print and distribute \The Linux Network Administrators' Guide", you may not refer to it as the \Ocial Printed Version". 5. The GNU General Public License referenced below may be reproduced under the conditions given within it. 6. Several sections of this document are held under separate copyright. When these sections are covered by a dierent copyright, the seperate copyright is noted. If you distribute \The Linux Network Administrators' Guide" in part, and that part is, in whole, covered under a seperate, noted copyright, the conditions of that copyright apply. Exceptions to these rules may be granted for academic purposes: Write to Olaf Kirch at the above address, or email [email protected], and ask. These restrictions are here to protect us as authors, not to restrict you as educators and learners. All source code in \The Linux Network Administrators' Guide" is placed under the GNU General Public License. See appendix C for a copy of the GNU \GPL." The author is not liable for any damages, direct or indirect, resulting from the use of information provided in this document. Anexo II: Actividades de Laboratorio DE SISTEMAS ADMINISTRACION ACTIVIDAD Instalaci on De Red Hat Linux Requerimientos iniciales Necesitamos inicialmente: Servidor Unix, con sistema de cheros en red (NFS). Im agenes de la instalacion de Red Hat Linux y parches disponibles. Disco de instalacion de Red Hat Linux. Alumnos: dos disquetes en blanco formateados para MS-DOS por ordenador para crear dos discos de arranque. Activaci on del disco extra ble 1. Apague el ordenador. 2. Inserte el disco extrable y fjelo con la llave. 3. Inicie el ordenador con el sistema Linux del disco interno. 4. Acredtese con su usuario y contrase~na. 5. Ejecute el mandato activa-hdc turno, siendo turno el correspondiente a su sesion. NO SE EQUIVOQUE. Ejecute este mandato sin argumentos para que muestre los turnos disponibles. 6. Recuerde que debe realizar esta activacion al principio de cada sesion de practicas. Instalaci on de RedHat Linux 1. Reiniciar el ordenador con el disco BOOTNET de RedHat. 2. El tipo de inicio (boot:) es text. 3. Seleccionar el idioma de la instalacion (al gusto). 4. Seleccionar el teclado es. 5. El metodo de instalacion es va NFS. 6. Congurar TCP/IP. (a) (b) (c) (d) (e) Direccion IP estatica. Asignar la direccion IP correspondiente al ordenador (158.42.54.[60+no ordenador]). Mascara: 255.255.128.0 Gateway: 158.42.1.10 Servidor de nombres (DNS): 158.42.49.82 1 2 Actividad: Instalacion De Red Hat Linux 7. Seleccion del servidor donde reside redhat. (a) Nombre o Direccion IP: adserver.dsic.upv.es (b) Directorio: /home/ftp/pub/redhat62 8. Tipo de instalacion: "Sistema personalizado". 9. Particiones y Sistema de Archivos. (a) Utilizar DiskDruid. (b) Editar la parcicion /dev/hdc1 indicando que su punto de montaje es '/boot'. (c) Editar la parcicion /dev/hdc3 indicando que su punto de montaje es '/'. 10. Formatear particiones. (a) Seleccionar hdc1 y hdc3. (b) Vericar bloques (SI). 11. LILO. (a) No necesita parametros adicionales. Activar la opcion lineal. (b) Instalacion en el primer sector de la particion de arranque (/dev/hdc1). (c) Asignar etiqueta solo a la particion hdc3(linux). 12. Nombre del ordenador: pc04XX.dsic.upv.es. 13. Conguracion del raton. Generic mouse PS/2 de dos botones y seleccionar simular tres botones. 14. Zona horaria. (a) Reloj no asignado a GMT. (b) Europa / Madrid. 15. Contrase~na. Seleccionar como contrase~na el nombre del ordenador: ejemplo pc0411. 16. A~nadir nuevos usuarios: ninguno. 17. Autenticacion. Las opciones por defecto son correctas. 18. Seleccion de componentes. Solo: X Window System, GNOME, KDE, Mail/WWW/News Tools, DOS/Windows Connectivity, Networked Workstation, Emacs. 19. Tarjeta de vdeo. Deteccion correcta de la tarjeta de vdeo (OK) 20. Esperar a que nalice la instalacion de paquetes. 21. Crear el disco de arranque. Etiquete el disco con "Arranque RedHat 'kernel' Ordenador XX ". 22. Conguracion de X. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: Instalaci on De Red Hat Linux (a) (b) (c) (d) (e) (f) (g) (h) (i) Monitor CTX CPS-1760. No probar la tarjeta de vdeo. Memoria de vdeo, 8Mb. No "clockchip setting". Omitir la prueba de relojes. Modo sugerido: 1024 x 768 con 24 bits. Probar la conguracion iniciando el servidor X. Aceptar la prueba (antes de 10 segundos). Activar las X desde el inicio del sistema. 23. Cuando aparezca la ventana de nalizacion, OK. 24. Esperar a que el sistema se reinicie. 25. Entrar como root, vericar funcionamiento. Creaci on del disquete de arranque basado en LILO. 1. Introducir un disquete formateado (puede utilizar el disquete de arranque creado durante la instalacion u otro disquete para mayor seguridad). 2. Editar el chero /etc/lilo.conf. 3. Modicar en la primera lnea hdc1 por fd0. 4. Ejecutar lilo 5. Etiquete el disco con "Arranque RedHat 'Lilo' Ordenador XX ". 6. Rearrancar la ordenador con el nuevo disco y probar que funciona. Desactivaci on del disco extra ble . 1. Inicie el ordenador con el sistema Linux del disco interno. 2. Acredtese con su usuario y contrase~na. 3. Ejecute el mandato desactiva-hdc. 4. Recuerde que debe realizar esta desactivacion al nal de cada sesion de practicas. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 DE SISTEMAS ADMINISTRACION ACTIVIDAD Instalaci on De Windows NT Workstation 4.0 ADVERTENCIA: La instalacion de NT Workstation se realiza en los ordenadores 2,4,6,8,10,13,15,17,19. Requerimientos iniciales Necesitamos inicialmente: Servidor NT. Imagenes de la instalaci on de NT Wks y Server. En cada ordenador hace falta una partici on disponible con tipo Old Minix de al menos 500Mb en el disco primario. 1 disquete por ordenador a instalar, de arranque MS-DOS con soporte de red (+drivers). Ademas debe tener: format, fdisk y xcopy. 1 disquete con formato MS-DOS para la generacion del disco de arranque. Activaci on del disco extra ble 1. Apague el ordenador. 2. Inserte el disco extrable y fjelo con la llave. 3. Inicie el ordenador con el sistema Linux del disco interno. 4. Acredtese con su usuario y contrase~na. 5. Ejecute el mandato activa-hdc turno, siendo turno el correspondiente a su sesion. NO SE EQUIVOQUE. Ejecute este mandato sin argumentos para que muestre los turnos disponibles. 6. Recuerde que debe realizar esta activacion al principio de cada sesion de practicas. Antes de instalar 1. Arrancar con el sistema Linux del disco extrable. 2. Salvar el MBR: dd if=/dev/hda of=/tmp/mbr bs=512 count=1 3. Cambiar los tipos de las particiones del DISCO FIJO (/dev/hda) (a) (b) (c) (d) Iniciar fdisk: fdisk Visualizar el estado actual de las particiones: p Cambiar el tipo de la particion hda1 a "Old Minix": t 1 80 Cambiar el tipo de la particion hda2 a "FAT16": t 2 6 1 2 Actividad: Instalacion De Windows NT Workstation 4.0 (e) Activar la particion hda2: a 2 (f) Si es necesario, desactivar la particion hda1: a 1 (g) Visualizar el estado actual de las particiones y vericar que todo es correcto. La particion hda2 debe ser ahora la activa y del tipo "FAT16". La particion had1 debe ser ahora del tipo "Old Minix"y no tener la etiqueta de activa: p (h) Guardar los cambios: w Instalaci on de MS-DOS 1. Reiniciar el ordenador y arrancar con el disco de instalacion de MS-DOS seleccionando la opcion "SIN soporte para red" 2. Ejecutar FDISK para vericar el estado de las particiones de ambos discos. Deben haber dos particiones, C: en el disco interno y D: en el extrable. 3. Formatear la particion C: FORMAT C: /U /S 4. Eliminar LILO del MBR. FDISK /MBR 5. Copiar el contenido del disquete en C: XCOPY A:\*.* C:\ /S ** no sobreescribir COMMAND.COM Instalaci on de Windows NT 1. Rearrancar el ordenador desde el disco duro. En este caso debe elegirse la opcion "CON soporte para red". 2. Usuario de red NT, contrase~na nt. 3. Conexion con el servidor donde residen los cheros necesarios para la instalacion. NET USE Z: \\ADSERVER\SOFT 4. Con el n de acelerar el proceso de copia de archivos, debe activarse el subsistema MS-DOS de cache de disco, el cual, por razones de espacio, no ha podido ser incluido en el disquete de arranque. C: CD \ COPY z:\SMARTDRV.EXE C:\ SMARTDRV c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: Instalaci on De Windows NT Workstation 4.0 5. Los manejadores de la tarjeta de red en la version original de NT no son adecuados. Por tanto, es necesario disponer de los manejadores de dispositivo correctos durante el proceso de instalacion. XCOPY Z:\3COM C:\3COM /s ** destino directorio 6. Iniciar la instalacion (Recuerda, est as instalando NT Workstation) Z: CD NTWKS WINNT /B 7. Descarga de archivos (a) El directorio donde reside la distribucion de NT es el indicado (b) Comienza la transferencia de cheros. Este proceso dura varios minutos. (c) Terminada la descarga, el ordenador solicita reiniciar. Enter. 8. En la deteccion de adaptadores SCSI no hay ninguno. 9. Los componentes hardware detectados son correctos. 10. Seleccion de la particion donde se instalara NT: D: 11. La particion debe tener formato NTFS. 12. El directorio sugerido para NT es correcto. 13. Realice el reconocimiento exhaustivo del disco. 14. El ordenador rearrancara un par de veces. 15. Se inicia la parte de la instalacion basada en NT (modo graco). (a) (b) (c) (d) (e) (f) Instalacion tpica. Identicar nombre y organizacion (al gusto). Identicar ordenador (pc04XX XX es el no del ordenador). Contrase~na del administrador. El nombre del ordenador (Ej. pc0411). NO crear disco de emergencia. Componentes de Windows recomendados. 16. Instalacion de Red. (a) (b) (c) (d) (e) (f) (g) Seleccionar conectado a la red mediante adaptador de red de area local. NO buscar adaptador. Seleccionar de la lista, utilizar disco, indicar la ruta C:n3COM. Solo protocolo TCP/IP Resto de opciones por defecto. No se utilizara DHCP. En la cha de Direccion IP indicar la direccion IP del (158.42.54.[60+no ordenador] ), la mascara de red (255.255.128.0) y el gateway 158.42.1.10 Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 4 Actividad: Instalacion De Windows NT Workstation 4.0 (h) En la cha DNS, indicar: dominio dsic.upv.es, servidor de nombres 158.42.48.150 (i) En la cha Direccion Wins, indicar: Servidor principal de WINS: nada, servidor secundario de WINS: nada 17. El ordenador formara parte de un WORKGROUP. Debe elegir un nombre de grupo de trabajo igual al nombre de dominio elegido en el NT Server. Denomine este grupo de trabajo como ADMON (el nombre de grupo elegido). 18. Para nalizar la instalacion. (a) Zona horaria. (b) Adaptador de vdeo. NT no detecta el tipo de adaptador, por lo que asume compatible VGA. 19. El ordenador debe reiniciarse de nuevo. Creaci on del disquete de arranque 1. Formatear un disquete con Windows NT. 2. Copiar en dicho disquete los siguientes cheros, que se encuentran en el directorio C: (pueden estar ocultos). NTDETECT.COM NTLDR BOOT.INI 3. Etiquete el disco con "Arranque NT Workstation. Ordenador XX ". 4. Reinice el ordenador con este disquete y compruebe que se arranca el sistema Windows NT instalado. Recuperaci on del MBR 1. Arrancar con el sistema Linux del disco extrable. 2. Ejecutar dd if=/tmp/mbr of=/dev/hda bs=512 count=1 Actividades adicionales 1. Instalar Service Pack 6. (disponible en nnadservernsoft) 2. Instalar el adaptador de video correcto. (disponible en el directorio nvidia de nnadservernsoft). El modelo del adaptador es Nvidia Riva 128. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 5 Actividad: Instalaci on De Windows NT Workstation 4.0 Desactivaci on del disco extra ble 1. Inicie el ordenador con el sistema Linux del disco interno. 2. Acredtese con su usuario y contrase~na. 3. Ejecute el mandato desactiva-hdc. 4. Recuerde que debe realizar esta desactivacion al nal de cada sesion de practicas. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 DE SISTEMAS ADMINISTRACION ACTIVIDAD Instalaci on De Windows NT Server 4.0 ADVERTENCIA: La instalacion de NT Server se realiza en los ordenadores 1,3,5,7,9,14,16,18,20. Requerimientos iniciales Necesitamos inicialmente: Servidor NT. Imagenes de la instalaci on de NT Wks y Server. En cada ordenador hace falta una partici on disponible con tipo Old Minix de al menos 500Mb en el disco primario. 1 disquete por ordenador a instalar, de arranque MS-DOS con soporte de red (+drivers). Ademas debe tener: format, fdisk y xcopy. 1 disquete con formato MS-DOS para la generacion del disco de arranque. Activaci on del disco extra ble 1. Apague el ordenador. 2. Inserte el disco extrable y fjelo con la llave. 3. Inicie el ordenador con el sistema Linux del disco interno. 4. Acredtese con su usuario y contrase~na. 5. Ejecute el mandato activa-hdc turno, siendo turno el correspondiente a su sesion. NO SE EQUIVOQUE. Ejecute este mandato sin argumentos para que muestre los turnos disponibles. 6. Recuerde que debe realizar esta activacion al principio de cada sesion de practicas. Antes de instalar 1. Arrancar con el sistema Linux del disco extrable. 2. Salvar el MBR: dd if=/dev/hda of=/tmp/mbr bs=512 count=1 3. Cambiar los tipos de las particiones del DISCO FIJO (/dev/hda) (a) (b) (c) (d) Iniciar fdisk: fdisk /dev/hda Visualizar el estado actual de las particiones: p Cambiar el tipo de la particion hda1 a "Old Minix": t 1 80 Cambiar el tipo de la particion hda2 a "FAT16": t 2 6 1 2 Actividad: Instalaci on De Windows NT Server 4.0 (e) Activar la particion hda2: a 2 (f) Si es necesario, desactivar la particion hda1: a 1 (g) Visualizar el estado actual de las particiones y vericar que todo es correcto. La particion hda2 debe ser ahora la activa y del tipo "FAT16". La particion had1 debe ser ahora del tipo "Old Minix"y no tener la etiqueta de activa: p (h) Guardar los cambios: w Instalaci on de MS-DOS 1. Reiniciar el ordenador y arrancar con el disco de instalacion de MS-DOS seleccionando la opcion "SIN soporte para red" 2. Ejecutar FDISK para vericar el estado de las particiones de ambos discos. Deben haber dos particiones, C: en el disco interno y D: en el extrable. 3. Formatear la particion C: FORMAT C: /U /S 4. Eliminar LILO del MBR. FDISK /MBR 5. Copiar el contenido del disquete en C: XCOPY A:\*.* C:\ /S ** no sobreescribir COMMAND.COM Instalaci on de Windows NT 1. Rearrancar el ordenador desde el disco duro. En este caso debe elegirse la opcion "CON soporte para red". 2. Usuario de red NT, contrase~na nt. 3. Conexion con el servidor donde residen los cheros necesarios para la instalacion. NET USE Z: \\ADSERVER\SOFT 4. Con el n de acelerar el proceso de copia de archivos, debe activarse el subsistema MS-DOS de cache de disco, el cual, por razones de espacio, no ha podido ser incluido en el disquete de arranque. C: CD \ COPY z:\SMARTDRV.EXE C:\ SMARTDRV c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: Instalaci on De Windows NT Server 4.0 5. Los manejadores de la tarjeta de red en la version original de NT no son adecuados. Por tanto, es necesario disponer de los manejadores de dispositivo correctos durante el proceso de instalacion. XCOPY Z:\3COM C:\3COM /s ** destino directorio 6. Iniciar la instalacion (Recuerda, est as instalando NT Server) Z: CD NTSERVER WINNT /B 7. Descarga de archivos (a) El directorio donde reside la distribucion de NT es el indicado (b) Comienza la transferencia de cheros. Este proceso dura varios minutos. (c) Terminada la descarga, el ordenador solicita reiniciar. Enter. 8. En la deteccion de adaptadores SCSI no hay ninguno. 9. Los componentes hardware detectados son correctos. 10. Seleccion de la particion donde se instalara NT: D: 11. La particion debe tener formato NTFS. 12. El directorio sugerido para NT es correcto. 13. Realice el reconocimiento exhaustivo del disco. 14. El ordenador rearrancara un par de veces. 15. Se inicia la parte de la instalacion basada en NT (modo graco). (a) (b) (c) (d) (e) (f) (g) Identicar nombre y organizacion (al gusto). Licencias por puesto. Identicar ordenador (pc04XX XX es el no del ordenador). El ordenador sera un controlador principal de dominio. Contrase~na del administrador. El nombre del ordenador (Ej. pc0411). NO crear disco de emergencia. Componentes de Windows recomendados. 16. Instalacion de Red. (a) (b) (c) (d) (e) (f) (g) Seleccionar conectado a la red mediante adaptador de red de area local. No instale Internet Infomation System. NO buscar adaptador. Seleccionar de la lista, utilizar disco, indicar la ruta C:n3COM. Solo protocolo TCP/IP Resto de opciones por defecto. No se utilizara DHCP. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 4 Actividad: Instalaci on De Windows NT Server 4.0 (h) En la cha de Direccion IP indicar la direccion IP del (158.42.54.[60+no ordenador] ), la mascara de red (255.255.128.0) y el gateway 158.42.1.10 (i) En la cha DNS, indicar: dominio dsic.upv.es, servidor de nombres 158.42.48.150 (j) En la cha Direccion Wins, indicar: Servidor principal de WINS: nada, servidor secundario de WINS: nada 17. Cuando se solicite el nombre del dominio, escoja el nombre del grupo de trabajo elegido para la instalacion del sistema NT Workstation del otro ordenador. Denomine este dominio como ADMON (el nombre de grupo elegido). 18. Para nalizar la instalacion. (a) Zona horaria. (b) Adaptador de vdeo. NT no detecta el tipo de adaptador, por lo que asume compatible VGA. 19. El ordenador debe reiniciarse de nuevo. Creaci on del disquete de arranque 1. Formatear un disquete con Windows NT. 2. Copiar en dicho disquete los siguientes cheros, que se encuentran en el directorio C: (pueden estar ocultos). NTDETECT.COM NTLDR BOOT.INI 3. Etiquete el disco con "Arranque NT Server. Ordenador XX ". 4. Reinice el ordenador con este disquete y compruebe que se arranca el sistema Windows NT instalado. Recuperaci on del MBR 1. Arrancar con el sistema Linux del disco extrable. 2. Ejecutar dd if=/tmp/mbr of=/dev/hda bs=512 count=1 Actividades adicionales 1. Instalar Service Pack 6. (disponible en nnadservernsoft) 2. Instalar el adaptador de video correcto. (disponible en el directorio nvidia de nnadservernsoft). El modelo del adaptador es Nvidia Riva 128. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 5 Actividad: Instalaci on De Windows NT Server 4.0 Desactivaci on del disco extra ble 1. Inicie el ordenador con el sistema Linux del disco interno. 2. Acredtese con su usuario y contrase~na. 3. Ejecute el mandato desactiva-hdc. 4. Recuerde que debe realizar esta desactivacion al nal de cada sesion de practicas. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 DE SISTEMAS ADMINISTRACION ACTIVIDAD Usuarios y Proteccion en RedHat Linux Introducci on El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios, con la gestion de proteccion y con la gestion de sistemas de archivos en el sistema operativo RedHat Linux. En particular, se abordaran los siguientes conceptos: Usuarios y grupos primarios Grupos suplementarios Reglas de proteccion Utilizacion de los bits SETUID y SETGID en ejecutables Utilizacion del bit SETGID en directorios Utilizacion de grupos privados Reglas de Seguridad de la Organizaci on Una organizacion esta utilizando un sistema Linux como soporte informatico. Esta organizacion ha dise~nado un plan de seguridad que cubre los siguientes aspectos: a) Sobre las contrase~ nas. A n de facilitar las pruebas sobre las actividades de laboratorio, asgnese a cada cuenta la contrase~na hardy. b) Sobre el directorio de cada usuario. Se tiene que cumplir lo siguiente: Todo usuario del sistema debe poseer un subdirectorio del directorio /lacasa cuyo nombre debe coincidir con el de la cuenta del usuario. En este directorio, el usuario debe poder crear y borrar cheros y directorios, pero no debe poder modicar los permisos de su directorio de conexion. Ning un otro usuario del sistema debe poder acceder a dicho directorio y a su contenido. c) Sobre los proyectos. La organizacion tiene varios proyectos en curso de realizacion. Sobre dichos proyectos, se tiene que cumplir lo siguiente: Cada proyecto debe tener un directorio bajo el directorio /proyectos donde almacenar su documentacion asociada. Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer, modicar, crear y borrar los archivos que forman parte del proyecto. Cuando un usuario cree un archivo en el directorio del proyecto, por defecto, este debe poder ser ledo, modicado o borrado por cualquier otro usuario del mismo proyecto. Ning un otro usuario debe poder acceder a estos directorios. 1 Actividad: Usuarios y Protecci on en RedHat Linux 2 d) Sobre los ejecutivos. En la empresa existen varios ejecutivos que tienen asignada la evaluacion de algunos de los proyectos existentes. Sobre ellos, se tienen que cumplir: Los ejecutivos no deben poder acceder directamente a los directorios de los proyectos. Para que los ejecutivos puedan controlar el estado de cada proyecto, deben existir en el directorio /usr/local/bin tantos programas como proyectos existan. Una copia de dichos programas puede obtenerse en el directorio remoto /home/ftp/pub/varios del ordenador adserver. Internamente, estos programas ejecutan el mandato ls -lR sobre el directorio del proyecto correspondiente. El programa que permite evaluar cada proyecto debera cumplir los siguientes dos requisitos: Debe poder ser ejecutado unicamente por los ejecutivos asociados a dicho proyecto. { Para que pueda ser ejecutado satisfactoriamente, este programa debe tener los permisos sucientes para poder ejecutar el mandato ls -lR sobre su directorio. { e) Sobre el resto de usuarios. En la organizacion pueden existir otros usuarios no vinculados a ningun proyecto, los cuales no deben tener ningun derecho de acceso a los directorios de los proyectos. Situaci on Actual de la Organizaci on Actualmente, en la organizacion se tiene la siguiente situacion de usuarios y proyectos: Existen tres proyectos, denominados proy1, proy2 y proy3. Hay dos ejecutivos, cuyas cuentas se denominan ejec1 y ejec2. Adicionalmente, existen dos usuarios, ajeno1 y ajeno2, que no est an vinculados a ningun proyec- to. Los usuarios que participan en proyectos estan organizados seg un se muestra en la tabla siguiente: Usuario usu1 usu2 usu3 usu4 usu5 Proyecto proy1 proy2 p p p p p p p p proy3 usu6 p p La asociaci on de ejecutivos a proyectos es la siguiente: Ejecutivo Proyecto proy1 ejec1 ejec2 c Agust n Espinosa, Andr es Terrasa, 2001 p p proy2 p proy3 p Administraci on de Sistemas, DSIC, UPV DE SISTEMAS ADMINISTRACION ACTIVIDAD Usuarios y Protecci on en Windows NT Introducci on El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios y con la gestion de proteccion en el sistema operativo Windows NT. En particular, se abordaran los siguientes conceptos: Usuarios y grupos locales Grupos predenidos Derechos de usuario Plan de cuentas Control de acceso a archivos y directorios Reglas de proteccion Reglas de Seguridad de la Organizaci on Una organizacion esta utilizando un sistema Windows NT como soporte informatico. Esta organizacion ha dise~nado un plan de seguridad que cubre los siguientes aspectos: a) Sobre el sistema. Cualquier usuario debe poder apagar el sistema. b) Sobre las contrase~ nas. siguientes normas: Las contrase~nas de los usuarios del sistema tienen que cumplir las Los usuarios deben cambiar su contrase~ na cada dos meses. Los usuarios pueden cambiar su contrase~ na tras dos semanas del cambio anterior. No se permiten contrase~ nas en blanco. Una nueva contrase~ na debe ser siempre distinta de la anterior. Si se detectan tres acreditaciones fallidas en un intervalo de cinco minutos a una cuenta de usuario, esta debe quedar permanentemente bloqueada. Estos intentos fallidos deben quedar registrados en la auditora del sistema. A n de facilitar las pruebas sobre las actividades de laboratorio, asgnese a cada cuenta la contrase~na master. c) Sobre el directorio de cada usuario. conexion, que debe cumplir lo siguiente: Cada usuario debe poseer un directorio propio de Todo usuario del sistema debe poseer un subdirectorio del directorio \lacasa cuyo nombre debe coincidir con el de la cuenta del usuario. En este directorio, el usuario debe tener control total sobre el mismo. 1 Actividad: Usuarios y Protecci on en Windows NT 2 Ning un otro usuario del sistema debe poder acceder a dicho directorio y a su contenido. d) Sobre los proyectos. ellos, se tiene que: La organizacion tiene varios proyectos en curso de realizacion. Sobre Cada proyecto debe tener un directorio bajo el directorio \proyectos donde almacenar su documentacion asociada. Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer y modicar los archivos que forman parte del proyecto. En cambio, no podr an crear ni borrar archivos del proyecto. Esta funcion debera realizarla el director del proyecto. e) Sobre los directores de proyecto. Cada proyecto posee uno o varios directores responsables del mismo. Dichos directores tendran control total sobre los archivos del proyecto que dirigen. Esto incluye poder modicar permisos y tomar posesion de cualquier archivo del proyecto. f ) Sobre los ejecutivos. En la organizacion existen una serie de ejecutivos, los cuales deben poder acceder a cualquiera de los directorios donde se guarda informacion sobre los proyectos en curso y poder leer dicha informacion. No obstante, no podran alterarla de ninguna forma. g) Sobre el resto de usuarios. En la organizacion pueden existir otros usuarios no vinculados a ningun proyecto, los cuales no deben tener ningun derecho de acceso a los directorios de los proyectos. h) Sobre el administrador. El administrador del sistema debe congurar los permisos iniciales de cada proyecto de forma que: Las restricciones anteriores se establezcan de forma automatica cada vez que se cree nueva informacion asociada a un proyecto. Las reglas de proteccion sean las mnimas necesarias para que se cumpla con todo lo ex- puesto. Situaci on Actual de la Organizaci on Actualmente, en la organizacion se tiene la siguiente situacion de usuarios y proyectos: Existen tres proyectos, denominados proy1, proy2 y proy3. Existen diez usuarios trabajando en los distintos proyectos. Dichos usuarios se denominan usu1, usu2, . . . , usu10. Hay tres ejecutivos en la organizacion, cuyas cuentas se denominan ejec1, ejec2 y ejec3. Los usuarios ajeno1 y ajeno2 no estan vinculados a ning un proyecto. La siguiente tabla muestra la asignaci on de usuarios a proyectos: c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV Actividad: Usuarios y Protecci on en Windows NT Usuario usu1 proy1 Director Participante p usu2 usu3 usu4 usu5 usu6 p usu7 usu8 usu9 usu10 Administraci on de Sistemas, DSIC, UPV p p p p 3 proy2 Director Participante p p p proy3 Director Participante p p p p p p p p p p p p p c Agust n Espinosa, Andr es Terrasa, 2001 DE SISTEMAS ADMINISTRACION ACTIVIDAD Dominios en Windows NT Introducci on El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios y con la gestion de proteccion en los dominios Windows NT. En particular, se abordaran los siguientes conceptos: Controladores principales de dominios Incorporaci on de estaciones a dominios Usuarios y grupos globales Relaciones de conanza Comparticion de recursos Reglas de Seguridad de la Organizaci on Una organizacion esta utilizando sistemas Windows NT como soporte informatico. Esta organizacion esta formada por varios departamentos, cada uno de los cuales esta organizado como un dominio NT. Para ello, cada departamento dispone de un servidor NT que actua como controlador principal del dominio y de una estacion NT que actua como miembro de dicho dominio. Esta organizacion ha dise~nado un plan de seguridad que cubre los siguientes aspectos. Sobre los Sistemas En cada departamento, los sistemas deben cumplir lo siguiente: a) Estacion. Cualquier usuario local o del dominio al que pertenece la estacion debe poder: Apagar el equipo. Iniciar una sesi on local. Iniciar una sesi on remota. b) Servidor. Cualquier administrador del dominio debe poder: Apagar el equipo. Iniciar una sesi on local. Por otra parte, cualquier usuario global del dominio y usuarios globales de otros dominios (cuando esto sea necesario) deben poder iniciar una sesi on remota. Sobre las Contrase~nas A n de facilitar las pruebas sobre las actividades de laboratorio, las cuentas no deben tener contrase~nas, a excepcion de la del administrador. 1 2 Actividad: Dominios en Windows NT Sobre el Directorio de Cada Usuario Todo usuario del dominio debe poseer un recurso de red en el controlador principal del dominio cuyo nombre debe coincidir con el de su cuenta del usuario. Dicho recurso de red/directorio debe cumplir las siguientes reglas: El recurso de red debe ser asignado de forma autom atica a la unidad logica Z: cuando el usuario se conecta al servidor o a la estacion. En dicho directorio, el usuario debe tener control total sobre el mismo. Ning un otro usuario del sistema debe poder acceder a dicho directorio ni a su contenido. Sobre los Proyectos Cada departamento tiene tres proyectos en curso de realizacion denominados proy1, proy2 y proy3. Sobre los mismos, se tienen que cumplir las siguientes reglas: Los proyectos proy1 y proy3 residen en subdirectorios del recurso de red denominado proyectos que exporta el servidor del departamento. En estos subdirectorios se almacena la documentacion asociada a cada proyecto. Los participantes de dichos proyectos pueden ser usuarios globales del dominio del departamento o de otros dominios. El proyecto proy2 reside en un subdirectorio del directorio nproyectos de la estaci on del departamento. Sus participantes pueden ser usuarios globales del dominio del departamento y usuarios locales de la estacion. Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer y modicar los archivos que forman parte del proyecto. En cambio, no podr an crear ni borrar archivos del proyecto. Esta funcion debera realizarla el director del proyecto. NOTA: La asignacion de permisos a proyectos se realizara exclusivamente en base a grupos locales. Sobre los Directores de Proyecto Cada proyecto posee uno o varios directores que son los responsables del mismo. La organizacion establece que: Los directores de un proyecto tendran control total sobre los archivos del proyecto que dirigen. Esto incluye poder modicar permisos y tomar posesion de cualquier archivo del proyecto. Uno de los directores del proyecto deber a ser el propietario del directorio de cada proyecto. Dicho director esta etiquetado con el smbolo \*" en la tabla de asignacion de usuarios a proyectos, al nal del documento. Sobre los Ejecutivos Los ejecutivos del departamento deben poder acceder y leer el contenido de cualquiera de los directorios donde se guarda informacion sobre los proyectos en curso, bien sean proyectos que residen en el servidor o en la estacion. No obstante, no podran alterar el contenido de los proyectos. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: Dominios en Windows NT Sobre los Administradores La organizacion establece que los administradores de cada departamento deben poder administrar el PDC de otro departamento. En concreto, el servidor de cada departamento debe poder ser administrado por los administradores del departamento/dominio \D" (vease la Figura 1 al nal de este documento). Sin embargo, dichos administradores no podran administrar la estaci on del departamento. Sobre el Resto de Usuarios En el departamento pueden existir otros usuarios no vinculados a ningun proyecto, los cuales no deben tener ningun derecho de acceso a los directorios de los proyectos. Situacion Actual de la Organizacion Actualmente, en la organizacion se tiene la siguiente situacion de usuarios y proyectos: Hay tres ejecutivos en el departamento. Sus cuentas son globales y se denominan ejec1, ejec2 y ejec3. Los usuarios ajeno1 y ajeno2 son usuarios globales del dominio y no estan vinculados a ning un proyecto. Los usuarios local1 y local2 solo existen en la estaci on del departamento. A continuacion se muestra una tabla que recoge la distribucion de usuarios a proyectos. Usuario usu1 proy1 Director Participante p p usu2 usu3 usu4 p p * local1 p proy2 Director Participante p proy3 Director Participante p p * p p p p p p p p p p p local2 Dnusu1 Dnusu2 * En la tabla anterior, los usuarios usu1 a usu4 son usuarios globales del dominio del departamento. Los usuarios Dnusu1 y Dnusu2 son usuarios globales del departamento/dominio \D". La Figura 1 al nal del documento muestra, para cada dominio, cual es su dominio \D" segun la distribucion del laboratorio. NOTA IMPORTANTE: Se recomienda organizar en primer lugar el proyecto proy1, luego el proy2 y por u ltimo el proy3. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 4 Actividad: Dominios en Windows NT la puerta Figura 1: Las echas se~nalan cual es el dominio \D" para cada dominio en el laboratorio. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV DE SISTEMAS ADMINISTRACION ACTIVIDAD Dominios en RedHat Linux Reglas de Seguridad de la Organizaci on Una organizacion esta utilizando un sistema Linux como soporte informatico. Esta organizacion ha dise~nado un plan de seguridad que cubre los siguientes aspectos: a) Sobre los sistemas. ** Uno de los ordenadores de la organizaci on debe actuar como servidor NIS y servidor NFS (En nuestro laboratorio, los ordenadores 2, 4, 6, 8, 10, 13, 15, 17 y 19) ** Todas las cuentas de usuarios y grupos deben ser gestionadas desde este servidor. b) Sobre las contrase~ nas. A n de facilitar las pruebas sobre las actividades de laboratorio, asgnese a cada cuenta la contrase~na hardy. c) Sobre el directorio de cada usuario. Se tiene que cumplir lo siguiente: Todo usuario del sistema debe poseer un subdirectorio del directorio /lacasa cuyo nombre debe coincidir con el de la cuenta del usuario. ** Este directorio debe residir fsicamente en el ordenador que actue como servidor NFS. ** Este directorio debe ser accesible desde cualquier ordenador de la organizacion utilizando el mismo nombre de ruta ( /lacasa/usu1, por ejemplo). ** Solo los dos ordenadores de la organizacion podran acceder a este directorio. En este directorio, el usuario debe poder crear y borrar cheros y directorios, pero no debe poder modicar los permisos de su directorio de conexion. Ningun otro usuario del sistema debe poder acceder a dicho directorio y a su contenido. d) Sobre los proyectos. La organizacion tiene varios proyectos en curso de realizacion. Sobre dichos proyectos, se tiene que cumplir lo siguiente: Cada proyecto debe tener un directorio bajo el directorio /proyectos donde almacenar su documentacion asociada. ** Este directorio debe residir fsicamente en el ordenador que actue como servidor NFS. ** Este directorio debe ser accesible desde cualquier ordenador de la organizacion utilizando el mismo nombre de ruta ( /proyectos). ** Solo los dos ordenadores de la organizacion podran acceder a este directorio. Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer, modicar, crear y borrar los archivos que forman parte del proyecto. Cuando un usuario cree un archivo en el directorio del proyecto, por defecto, este debe poder ser ledo, modicado o borrado por cualquier otro usuario del mismo proyecto. Ningun otro usuario debe poder acceder a estos directorios. e) Sobre los ejecutivos. En la empresa existen varios ejecutivos que tienen asignada la evaluacion de algunos de los proyectos existentes. Sobre ellos, se tienen que cumplir: 1 2 Actividad: Dominios en RedHat Linux Los ejecutivos no deben poder acceder directamente a los directorios de los proyectos. Para que los ejecutivos puedan controlar el estado de cada proyecto, deben existir en el directorio /usr/local/bin tantos programas como proyectos existan. Una copia de dichos programas puede obtenerse en el directorio remoto /home/ftp/pub/varios del ordenador adserver. Internamente, estos programas ejecutan el mandato ls -lR sobre el directorio del proyecto correspondiente. ** Deben existir copias de estos programas en los dos ordenadores de la organizaci on. El programa que permite evaluar cada proyecto debera cumplir los siguientes dos requisitos: { Debe poder ser ejecutado unicamente por los ejecutivos asociados a dicho proyecto. { Para que pueda ser ejecutado satisfactoriamente, este programa debe tener los permisos sucientes para poder ejecutar el mandato ls -lR sobre su directorio. { ** Debe funcionar satisfactoriamente en cualquiera de los dos ordenadores de la organizacion. f) Sobre el resto de usuarios. En la organizacion pueden existir otros usuarios no vinculados a ningun proyecto, los cuales no deben tener ningun derecho de acceso a los directorios de los proyectos. g) Directorio p ublico. ** El servidor NFS de la organizacion debe ofrecer un directorio denominado /pub a cualquier ordenador o usuario que desee utilizarlo. Este directorio sera de solo lectura y todos los accesos deberan ser considerados como anonimos. Situaci on Actual de la Organizaci on Actualmente, en la organizacion se tiene la siguiente situacion de usuarios y proyectos: Existen tres proyectos, denominados proy1, proy2 y proy3. Hay dos ejecutivos, cuyas cuentas se denominan ejec1 y ejec2. Adicionalmente, existen dos usuarios, ajeno1 y ajeno2, que no est an vinculados a ningun proyec- to. Los usuarios que participan en proyectos estan organizados seg un se muestra en la tabla siguiente: Usuario usu1 usu2 usu3 usu4 usu5 Proyecto proy1 proy2 p p p p p p p p proy3 usu6 p p La asociaci on de ejecutivos a proyectos es la siguiente: Ejecutivo Proyecto proy1 ejec1 ejec2 c Agust n Espinosa, Andr es Terrasa, 2001 p p proy2 p proy3 p Administraci on de Sistemas, DSIC, UPV DE SISTEMAS ADMINISTRACION ACTIVIDAD Samba Introducci on El objeto de esta practica consiste en adquirir habilidades relacionadas con la gestion del producto denominado Samba, el cual permite que una maquina Unix implemente el protocolo SMB, haciendo as posible que maquinas basadas en sistemas operativos de Microsoft utilicen a traves de la red directorios de la maquina Unix. Supuesto practico Una organizacion esta utilizando sistemas Windows NT 4.0 y sistemas Unix (RedHat Linux) como soporte informatico. En este momento, las maquinas Windows NT forman un dominio, as como tambien las maquinas Linux. No obstante, no existe ningun tipo de interoperatividad entre ambos tipos de sistemas, por lo que deciden utilizar Samba para conseguir una mayor integracion entre sus sistemas. Los objetivos que persiguen son los siguientes: a) Unicacion de usuarios. b) En ambos tipos de sistemas, deben existir los mismos usuarios. c) No es necesario que las contrase~nas coincidan en ambos sistemas. d) Cuando un usuario se conecte en un sistema NT, debe recibir de forma automatica las siguientes conexiones de red predeterminadas: Z: L: P: Q: H: e) directorio del usuario en el sistema NT. directorio del usuario en el servidor Linux. directorio donde residen los subdirectorios de los proyectos en el servidor Linux. directorio donde residen los subdirectorios de los proyectos en el sistema NT Server. recurso soft de adserver. Las siguientes conexiones deben poder realizarse de forma manual sobre el servidor Linux desde los sistemas NT: Recurso pub, accesible por cualquier usuario, aunque no se encuentre registrado, de solo lectura. Recurso almacen, accesible por cualquier usuario, aunque no se encuentre registrado, de lectura-escritura. Todos los archivos y directorios que se creen dentro de este recurso deberan pertenecer al mismo usuario y al mismo grupo, con independencia del usuario que los creo. f) Sobre las restricciones de acceso El acceso a los recursos de red con conexi on automatica debe estar restringido a los orde- nadores del grupo. El acceso a los recursos de red adicionales debe estar permitido para cualquier ordenador. 1 DE SISTEMAS ADMINISTRACION ACTIVIDAD Encaminamiento y DNS Introduccion Una organizacion desea disponer de varias redes de area local, una por cada departamento. Para conseguir la interconexion de dichas redes, se dispone de otra red de area local, denominada troncal. La red propia de cada departamento dispondra de un ordenador que realizara las funciones de encaminador, estando conectado cada encaminador conectado tanto a su red propia como a la red troncal. En lo referente a la resolucion de nombres, se ha optado por utilizar el servicio DNS. Conguracion de las Redes Uno de los ordenadores de la red troncal (adserver) actuara como el servidor maestro del dominio admon, y cada departamento utilizara y administrara un subdominio del dominio admon. La tabla siguiente detalla las caractersticas de todos los ordenadores de la organizacion: Grupo No IP en Red IP en Red Servidor DNS Encaminador PC Troncal Local p p p p p p p p p p p p p p p p p p p 1 01 158.42.54.61 158.1.1.1 pc0201.grupo1.admon 158.1.1.2 pc0202.grupo1.admon 158.2.1.1 pc0203.grupo2.admon 158.2.1.2 pc0204.grupo2.admon 158.3.1.1 pc0205.grupo3.admon 158.3.1.2 pc0206.grupo3.admon 158.4.1.1 pc0207.grupo4.admon 158.4.1.2 pc0208.grupo4.admon 158.5.1.1 pc0209.grupo5.admon 10 158.5.1.2 pc0210.grupo5.admon 13 158.6.1.2 pc0213.grupo6.admon 158.6.1.1 pc0214.grupo6.admon 158.7.1.2 pc0215.grupo7.admon 158.6.1.1 pc0216.grupo7.admon 158.8.1.2 pc0217.grupo8.admon 158.8.1.1 pc0218.grupo8.admon 158.9.1.2 pc0219.grupo9.admon 158.9.1.1 pc0220.grupo9.admon 02 2 03 158.42.54.63 04 3 05 158.42.54.65 06 4 07 158.42.54.67 08 5 6 09 14 7 158.42.54.76 158.42.54.78 19 20 adserver 158.42.54.74 17 18 9 158.42.54.69 15 16 8 Nombre DNS 158.42.54.80 158.42.49.82 1 adserver.admon 2 Actividad: Encaminamiento y DNS Primera Parte: Establecimiento de las Redes Esta parte consiste en el establecimiento de las distintas redes fsicas de la organizacion. Para ello, el servidor Linux de cada departamento va a ser desconectado de la red troncal, pasando ahora a formar parte de la red propia. Este cambio va a provocar que algunos servicios, NIS, NFS y DNS en particular, deban ser recongurados. A continuacion haremos referencia a los dos equipos de cada grupo como \el encaminador" y \el servidor" (este ultimo, que ya es servidor de NIS y NFS, sera tambien el servidor DNS). Los pasos a seguir son los siguientes: 1. En ambos sistemas, lo primero que hay que hacer es copiar todo el software necesario para la practica. Dicho software puede recuperarase mediante el ftp de adserver, en el directorio pub/dns. Copiar todo ese directorio a /tmp/dns (cuidado con los subdirectorios!). 2. Arrancar ambos ordenadores en el nivel de ejecuci on 2. Al utilizar este nivel los servicios NFS y NIS no se activan, lo cual es necesario porque ambos servicios van a dejar de funcionar debido a los cambios realizados en la red. 3. Ahora hay que conseguir que DNS no interera con los cambios en la red que vamos a efectuar. Para ello hay que hacer lo siguiente en ambos sistemas: Desactivar la utilizacion de la resoluci on de nombres DNS (mediante linuxconf). Especicar de forma estatica las nuevas direcciones de los dos ordenadores del grupo. La forma mas facil es incluir en el chero /etc/hosts las nuevas dos direcciones IP (de la red local), cada una junto con el nombre de su ordenador. En el chero /etc/nsswitch.conf, editar la lnea que empieza por hosts: de manera que la primera opcion de la lista sea files y la segunda dns. 4. Conectamos el servidor a la nueva red. Para ello: Desenchufar el cable de red de la roseta y conectar dicho cable y el cable amarillo entre s con el conector. Mediante linuxconf, cambiar la direccion IP de la tarjeta de red, seg un la nueva conguracion de la tabla. Reiniciar el servidor en el nivel 2. 5. En el encaminador debe darse de alta la segunda tarjeta de red (correspondiente a la red local). Sus parametros son: Enabled: S Config mode: Manual Primary name+domain: (ver tabla) Aliases: ninguno IP Address: (ver tabla) Netmask: 255.255.0.0 Net device: eth1 Kernel module: rtl8139 Una vez hecho esto, reiniciar el encaminador en el nivel 2. 6. En ambos ordenadores, cambiar la direccion IP del servidor NIS (mediante linuxconf). 7. En el servidor NFS, reejar los cambios realizados en las direcciones IP y/o nombres de ordenadores en la tabla de exportacion de directorios va NFS. 8. En el cliente NFS, reejar los cambios realizados en las direcciones IP y/o nombres de ordenadores en la tabla de montaje de dispositivos. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: Encaminamiento y DNS 9. Reiniciar ambos ordenadores, en este caso en el nivel de arranque por defecto. Una vez concluidos estos pasos, es conveniente comprobar mediante el mandato ping -n, utilizando exclusivamente direcciones IP, la conectividad que ambos ordenadores tienen a la red, es decir, qu e ordenadores son alcanzables mediante el ping. Segunda Parte: Interconexion de las Redes El objetivo de esta segunda parte consiste en interconectar las distintas redes entre si, de tal forma que todos los ordenadores puedan comunicarse entre ellos. Un metodo para conseguir esta conectividad consiste en instalar el servicio de encaminamiento dinamico (gated) en cada uno de los ordenadores que forman parte de la red troncal. Los pasos a seguir son los siguientes: En el encaminador: 1. 2. 3. 4. Instalar el paquete gated, disponible en /tmp/dns. Congurar gated. Para ello basta copiar el gated.conf del directorio /tmp/dns al /etc. Congurar el inicio de gated en los niveles de ejecucion 2, 3 y 5. En el apartado de Gateways de linuxconf, eliminar la direccion IP del gateway y habilitar el encaminamiento. 5. Debido a un error en RedHat 6.2, hay que incluir a mano la siguiente lnea en el chero /etc/rc.d/init.d/gated (en la seccion start), antes de la lnea daemon gated): echo ``1'' > /proc/sys/net/ipv4/ip_forward 6. Reiniciar. En el servidor: 1. Indicar que su gateway por defecto es el encaminador de la red propia. 2. Reiniciar. Volver a comprobar la conectividad de ambos ordenadores, de nuevo mediante ping -n y direc- ciones IP, viendo qu e ordenadores son ahora alcanzables. Tercera Parte: Asignacion de Nombres Para concluir la conguracion de la red es necesario establecer un mecanismo que permita que los ordenadores puedan comunicarse entre si utilizando nombres (por ahora, tan solo pueden utilizarse direcciones IP). El mecanismo escogido en este caso es el servicio DNS. El ordenador adserver actuara como el servidor principal de la organizacion, para lo cual administrara el dominio admon. No obstante, cada departamento dispondra de un dominio propio, y sera cada departamento el encargado de administrarlo. Para ello, adserver delegara la autoridad de cada subdominio de admon en el servidor DNS del departamento correspondiente. Los pasos a seguir son los siguientes: En el servidor (DNS): 1. 2. 3. 4. Instalar el paquete bind-8.2, disponible en /tmp/dns. Congurar el inicio de named en los niveles de ejecucion 3 y 5. Copiar el chero /tmp/dns/named.conf en /etc. Copiar el directorio /tmp/dns/named en /var. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 4 Actividad: Encaminamiento y DNS 5. Renombrar los cheros /var/named/Z.158.zona y /var/named/grupoZ.admon.zona, cambiando Z por el numero del grupo. 6. Editar los cheros /var/named/grupoZ.admon.zona, /var/named/Z.158.zona y /etc/named.conf para adecuar sus contenidos. Las modicaciones a realizar consisten en realizar las siguientes sustituciones: Z: numero del grupo XX: servidor DNS (n umero de PC) YY: encaminador (numero de PC) 7. Reiniciar el ordenador. En ambos sistemas, especicar los par ametros del servicio DNS: { Servidor: 158.Z.1.2 { Orden de busqueda 1: grupoZ.admon. (Nota: Es posible que, debido a un error de linuxconf, el servicio DNS no pueda congurarse. Para solucionarlo, debe borrarse el contenido del chero /etc/resolv.conf antes de utilizar linuxconf.) Una vez concluidos estos pasos, debe observarse que todos los ordenadores de la organizaci on son accesibles por nombre, as como que los servicios NFS y NIS funcionan correctamente. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV DE SISTEMAS ADMINISTRACION ACTIVIDAD WINS y DHCP en Windows NT Introducci on El objeto de la practica consiste en adquirir habilidades relacionadas con la instalacion y conguracion del protocolo DHCP y del servicio de nombres NetBIOS sobre TCP/IP (WINS) en un entorno NT. En particular, se abordaran los siguientes conceptos: Instalacion y conguracion de servidores DHCP. Conguracion de Windows NT como cliente DHCP. Instalacion y conguracion de varios servidores WINS. Conguracion de Windows NT como cliente WINS La practica se realizara en el contexto de varias redes locales interconectadas por otra red de area troncal, por lo que sera necesaria la conguracion del encaminamiento entre redes. Nota: Esta practica debe realizarse con la red local del laboratorio aislada. (adviertalo a su profesor, ya que suele ser muy despistado :-) Supuesto Practico Una organizacion posee sistemas Windows NT distribuidos en varios departamentos. Dicha organizacion desea que cada departamento posea su propia red fsica (interconectada con el resto de la organizacion) y que ademas resulte facil cambiar un ordenador de departamento sin tener que recongurar manualmente sus parametros de red. En concreto, se pretende conseguir una situacion descrita por los siguientes puntos: Cada departamento posee una red fsica propia, denominada red local. Para conseguir la interconexion de las redes de los departamentos, se dispone de otra red de area local (denominada troncal ). La red local de cada departamento dispondra de un ordenador que realizara las funciones de encaminador, estando conectado tanto a su red propia como a la red troncal. La organizacion ha decidido utilizar el servicio WINS para la resolucion de nombres NetBIOS. En concreto, se pretende que cada departamento disponga de un servidor WINS propio, y que todos los servidores WINS de la organizacion cooperaren entre s para permitir que la resolucion de nombres NetBIOS funcione correctamente a nivel de toda la organizacion. La organizaci on no utiliza en absoluto el sistema de resolucion de nombres DNS. Para facilitar la movilidad de los ordenadores, cada departamento asignara direcciones y propiedades TCP/IP a sus ordenadores de forma dinamica, utilizando para ello un servidor DHCP (privado en cada red local). 1 2 Actividad: WINS y DHCP en Windows NT La tabla siguiente detalla las caractersticas de todos los ordenadores de la organizacion: Grupo 1 No IP en Red PC Troncal IP en Red Local 01 158.1.1.1 158.42.54.61 02 2 03 05 158.42.54.63 07 158.42.54.65 09 158.42.54.69 7 16 18 158.42.54.76 adserver p pc0204 p p pc0206 p p pc0208 158.3.1.1 158.4.1.1 158.5.1.1 158.6.1.1 158.7.1.1 158.8.1.2 158.42.54.78 19 20 p 158.2.1.1 158.7.1.2 17 9 pc0202 158.6.1.2 158.42.54.74 15 8 p 158.5.1.2 13 14 p 158.4.1.2 10 6 p 158.3.1.2 158.42.54.67 08 5 p 158.2.1.2 06 4 Encaminador 158.1.1.2 04 3 Serv. WINS-DHCP 158.8.1.1 158.9.1.2 158.42.54.80 158.9.1.1 158.42.49.82 Nombre NetBIOS pc0201 pc0203 pc0205 pc0207 pc0209 pc0210 p p pc0213 p p pc0215 p p pc0217 p p p pc0219 pc0214 pc0216 pc0218 pc0220 adserver Primera Parte: Encaminamiento En cada grupo, la activacion del encaminamiento debe realizarse siguiendo los pasos expresados a continuacion: En el enrutador: 1. Dar de alta la segunda tarjeta de red. Esta tarjeta de red se utilizara para conectar con el otro ordenador del grupo, formando as la red propia. El manejador para el modelo de tarjeta utilizada esta disponible en el recurso de red nnadservern3com. 2. Reiniciar el ordenador en este punto. 3. Instalar el enrutamiento. Para ello, se debe agregar el servicio denominado Enrutador RIP para el protocolo Internet (IP) en la pesta~na de Servicios, en la conguracion de Red del Panel de Control. 4. Comprobar, en las propiedades del protocolo TCP/IP, que el \reenvo IP" este activo. En el otro equipo: se debe modicar las propiedades TCP/IP de su u nica tarjeta de red para que reeje la nueva conguracion de la red (ahora forma parte de la red local). Ambos sistemas deben conectarse entre s. Para ello, debe enchufarse el cable que conecta la segunda tarjeta de red del enrutador con el cable de red del otro equipo. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV 3 Actividad: WINS y DHCP en Windows NT Segunda Parte: Instalacion de WINS En cada grupo, la instalacion del servicio WINS debe hacerse en el ordenador que ademas es el enrutador, y que denominaremos genericamente \servidor". La instalacion/conguracion de dicho servicio debe realizarse mediante los siguientes pasos: 1. Instalar el servicio WINS en el servidor. Para ello, agregar el servicio Servidor de nombres de Internet para Windows en la pesta~na de Servicios en la conguracion de Red del Panel de Control. 2. Tanto el servidor WINS como su cliente de cada grupo deben indicar en las propiedades del protocolo TCP/IP la direccion IP del propio servidor WINS del grupo. Puesto que solo hay un servidor WINS por grupo, debe indicarse el servidor WINS primario, no el secundario. En este punto, comprobar que ordenadores de la organizacion se pueden encontrar (mediante Inicio/Buscar Equipo) desde ambos ordenadores del grupo. 3. Establecer las relaciones entre los servidores WINS, tal como muestra la Figura 1. En una primera fase, no establecer la duplicacion entre los servidores denominados A y B en la gura. Comprobar que equipos se pueden encontrar ahora desde cada ordenador. 4. Finalmente, establecer las relaciones de duplicacion entre los servidores denominados A y B en la gura. Comprobar si nalmente todos los ordendores de la organizacion se pueden encontrar desde cada ordenador. Tercera Parte: Instalacion de DHCP En cada grupo, la instalacion del servicio DHCP debe hacerse en el servidor (servidor DHCP+servidor WINS+enrutador). Para ello deben seguirse los siguientes pasos: 1. Instalar el servicio DHCP. Para ello se agrega el servicio denominado Servidor DHCP de Microsoft en la pesta~na de Servicios en la conguracion de Red del Panel de Control. 2. Una vez instalado el servidor, se deben seguir los siguiente aspectos de conguracion: Agregar un nuevo ambito: { Rango de direcciones IP a asignar: 158.Z.1.2 a 158.Z.1.20, donde Z representa el numero del grupo. { Mascara de subred: 255.255.0.0 { El ambito debe ser activado. Opciones de conguraci on del ambito: { Enrutador: 158.Z.1.1 { WINS: Congurar el servidor WINS como el 158.Z.1.1 y el tipo de nodo a p-type. 3. Una vez instalado y congurado el servidor, se debe congurar tambien el cliente. Para ello, en las opciones de conguracion del protocolo TCP/IP hay que seleccionar Obtener direccion IP de un servidor DHCP. Aseg urese de que el resto de opciones locales sean borradas: servidor y domino DNS, puerta de enlace, y servidor(es) WINS. Una vez reinicie el cliente, este debera obtener su direccion IP y el resto de opciones de un servidor DHCP. Administraci on de Sistemas, DSIC, UPV c Agust n Espinosa, Andr es Terrasa, 2001 4 Actividad: WINS y DHCP en Windows NT WINS WINS WINS WINS WINS WINS WINS B WINS WINS A adserver la puerta Servidor de Duplicacion Figura 1: Cliente WINS de ... Relaciones de duplicaci on entre servidores WINS. Nota 1: Utilice el mandato ipconfig /all en el cliente para vericar las propiedades TPC/IP asignadas al cliente. Nota 2: Utilice los mandatos ipconfig /release e ipconfig /renew para cancelar y renovar, respectivamente, la concesi on DHCP en el cliente, si lo considera necesario. c Agust n Espinosa, Andr es Terrasa, 2001 Administraci on de Sistemas, DSIC, UPV