Red Hat Enterprise Linux

Deployment Guide

Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).

Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.

Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.

Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.

All other trademarks referenced herein are the property of their respective owners.

The GPG fingerprint of the security@redhat.com key is:

CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

1801 Varsity Drive RaleighNC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle ParkNC 27709 USA

January 2008

Historial de revisiones
Revisión 5.2-11 Wed May 21 2008 Michael Hideo
Smith
Resolves: #232215
Changing from XML to HTML Single with floating Table of Contents and viewable by browser
Resumen

This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.2.


Introducción
1. Convenciones del documento
2. Envíenos su opinión
I. Sistemas de archivos
1. Estructura del sistema de archivos
1.1. Por qué compartir una estructura común
1.2. Vista preliminar del estándar de jerarquía del sistema de archivos (FHS)
1.2.1. Organización de FHS
1.3. Ubicación de Archivos Especiales bajo Red Hat Enterprise Linux
2. Sistema de archivos ext3
2.1. Características de ext3
2.2. Creación de un sistema de archivos ext3
2.3. Conversión a un sistema de archivos ext3
2.4. Volver al sistema de archivos ext2
3. El sistema de archivos /proc
3.1. Sistema de archivos virtual
3.1.1. Visualización de archivos virtuales
3.1.2. Cambiar archivos virtuales
3.2. Archivos de alto nivel en el sistema de archivos proc
3.2.1. /proc/apm
3.2.2. /proc/buddyinfo
3.2.3. /proc/cmdline
3.2.4. /proc/cpuinfo
3.2.5. /proc/crypto
3.2.6. /proc/devices
3.2.7. /proc/dma
3.2.8. /proc/execdomains
3.2.9. /proc/fb
3.2.10. /proc/filesystems
3.2.11. /proc/interrupts
3.2.12. /proc/iomem
3.2.13. /proc/ioports
3.2.14. /proc/kcore
3.2.15. /proc/kmsg
3.2.16. /proc/loadavg
3.2.17. /proc/locks
3.2.18. /proc/mdstat
3.2.19. /proc/meminfo
3.2.20. /proc/misc
3.2.21. /proc/modules
3.2.22. /proc/mounts
3.2.23. /proc/mtrr
3.2.24. /proc/partitions
3.2.25. /proc/pci
3.2.26. /proc/slabinfo
3.2.27. /proc/stat
3.2.28. /proc/swaps
3.2.29. /proc/sysrq-trigger
3.2.30. /proc/uptime
3.2.31. /proc/version
3.3. Directorios en /proc/
3.3.1. Directorios de proceso
3.3.2. /proc/bus/
3.3.3. /proc/driver/
3.3.4. /proc/fs
3.3.5. /proc/ide/
3.3.6. /proc/irq/
3.3.7. /proc/net/
3.3.8. /proc/scsi/
3.3.9. /proc/sys/
3.3.10. /proc/sysvipc
3.3.11. /proc/tty/
3.4. Uso del comando sysctl
3.5. Recursos adicionales
3.5.1. Documentación instalada
3.5.2. Sitios web útiles
4. Array Redundante de Discos Independientes (RAID)
4.1. ¿Qué es RAID?
4.2. ¿Quién debe utilizar RAID?
4.3. RAID: Hardware vs. Software
4.3.1. Hardware RAID
4.3.2. Software RAID
4.4. Niveles de RAID y Soporte Lineal
4.5. Configuración de Software RAID
4.5.1. Creación de Particiones RAID
4.5.2. Creación de Dispositivos RAID y Puntos de Montaje
5. Espacio Swap
5.1. ¿Qué es el espacio Swap?
5.2. Añadir el espacio Swap
5.2.1. Extensión de Swap en un Volumen Lógico LVM2
5.2.2. Creación de un Volumen Lógico LVM2 para Swap
5.2.3. Creación de un Archivo Swap
5.3. Eliminar el espacio Swap
5.3.1. Reducción de Swap en un Volumen Lógico LVM2
5.3.2. Eliminación de un Volumen Lógico LVM2 por Swap
5.3.3. Eliminar el Archivo Swap
5.4. Mover el espacio Swap
6. Gestión del almacenamiento en disco
6.1. Particiones Estándares utilizando parted
6.1.1. Visualizar la tabla de particiones
6.1.2. Creación de una partición
6.1.3. Eliminar una partición
6.1.4. Redimensionar una partición
6.2. Administración de la Partición LVM
7. Implementación de cuotas de disco
7.1. Configuración de cuotas de disco
7.1.1. Activar cuotas
7.1.2. Volver a montar un sistema de archivos
7.1.3. Creación de Archivos de Base de Datos de Cuotas
7.1.4. Asignación de cuotas por usuario
7.1.5. Asignación de cuotas por grupo
7.1.6. Configuración del Periodo de Gracia de los Límites Suaves
7.2. Administración de cuotas de disco
7.2.1. Activación y desactivación de cuotas
7.2.2. Informes de cuotas de disco
7.2.3. Mantenimiento de la precisión de las cuotas
7.3. Recursos adicionales
7.3.1. Documentación instalada
7.3.2. Libros relacionados
8. Listas de Control de Acceso
8.1. Montaje de sistemas de archivos
8.1.1. NFS
8.2. Configuración de acceso a ACLs
8.3. Configurar ACLs predeterminados
8.4. Recuperar ACLs
8.5. Archivar sistemas de archivos con ACLs
8.6. Compatibilidad con sistemas antiguos
8.7. Recursos adicionales
8.7.1. Documentación instalada
8.7.2. Sitios Web de utilidad
9. LVM (Administrador de Volúmenes Lógicos)
9.1. ¿Qué es LVM?
9.1.1. ¿Qué es LVM2?
9.2. Configuración de LVM
9.3. Particionamiento automático
9.4. Particionamiento manual de LVM
9.4.1. Creación de la partición /boot/
9.4.2. Creación de los volúmenes físicos LVM
9.4.3. Crear el grupo de volúmenes LVM
9.4.4. Creación de volúmenes lógicos LVM
9.5. Usar la utilidad LVM system-config-lvm
9.5.1. Uso de entidades no incializadas
9.5.2. Añadir volúmened no asignados a un grupo de volúmenes
9.5.3. Migración de extenciones
9.5.4. Añadir un nuevos disco duro utilizando LVM
9.5.5. Añadir un nuevo grupo de volúmenes
9.5.6. Entensión de un grupo de volúmenes
9.5.7. Modificación de un volumen lógico
9.6. Recursos adicionales
9.6.1. Documentación instalada
9.6.2. Sitios Web de utilidad
II. Administración de paquetes
10. Administración de paquetes con RPM
10.1. Metas de diseño RPM
10.2. El uso de RPM
10.2.1. Encontrar paquetes RPM
10.2.2. Instalación de RPM
10.2.3. Desinstalación
10.2.4. Actualización
10.2.5. Refrescamiento
10.2.6. Consultas
10.2.7. Verificación
10.3. Verificando la firma del paquete
10.3.1. Importar claves
10.3.2. Verificación de la firma de paquetes
10.4. Ejemplos comunes y prácticos sobre el uso de RPM
10.5. Recursos adicionales
10.5.1. La documentación instalada
10.5.2. Sitios web útiles
10.5.3. Libros relacionados
11. Herramienta de administración de paquetes
11.1. Listar y analizar paquetes
11.2. Instalación y Eliminación de paquetes
12. YUM (Yellowdog Updater Modified)
12.1. Setting Up a yum Repository
12.2. yum Commands
12.3. yum Options
12.4. Configuring yum
12.4.1. [main] Options
12.4.2. [repository] Options
12.5. Useful yum Variables
13. Red Hat Network
III. Configuración relacionada a la red
14. Interfaces de red
14.1. Archivos de configuración de red
14.2. Archivos de configuración de interfaz
14.2.1. Interfaces Ethernet
14.2.2. Interfaces IPsec
14.2.3. Interfaces de unión de canales
14.2.4. Archivos alias y clon
14.2.5. Interfaces de acceso telefónico
14.2.6. Otras interfaces
14.3. Scripts de control de interfaz
14.4. Configuring Static Routes
14.5. Archivos de funciones de red
14.6. Recursos adicionales
14.6.1. Documentación instalada
15. Configuración de la red
15.1. Resumen
15.2. Conexión Ethernet
15.3. Conexión RDSI
15.4. Conexión vía módem
15.5. Conexión xDSL
15.6. Conexión Token Ring
15.7. Conexión de tipo inalámbrica
15.8. Administración de los parámetros DNS
15.9. Administración de hosts
15.10. Funcionamiento con perfiles
15.11. Alias de dispositivo
15.12. Guardar y recuperar la configuración de la red
16. Control de acceso a servicios
16.1. Niveles de ejecución
16.2. TCP Wrappers
16.2.1. xinetd
16.3. Herramienta de configuración de servicios
16.4. ntsysv
16.5. chkconfig
16.6. Recursos adicionales
16.6.1. Documentación instalada
16.6.2. Sitios Web útiles
17. Berkeley Internet Name Domain (BIND)
17.1. Introducción a DNS
17.1.1. Zonas de servidores de nombres
17.1.2. Tipos de servidores de nombres
17.1.3. BIND como un servidor de nombres
17.2. /etc/named.conf
17.2.1. Tipos de declaraciones comúnes
17.2.2. Otros tipos de declaraciones
17.2.3. Etiquetas de comentarios
17.3. Archivos de zona
17.3.1. Directivas de archivos de zona
17.3.2. Registros de recursos de archivos de zona
17.3.3. Ejemplo de archivo de zonas
17.3.4. Archivos de zona de resolución de nombres inversa
17.4. Uso de rndc
17.4.1. Configuración de /etc/named.conf
17.4.2. Configuración de /etc/rndc.conf
17.4.3. Opciones de línea de comandos
17.5. Características avanzadas de BIND
17.5.1. Mejoras al protocolo DNS
17.5.2. Vistas múltiples
17.5.3. Seguridad
17.5.4. IP versión 6
17.6. Errores comunes que debe evitar
17.7. Recursos adicionales
17.7.1. Documentación instalada
17.7.2. Sitios web de utilidad
17.7.3. Libros relacionados
18. OpenSSH
18.1. Características de SSH
18.1.1. ¿Por qué usar SSH?
18.2. Versiones del protocolo SSH
18.3. Secuencia de eventos de una conexión SSH
18.3.1. Capa de transporte
18.3.2. Autenticación
18.3.3. Canales
18.4. Configurar un servidor OpenSSH
18.4.1. Requiriendo SSH para conexiones remotas
18.5. Archivos de configuración de OpenSSH
18.6. Configuración de un cliente OpenSSH
18.6.1. Uso del comando ssh
18.6.2. Usando el comando scp
18.6.3. Uso del comando sftp
18.7. Más que un Shell seguro
18.7.1. Reenvío por X11
18.7.2. Reenvío del puerto
18.7.3. Generar pares de claves
18.8. Recursos adicionales
18.8.1. Documentación instalada
18.8.2. Sitios web útiles
19. Sistema de archivos de red (NFS)
19.1. Funcionamiento
19.1.1. Servicios requeridos
19.2. Configuración de clientes NFS
19.2.1. Montaje del sistemas de archivos NFS con /etc/fstab
19.3. autofs
19.3.1. Nuevas características de la versión 5 de autofs
19.3.2. Configuración de autofs
19.3.3. Tareas comunes autofs
19.4. Opciones de montaje NFS comunes
19.5. Iniciar y detener NFS
19.6. Configuración del servidor NFS
19.6.1. Exportar o compartir sistemas de archivos NFS
19.6.2. Configuración desde la línea de comandos
19.6.3. Formatos del nombre de host
19.7. El archivo de configuración /etc/exports
19.7.1. El comando exportfs
19.8. Protección de NFS
19.8.1. Acceso al sistema
19.8.2. Permisos de archivos
19.9. NFS y portmap
19.9.1. Solución de problemas de NFS y portmap
19.10. Uso de NFSv4 sobre TCP
19.11. Recursos adicionales
19.11.1. Documentación instalada
19.11.2. Sitios Web útiles
19.11.3. Libros sobre el tema
20. Samba
20.1. Introducción a Samba
20.1.1. Características de Samba
20.2. Demonios Samba y Servicios relacionados
20.2.1. Demonios Samba
20.3. Conexión a un recurso compartido Samba
20.3.1. Línea de comandos
20.3.2. Montar el recurso compartido Samba
20.4. Configuración del servidor Samba
20.4.1. Configuración gráfica
20.4.2. Configuración desde la línea de comandos
20.4.3. Contraseñas encriptadas
20.5. Arrancar y detener el Samba
20.6. Tipos de servidores Samba y el archivo smb.conf
20.6.1. Servidor independiente
20.6.2. Servidor miembro de dominio
20.6.3. Domain Controller
20.7. Modos de seguridad Samba
20.7.1. Seguridad a nivel de usuario
20.7.2. Seguridad a nivel de usuarios
20.8. Bases de datos de información de cuentas Samba
20.9. Navegación de red con Samba
20.9.1. Navegación de dominios
20.9.2. WINS (Windows Internetworking Name Server)
20.10. Samba con soporte para la impresión con CUPS
20.10.1. Configuraciones simples de smb.conf
20.11. Programas de distribución Samba
20.12. Recursos adicionales
20.12.1. Documentación instalada
20.12.2. Libros relacionados
20.12.3. Sitios web útiles
21. Protocolo de Configuración Dinámica de Hosts (DHCP)
21.1. Motivos para usar el protocolo DHCP
21.2. Configuración de un servidor DHCP
21.2.1. Archivo de configuración
21.2.2. Base de datos de arrendamiento
21.2.3. Iniciar y detener el servidor
21.2.4. Agente de transmisión DHCP
21.3. Configuración de un cliente DHCP
21.4. Recursos adicionales
21.4.1. Documentación instalada
22. Servidor HTTP Apache
22.1. Servidor HTTP Apache Versión 2.2
22.1.1. Características del Servidor HTTP Apache Versión 2.2
22.2. Migración de los Archivos de Configuración del Servidor HTTP Apache
22.2.1. Migración de los Archivos de Configuración del Servidor HTTP Apache Versión 2.0.
22.2.2. Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0
22.3. Arrancar y detener httpd
22.4. Configuración del Servidor HTTP Apache
22.4.1. Configuración Básica
22.4.2. Configuraciones predeterminadas
22.5. Directrices de configuración en httpd.conf
22.5.1. Sugerencias de configuración generales
22.5.2. Configuración de directrices para SSL
22.5.3. Directrices MPM específicas al pool de servidores
22.6. Añadir módulos
22.7. Hosts virtuales
22.7.1. Configuración de máquinas virtuales
22.8. Configuración del Servidor Seguro Apache HTTP
22.8.1. Vista preliminar de los paquetes relacionados con la seguridad
22.8.2. Vista preliminar de certificados y seguridad
22.8.3. Uso de claves y certificados preexistentes
22.8.4. Tipos de certificados
22.8.5. Generar una clave
22.8.6. Cómo configurar el servidor para utilizar la nueva clave
22.9. Recursos adicionales
22.9.1. Sitios Web de utilidad
23. FTP
23.1. El Protocolo de Transferencia de Archivos
23.1.1. Puertos múltiples, modos múltiples
23.2. Servidores FTP
23.2.1. vsftpd
23.3. Archivos instalados con vsftpd
23.4. Iniciar y detener vsftpd
23.4.1. Iniciar múltiples copias de vsftpd
23.5. Opciones de configuración vsftpd
23.5.1. Opciones de demonios
23.5.2. Opciones de conexión y control de acceso
23.5.3. Opciones de usuario anónimo
23.5.4. Opciones del usuario local
23.5.5. Opciones de directorio
23.5.6. Opciones de transferencia de archivos
23.5.7. Opciones de conexión
23.5.8. Opciones de red
23.6. Recursos adicionales
23.6.1. Documentación instalada
23.6.2. Sitios web de utilidad
24. Correo electrónico
24.1. Protocolos de correo electrónico
24.1.1. Protocolos de transporte de correo
24.1.2. Protocolos de acceso a correo
24.2. Clasificaciones de los programas de correo
24.2.1. Agente de Transporte de Correo
24.2.2. Agente de entrega de correos
24.2.3. Agente de usuario de correo
24.3. Agentes de transporte de correo
24.3.1. Sendmail
24.3.2. Postfix
24.3.3. Fetchmail
24.4. Configuración del Agente de Transporte de Correo (MTA)
24.5. Agente de entrega de correo
24.5.1. Configuración de Procmail
24.5.2. Recetas de Procmail
24.6. Agentes de usuario de correo
24.6.1. Comunicación segura
24.7. Recursos adicionales
24.7.1. Documentación instalada
24.7.2. Sitios web útiles
24.7.3. Libros relacionados
25. Protocolo Ligero de Acceso a Directorios (LDAP)
25.1. Razones por las cuales usar LDAP
25.1.1. Características de OpenLDAP
25.2. Terminología LDAP
25.3. Demonios y utilidades OpenLDAP
25.3.1. NSS, PAM, y LDAP
25.3.2. PHP4, LDAP y el Servidor HTTP Apache
25.3.3. Aplicaciones cliente LDAP
25.4. Archivos de configuración de OpenLDAP
25.5. El directorio /etc/openldap/schema/
25.6. Descripción general de la configuración de OpenLDAP
25.6.1. Modificar /etc/openldap/slapd.conf
25.7. Configurar un sistema para la autenticación mediante OpenLDAP
25.7.1. PAM y LDAP
25.7.2. Migrar la información de autenticación antigua al formato LDAP
25.8. Migración de directorios desde versiones anteriores
25.9. Recursos adicionales
25.9.1. Documentación instalada
25.9.2. Sitios web útiles
25.9.3. Libros relacionados
26. Configuración de la autenticación
26.1. Información del usuario
26.2. Autenticación
26.3. Options
26.4. Versión de línea de comandos
IV. Configuración del sistema
27. Acceso a consola
27.1. Deshabilitando el apagado a través de Ctrl-Alt-Del
27.2. Desactivación del acceso a programas de la consola
27.3. Definición de la consola
27.4. Colocar los archivos accesibles desde la consola
27.5. Activación del acceso a la consola para otras aplicaciones
27.6. El Grupo floppy
28. El directorio sysconfig
28.1. Archivos en el directorio /etc/sysconfig/
28.1.1. /etc/sysconfig/amd
28.1.2. /etc/sysconfig/apmd
28.1.3. /etc/sysconfig/arpwatch
28.1.4. /etc/sysconfig/authconfig
28.1.5. /etc/sysconfig/autofs
28.1.6. /etc/sysconfig/clock
28.1.7. /etc/sysconfig/desktop
28.1.8. /etc/sysconfig/dhcpd
28.1.9. /etc/sysconfig/exim
28.1.10. /etc/sysconfig/firstboot
28.1.11. /etc/sysconfig/gpm
28.1.12. /etc/sysconfig/hwconf
28.1.13. /etc/sysconfig/i18n
28.1.14. /etc/sysconfig/init
28.1.15. /etc/sysconfig/ip6tables-config
28.1.16. /etc/sysconfig/iptables-config
28.1.17. /etc/sysconfig/irda
28.1.18. /etc/sysconfig/keyboard
28.1.19. /etc/sysconfig/kudzu
28.1.20. /etc/sysconfig/named
28.1.21. /etc/sysconfig/network
28.1.22. /etc/sysconfig/nfs
28.1.23. /etc/sysconfig/ntpd
28.1.24. /etc/sysconfig/radvd
28.1.25. /etc/sysconfig/samba
28.1.26. /etc/sysconfig/selinux
28.1.27. /etc/sysconfig/sendmail
28.1.28. /etc/sysconfig/spamassassin
28.1.29. /etc/sysconfig/squid
28.1.30. /etc/sysconfig/system-config-securitylevel
28.1.31. /etc/sysconfig/system-config-selinux
28.1.32. /etc/sysconfig/system-config-users
28.1.33. /etc/sysconfig/system-logviewer
28.1.34. /etc/sysconfig/tux
28.1.35. /etc/sysconfig/vncservers
28.2. Directorios en el directorio /etc/sysconfig/
28.3. Recursos adicionales
28.3.1. Documentación instalada
29. Configuración de la fecha y hora
29.1. Propiedades de hora y fecha
29.2. Propiedades del protocolo de tiempo de red (NTP)
29.3. Configuración de la zona horaria
30. Configuración del Teclado
31. El Sistema X Window
31.1. El lanzamiento X11R7.1
31.2. Entornos de escritorio y gestores de ventanas
31.2.1. Entornos de escritorio
31.2.2. Gestores de ventanas
31.3. Archivos de configuración del servidor X
31.3.1. xorg.conf
31.4. Fuentes
31.4.1. Fontconfig
31.4.2. Sistema de fuentes base de X
31.5. Niveles de ejecución y X
31.5.1. Nivel de ejecución 3
31.5.2. Nivel de ejecución 5
31.6. Recursos adicionales
31.6.1. Documentación instalada
31.6.2. Sitios Web útiles
32. Configuración del Sistema X Window
32.1. Configuraciones de la visualización
32.2. Configuraciones del hardware de visualización
32.3. Configuraciones de visualización en dos pantallas
33. Usuarios y grupos
33.1. Configuración de grupos y de usuarios
33.1.1. Añadir un nuevo usuario
33.1.2. Modificar las propiedades del usuario
33.1.3. Añadir un nuevo grupo
33.1.4. Modificar las propiedades del grupo
33.2. Herramientas de administración de usuarios y grupos
33.2.1. Configuración desde la línea de comandos
33.2.2. Añadir un usuario
33.2.3. Añadir un grupo
33.2.4. Vencimiento de la contraseña
33.2.5. Explicación del proceso
33.3. Usuarios estándar
33.4. Grupos estándar
33.5. Grupos de usuario privado
33.5.1. Directorios de grupos
33.6. Contraseñas Shadow
33.7. Recursos adicionales
33.7.1. Documentación instalada
34. Configuración de la impresora
34.1. Añadir una impresora local
34.2. Añadir una impresora de red IPP
34.3. Añadir una impresora Samba (SMB)
34.4. Añadir una Impresora JetDirect
34.5. Selección del modelo de impresora
34.5.1. Confirmación de la configuración de la impresora
34.6. Imprimiendo una página de prueba
34.7. Modificar impresoras existentes
34.7.1. La pestaña Configuración
34.7.2. La pestaña Políticas
34.7.3. La Pestaña Control de Acceso
34.7.4. Las pestañas Opciones de la Impresora y Opciones de Trabajo
34.8. Administración de trabajos de impresión
34.9. Recursos adicionales
34.9.1. Documentación instalada
34.9.2. Sitios Web de utilidad
35. Tareas automáticas
35.1. Cron
35.1.1. Configuración de una tarea Cron
35.1.2. Control de acceso a Cron
35.2. At y Batch
35.2.1. Configuración de tareas
35.2.2. Configuración de tareas Batch
35.2.3. Visualización de las tareas pendientes
35.2.4. Opciones adicionales de la línea de comandos
35.2.5. Control de acceso a At y Batch
35.3. Recursos adicionales
35.3.1. Documentación instalada
36. Archivos de registro
36.1. Localizar archivos de registro
36.2. Visualizar los archivos de registro
36.3. Añadir un archivo de registro
36.4. Control de Archivos de Registro
V. Supervisión del sistema
37. SystemTap
37.1. Introducción
37.2. Implementación
37.3. Utilización de System Tap
37.3.1. Rastreo
38. Reunir información del sistema
38.1. Procesos del sistema
38.2. Utilización de memoria
38.3. Sistemas de archivos
38.4. Hardware
38.5. Recursos adicionales
38.5.1. Documentación instalada
39. OProfile
39.1. Descripción general de las herramientas
39.2. Configuración de Oprofile
39.2.1. Especificar el Kernel
39.2.2. Configurar los eventos a supervisar
39.2.3. Separar perfiles del Kernel y del espacio del usuario
39.3. Iniciar y detener Oprofile
39.4. Guardar los datos
39.5. Análisis de los datos
39.5.1. Utilizando opreport
39.5.2. Utilizando opreport en un Ejecutable Unico
39.5.3. Obtener salidas más detalladas sobre los módulos
39.5.4. Utilizando opannotate
39.6. Comprender /dev/oprofile/
39.7. Ejemplo de uso
39.8. Interfaz gráfica
39.9. Recursos adicionales
39.9.1. Documentos instalados
39.9.2. Sitios Web útiles
VI. Configuración del Kernel y los dispositivos
40. Actualización Manual del Kernel
40.1. Descripción general de los Paquetes del Kernel
40.2. Preparación para la actualización
40.3. Descarga
40.4. Realizando la actualización
40.5. Verificación de la imagen de disco RAM inicial
40.6. Configuración del gestor de arranque
40.6.1. Sistemas x86
40.6.2. Sistemas Itanium
40.6.3. Sistemas IBM S/390 e IBM System z
40.6.4. Sistemas IBM eServer iSeries
40.6.5. Sistemas IBM eServer pSeries
41. Parámetros y Módulos Generales
41.1. Utilidades del Módulo del Kernel
41.2. Carga Persistente de Módulos
41.3. Especificar parámetros de módulos
41.4. Parámetros de Almacenamiento
41.5. Parámetros Ethernet
41.5.1. Utilización de Múltiples Tarjetas Ethernet
41.5.2. El Módulo del canal de vinculación (Bonding)
41.6. Recursos adicionales
41.6.1. Documentación instalada
41.6.2. Sitios Web útiles
VII. Seguridad y autenticación
42. Generalidades concernientes a la seguridad
42.1. Evaluación de vulnerabilidad
42.1.1. Pensando como el enemigo
42.1.2. Definición de la evaluación y pruebas
42.1.3. Evaluación de herramientas
42.2. Ataques y vulnerabilidades
42.2.1. Una breve historia sobre los hackers
42.2.2. Amenazas a la Seguridad de la red
42.2.3. Amenazas a la seguridad de servidores
42.2.4. Amenazas a la seguridad de estaciones de trabajo y PCs del hogar
42.3. Ataques y agresiones comunes
42.4. Actualizaciones de seguridad
42.4.1. Actualización de paquetes
43. Aseguramiento de su Red
43.1. Seguridad en las estaciones de trabajo
43.1.1. Evaluando la seguridad en la estación de trabajo
43.1.2. Seguridad del BIOS y del gestor de arranque
43.1.3. Seguridad de contraseñas
43.1.4. Controles administrativos
43.1.5. Servicios de red disponibles
43.1.6. Cortafuegos personales
43.1.7. Herramientas de mejoramiento de la seguridad
43.2. Seguridad de servidores
43.2.1. Asegurando los servicios con TCP Wrappers y xinetd
43.2.2. Protección de Portmap
43.2.3. Protección de NIS
43.2.4. Protección de NFS
43.2.5. Protegiendo el servidor Apache HTTP
43.2.6. Protección de FTP
43.2.7. Asegurando Sendmail
43.2.8. Verificar cuáles puertos están escuchando
43.3. Single Sign-on (SSO)
43.3.1. Introducción
43.3.2. Iniciando con su nueva tarjeta inteligente
43.3.3. Cómo funciona la inscripción de las tarjetas inteligentes
43.3.4. Cómo funciona el registro de las tarjetas inteligentes
43.3.5. Configuración de Firefox para utilizar Kerberos con SSO
43.4. Pluggable Authentication Modules (PAM)
43.4.1. Las ventajas de PAM
43.4.2. archivos de configuración PAM
43.4.3. Formato del archivo de configuración PAM
43.4.4. Muestras de archivos de configuración PAM
43.4.5. Creación de módulos PAM
43.4.6. PAM y el caché de credenciales administrativas
43.4.7. PAM y propiedad del dispositivo
43.4.8. Recursos adicionales
43.5. TCP Wrappers y xinetd
43.5.1. Wrappers TCP
43.5.2. Archivos de configuración de Wrappers TCP
43.5.3. xinetd
43.5.4. Archivos de configuración de xinetd
43.5.5. Recursos adicionales
43.6. Redes privadas virtuales (VPNs)
43.6.1. ¿Cómo funciona un VPN?
43.6.2. VPNs y Red Hat Enterprise Linux
43.6.3. IPsec
43.6.4. Creando una conexión IPsec
43.6.5. Instalación de IPsec
43.6.6. Configuración IPsec de host-a-host
43.6.7. Configuración de IPsec de red-a-red
43.6.8. Iniciando y deteniendo conexiones IPsec
43.7. IPTables
43.7.1. Filtrado de paquetes
43.7.2. Diferencias entre IPTables y IPChains
43.7.3. Opciones de comandos para IPTables
43.7.4. Guardando reglas IPTables
43.7.5. Scripts de control de IPTables
43.7.6. IPTables y IPv6
43.7.7. Recursos adicionales
44. Seguridad y SELinux
44.1. Mecanismos de Control de Acceso (ACMs)
44.1.1. Control de Acceso Discrecional (DAC)
44.1.2. Control de Acceso Mandatorio (MAC)
44.1.3. Control de Acceso basado en Roles (RBAC)
44.1.4. Seguridad Multi-Nivel (MLS)
44.2. Introducción a SELinux
44.2.1. Sinopsis de SELinux
44.2.2. Archivos relacionados con SELinux
44.2.3. Recursos adicionales
44.3. Antecedentes e historia de SELinux
44.4. Multi-Category Security (MCS)
44.4.1. Introducción
44.4.2. Aplicaciones para Seguridad Multi-Categoría
44.4.3. Contextos de Seguridad de SELinux
44.5. Getting Started with Multi-Category Security (MCS)
44.5.1. Introduction
44.5.2. Comparing SELinux and Standard Linux User Identities
44.5.3. Configuring Categories
44.5.4. Assigning Categories to Users
44.5.5. Assigning Categories to Files
44.6. Seguridad Multi-Nivel (MLS)
44.6.1. ¿Por qué Multi-Nivel?
44.6.2. Niveles de Seguridad, Objetos y Sujetos
44.6.3. Política MLS
44.6.4. Certificación LSPP
44.7. Sinopsis de las Políticas de SELinux
44.7.1. ¿Qué es la Política SELinux?
44.7.2. ¿Dónde se encuentra la Política?
44.7.3. El Papel de la Política durante el Proceso de Arranque
44.7.4. Clases de Objetos y Permisos
44.8. Sinopsis de la Política de Objetivos
44.8.1. ¿Qué es la Política Objetivo?
44.8.2. Archivos y Directorios de la Política Objetivo
44.8.3. Usuarios y Roles en la Política Objetivo
45. Trabajar con SELinux
45.1. Control de Usuario Final de SELinux
45.1.1. Mover y Copiar Archivos
45.1.2. Verificar el Contexto de Seguridad de un Proceso, Usuario u Objeto de Archivo
45.1.3. Nuevas Etiquetas para un Archivo o Directorio
45.1.4. Creación de Archivos que Retienen Contextos de Seguridad
45.2. Controles administrativos de SELinux
45.2.1. Ver el Estado de SELinux
45.2.2. Creación de Etiquetas Nuevas para Sistemas de Archivos
45.2.3. Administración de Directorios Principales NFS
45.2.4. Otorgar Acceso a un Directorio o a un Arbol
45.2.5. Copias de Seguridad y Restauración del Sistema
45.2.6. Activación o Desactivación del Refuerzo
45.2.7. Activar o Desactivar SELinux
45.2.8. Cambio de la Política
45.2.9. Especificación del Contexto de Seguridad del Sistema de Archivos Entero
45.2.10. Cambio de la Categoria de Seguridad de un Archivo o Usuario
45.2.11. Ejecución de un Comando en un Contexto de Seguridad Especifico
45.2.12. Comandos Utiles para Scripts
45.2.13. Cambio a un Rol Diferente
45.2.14. Cuando Reiniciar
45.3. Control Analista de SELinux
45.3.1. Activación de la Auditoría de Kernel
45.3.2. Volcado y Vista de Registros
46. Customizing SELinux Policy
46.1. Introduction
46.1.1. Modular Policy
46.2. Building a Local Policy Module
46.2.1. Using audit2allow to Build a Local Policy Module
46.2.2. Analyzing the Type Enforcement (TE) File
46.2.3. Loading the Policy Package
47. Referencias

Introducción

Bienvenido al Manual de implementación de Red Hat Enterprise Linux.

El Manual de implementación de Red Hat Enterprise Linux contiene información sobre cómo personalizar su sistema Red Hat Enterprise Linux para satisfacer sus necesidades. Si está buscando una guía completa, orientada a tareas para la configuración y personalización de su sistema, este es el manual que está buscando.

Esta manual asume que usted comprende los conceptos básicos relacionados con su sistema Red Hat Enterprise Linux. Si necesita ayuda para instalar Red Hat Enterprise Linux, consulte el Manual de instalación de Red Hat Enterprise Linux.

1. Convenciones del documento

En este manual ciertas palabras utilizan diferentes tipos de letras, tamañosy pesos. Este énfasis es sistemático; diferentes palabras se representan con el mismo estilo para indicar su inclusión en una categoria específica. Los tipos de palabras que se representan de esta manera son:

comandos

Los comandos en Linux (y comandos de otros sistemas operativos, cuando estos se utilicen) se representan de esta manera. Este estilo le indica que puede escribir la palabra o frase en la línea de comandos y pulsarIntro para invocar el comando. A veces un comando contiene palabras que aparecerían con un estilo diferente si estuvieran solas (por ejemplo, nombres de archivos). En estos casos, se las considera como parte del comando, de manera que toda la frase aparece como un comando. Por ejemplo:

Utilice el comando cat testfile para ver el contenido de un archivo, llamado testfile en el directorio actual.

nombres de archivos

Los nombres de archivos, nombres de directorios, rutas y nombres de rutas y paquetes RPM aparecen siempre en este modo. Este estilo indica que un archivo o directorio en particular existe con ese nombre en su sistema. Ejemplos:

El archivo .bashrc en su directorio principal contiene definiciones de la shell de bash y alias para su propio uso.

El archivo /etc/fstab contiene información sobre diferentes dispositivos del sistema y sistemas de archivos.

Instale el RPM webalizer si quiere utilizar un programa de análisis del archivo de registro del servidor Web.

aplicaciones

Este estilo indica que el programa es una aplicación de usuario final (lo contrario a software del sistema). Por ejemplo:

Utilice Mozilla para navegar por la Web.

tecla

Una tecla del teclado aparece en el siguiente estilo. Por ejemplo:

Para utilizar la completación con Tab para enumerar los archivos en particular en un directorio, escriba ls luego un caracter y finalmente pulse la tecla Tab. Aparecerá una lista de archivos en el directorio que empiezan con esa letra.

tecla-combinación

Una combinación de teclas aparece de la siguiente manera. Por ejemplo:

La combinación de teclas Ctrl-Alt-Retroceso terminará la sesión gráfica y lo llevará a la pantalla gráfica de inicio de sesión o a la consola.

texto de una interfaz gráfica (GUI)

Un título, palabra o frase encontrada en una pantalla o ventana en la interfaz gráfica aparecerá en este estilo. La finalidad del texto escrito en este estilo es la de identificar una pantalla GUI particular o un elemento en una pantalla gráfica (p.ej. un texto relacionado con una casilla de verificación o un campo). Ejemplos:

Seleccione la casilla de verificación Pedir contraseña si quiere que su salvapantallas pida una contraseña antes de terminar.

nivel superior de un menú en una pantalla o ventana GUI

Cuando vea una palabra con este estilo, significa que la palabra está en el nivel superior de un menú desplegable. Si hace clic sobre la palabra en la pantalla GUI, aparecerá el resto del menú. Por ejemplo:

Bajo Archivo en una terminal de GNOME, la opción Nueva solapa le permite abrir múltiples intérpretes de comandos de la shell en la misma ventana.

Las instrucciones para escribir una secuencia de comandos desde un menú GUI aparecerán como en el siguiente ejemplo:

Vaya a Aplicaciones (el menú principal en el panel) => Programación => Editor de texto Emacs para iniciar el editor de texto Emacs.

botón en una pantalla o ventana GUI

Este estilo indica que el texto puede encontrarse en un botón que se puede pulsar en una pantalla GUI. Por ejemplo:

Pulse el botón Anterior para volver a la última página Web que haya visitado.

salida del computador

El texto en este estilo indica el texto desplegado en un intérprete de comandos de la shell, tales como mensajes de error y respuestas a comandos. Por ejemplo:

Utilice el comando ls para visualizar los contenidos de un directorio. Por ejemplo:

Desktop    about.html    logs     paulwesterberg.png
Mail    backupfiles    mail     reports

La salida de pantalla que un comando retorna (en este caso el contenido del directorio) se mostrará en este estilo.

intérprete de comandos

El intérprete de comandos es el modo en el que el ordenador le indica que está preparado para que usted introduzca algo, aparecerá con el siguiente estilo. Ejemplos:

$

#

[stephen@maturin stephen]$

leopard login:

entrada de usuario

El texto que el usuario tiene que escribir, ya sea en la línea de comandos o en una casilla de texto de una pantalla GUI, se visualizará en este estilo. En el siguiente ejemplo, text se presenta en este estilo:

Para arrancar su sistema en el programa de instalación en modo texto, necesitará escribir el comando text en el intérprete de comandos boot:.

<reemplazable>

El texto usado en los ejemplos, que se supone debe ser reemplazado con datos proporcionados por el usuario, se representa en este estilo. En el siguiente ejemplo, <número-versión> se mostrará en este estilo:

El directorio para la fuente del kernel es /usr/src/kernels/<número-versión>/, donde <número-versión> es la versión del kernel instalado en este sistema.

Adicionalmente, usamos diferentes tipos de estrategias para llamar su atención sobre determinados tipos de información. Dependiendo de la importancia de esta información, estos elementos serán marcados como nota, sugerencia, importante, atención o aviso. Por ejemplo:

Nota

Recuerde que Linux es sensible a mayúsculas y minúsculas. En otras palabras, rosa no es lo mismo que ROSA o rOsA.

Sugerencia

El directorio /usr/share/doc/ contiene documentación adicional de los paquetes instalados en su sistema.

Importante

Si modifica el archivo de configuración de DHCP, los cambios no surtirán efecto sino hasta que reinicie el demonio DHCP.

Advertencia

No lleve a cabo tareas rutinarias como root — utilice una cuenta de usuario normal a menos que necesite usar la cuenta de root para administrar su sistema.

Aviso

Tenga cuidado de borrar solamente las particiones necesaria. Remover otras particiones puede resultar en perdida de datos o en un entorno de sistema corrupto.

2. Envíenos su opinión

Si encuentra algún error en el Manual de implementación de Red Hat Enterprise Linux, o si se le ha ocurrido una manera de mejorar este manual, nos encantaría escuchar sus comentarios. Por favor envíe un informe a Bugzilla (http://bugzilla.redhat.com/bugzilla/) contra el componente Deployment_Guide.

Si tiene alguna sugerencia para mejorar la documentación, trate de ser tan específico como sea posible. Si ha encontrado un error, por favor incluya el número de la sección y parte del texto alrededor del error para que así lo podamos localizar rápidamente.

Parte I. Sistemas de archivos

El Sistema de archivos hace referencia a los directorios y archivos almacenados en un computador. Un sistema de archivos puede tener diferentes formatos llamados tipos de sistemas de archivos. Estos formatos determinan la forma en que los archivos y directorios son almacenados. Algunos sistemas de archivos almacenan copias redundantes de los datos mientras que otros archivos permiten un fácil acceso al disco duro. Esta sección discute los tipos de archivos ext3, swap, RAID y LVM. Asimismo discute la utilidad parted utilizada para administrar particiones y las listas de control de acceso (ACL) usadas para personalizar los permisos a los archivos.

Tabla de contenidos

1. Estructura del sistema de archivos
1.1. Por qué compartir una estructura común
1.2. Vista preliminar del estándar de jerarquía del sistema de archivos (FHS)
1.2.1. Organización de FHS
1.3. Ubicación de Archivos Especiales bajo Red Hat Enterprise Linux
2. Sistema de archivos ext3
2.1. Características de ext3
2.2. Creación de un sistema de archivos ext3
2.3. Conversión a un sistema de archivos ext3
2.4. Volver al sistema de archivos ext2
3. El sistema de archivos /proc
3.1. Sistema de archivos virtual
3.1.1. Visualización de archivos virtuales
3.1.2. Cambiar archivos virtuales
3.2. Archivos de alto nivel en el sistema de archivos proc
3.2.1. /proc/apm
3.2.2. /proc/buddyinfo
3.2.3. /proc/cmdline
3.2.4. /proc/cpuinfo
3.2.5. /proc/crypto
3.2.6. /proc/devices
3.2.7. /proc/dma
3.2.8. /proc/execdomains
3.2.9. /proc/fb
3.2.10. /proc/filesystems
3.2.11. /proc/interrupts
3.2.12. /proc/iomem
3.2.13. /proc/ioports
3.2.14. /proc/kcore
3.2.15. /proc/kmsg
3.2.16. /proc/loadavg
3.2.17. /proc/locks
3.2.18. /proc/mdstat
3.2.19. /proc/meminfo
3.2.20. /proc/misc
3.2.21. /proc/modules
3.2.22. /proc/mounts
3.2.23. /proc/mtrr
3.2.24. /proc/partitions
3.2.25. /proc/pci
3.2.26. /proc/slabinfo
3.2.27. /proc/stat
3.2.28. /proc/swaps
3.2.29. /proc/sysrq-trigger
3.2.30. /proc/uptime
3.2.31. /proc/version
3.3. Directorios en /proc/
3.3.1. Directorios de proceso
3.3.2. /proc/bus/
3.3.3. /proc/driver/
3.3.4. /proc/fs
3.3.5. /proc/ide/
3.3.6. /proc/irq/
3.3.7. /proc/net/
3.3.8. /proc/scsi/
3.3.9. /proc/sys/
3.3.10. /proc/sysvipc
3.3.11. /proc/tty/
3.4. Uso del comando sysctl
3.5. Recursos adicionales
3.5.1. Documentación instalada
3.5.2. Sitios web útiles
4. Array Redundante de Discos Independientes (RAID)
4.1. ¿Qué es RAID?
4.2. ¿Quién debe utilizar RAID?
4.3. RAID: Hardware vs. Software
4.3.1. Hardware RAID
4.3.2. Software RAID
4.4. Niveles de RAID y Soporte Lineal
4.5. Configuración de Software RAID
4.5.1. Creación de Particiones RAID
4.5.2. Creación de Dispositivos RAID y Puntos de Montaje
5. Espacio Swap
5.1. ¿Qué es el espacio Swap?
5.2. Añadir el espacio Swap
5.2.1. Extensión de Swap en un Volumen Lógico LVM2
5.2.2. Creación de un Volumen Lógico LVM2 para Swap
5.2.3. Creación de un Archivo Swap
5.3. Eliminar el espacio Swap
5.3.1. Reducción de Swap en un Volumen Lógico LVM2
5.3.2. Eliminación de un Volumen Lógico LVM2 por Swap
5.3.3. Eliminar el Archivo Swap
5.4. Mover el espacio Swap
6. Gestión del almacenamiento en disco
6.1. Particiones Estándares utilizando parted
6.1.1. Visualizar la tabla de particiones
6.1.2. Creación de una partición
6.1.3. Eliminar una partición
6.1.4. Redimensionar una partición
6.2. Administración de la Partición LVM
7. Implementación de cuotas de disco
7.1. Configuración de cuotas de disco
7.1.1. Activar cuotas
7.1.2. Volver a montar un sistema de archivos
7.1.3. Creación de Archivos de Base de Datos de Cuotas
7.1.4. Asignación de cuotas por usuario
7.1.5. Asignación de cuotas por grupo
7.1.6. Configuración del Periodo de Gracia de los Límites Suaves
7.2. Administración de cuotas de disco
7.2.1. Activación y desactivación de cuotas
7.2.2. Informes de cuotas de disco
7.2.3. Mantenimiento de la precisión de las cuotas
7.3. Recursos adicionales
7.3.1. Documentación instalada
7.3.2. Libros relacionados
8. Listas de Control de Acceso
8.1. Montaje de sistemas de archivos
8.1.1. NFS
8.2. Configuración de acceso a ACLs
8.3. Configurar ACLs predeterminados
8.4. Recuperar ACLs
8.5. Archivar sistemas de archivos con ACLs
8.6. Compatibilidad con sistemas antiguos
8.7. Recursos adicionales
8.7.1. Documentación instalada
8.7.2. Sitios Web de utilidad
9. LVM (Administrador de Volúmenes Lógicos)
9.1. ¿Qué es LVM?
9.1.1. ¿Qué es LVM2?
9.2. Configuración de LVM
9.3. Particionamiento automático
9.4. Particionamiento manual de LVM
9.4.1. Creación de la partición /boot/
9.4.2. Creación de los volúmenes físicos LVM
9.4.3. Crear el grupo de volúmenes LVM
9.4.4. Creación de volúmenes lógicos LVM
9.5. Usar la utilidad LVM system-config-lvm
9.5.1. Uso de entidades no incializadas
9.5.2. Añadir volúmened no asignados a un grupo de volúmenes
9.5.3. Migración de extenciones
9.5.4. Añadir un nuevos disco duro utilizando LVM
9.5.5. Añadir un nuevo grupo de volúmenes
9.5.6. Entensión de un grupo de volúmenes
9.5.7. Modificación de un volumen lógico
9.6. Recursos adicionales
9.6.1. Documentación instalada
9.6.2. Sitios Web de utilidad

Capítulo 1. Estructura del sistema de archivos

1.1. Por qué compartir una estructura común

La estructura de un sistema de archivos de un sistema operativo es el nivel más básico de organización. Casi todas las formas en que un sistema operativo interactúa con sus usuarios, aplicaciones y modelos de seguridad dependen de la manera en que almacena y organiza los archivos en los dispositivo de almacenamiento. El proporcionar una estructura de sistema de archivos común asegura que los usuarios y programas pueden acceder y escribir a los archivos.

Los sistemas de archivos dividen los archivos en dos categorías lógicas:

  • archivos compartibles vs. no compartibles

  • archivos variables vs. estáticos

Los archivos compartibles son aquéllos a los que se puede acceder desde varios hosts; mientras que los archivos no compartibles sólo están disponibles localmente. Los archivos variables, tales como documentos, pueden cambiar en cualquier momento; los archivos estáticos, tales como binarios, no cambian sin una actuación por parte del administrador de sistemas.

La razón para visualizar a los archivos de esta manera es para ayudar a correlacionar la función del archivo con los permisos otorgados a los directorios que los sostienen. El modo en que el sistema operativo y sus usuarios interactúan con un archivo dado determina el directorio en el cual estos archivos están ubicados, si ese directorio está montado como de sólo lectura o sólo escritura y el nivel de acceso que cada usuario tiene a ese archivo. El nivel superior de esta organización es crucial. El acceso a los directorios inferiores puede estar restringido o se pueden manifestar problemas de seguridad si el nivel superior es dejado sin organizar o no sigue ninguna estructura rígida.

1.2. Vista preliminar del estándar de jerarquía del sistema de archivos (FHS)

Red Hat Enterprise Linux utiliza la estructura del sistema de archivos Estándar de Jerarquía de Sistemas de archivos (FHS del inglés Filesystem Hierarchy Standard), un documento que define los nombres, la ubicación y los permisos de muchos tipos de archivos y directorios.

El documento que define el FHS es la referencia autorizada para cualquier sistema compatible FHS, sin embargo el estándar da pie a la extensibilidad de unas áreas o no define otras. En esta sección se proporciona un resumen del estándar y una descripción de aquellas partes del sistema de archivos que no cubre el estándar.

El cumplimiento del estándar significa varias cosas, pero los dos aspectos más importantes son la compatibilidad con otros sistemas que siguen el estándar y la capacidad de poder montar la partición /usr/ en modo sólo lectura. Este segundo punto es importante porque el directorio contiene ejecutables comunes y no está pensado para ser alterado por los usuarios. Por este motivo, el directorio /usr/ se monta como de sólo lectura, y esto se puede hacer directamente desde el CD-ROM o desde otro ordenador a través de NFS en modo sólo lectura.

1.2.1. Organización de FHS

Los directorios y archivos aquí anotados, son sólo un subconjunto de los especificados por el FHS. Véase la última versión del FHS para una descripción detallada.

El estándar completo está disponible en línea desde http://www.pathname.com/fhs/.

1.2.1.1. El directorio /boot/

El directorio /boot/ contiene archivos estáticos requeridos para arrancar el sistema, tales como el kernel de Linux. Estos archivos son esenciales para que el sistema arranque correctamente.

Aviso

No elimine el directorio /boot/. Si lo hace, entonces no podrá arrancar su sistema.

1.2.1.2. El directorio /dev/

El directorio /dev/ contiene nodos de dispositivos que representan dispositivos que se encuentran sujetos al sistema o al los dispositivos virtuales que el kernel proporciona. Estos nodos de dispositivo son esenciales para que el sistema funcione apropiadamente. El demonio udev se encarga de crear y eliminar todos estos nodos de dispositivos en /dev/.

Los dispositivos en el directorio y subdirectorios /dev son caracteres (dada solamente una corriente serial de entrada/salida) o bloques (accesible aleatoriamente). Los dispositivos de caracteres incluyen el ratón, le teclado, el módem mientras que los dispositivos de bloques incluyen el disco duro, un disquete, etc. Si tiene instalado GNOME o KDE en su sistema, los dispositivos como discos externos o cds son detectados automáticamente cuando se conectan (por ejemplo, por medio de usb) o insertados (por ejemplo, por medio de dispositivos de CD o DVD) y aparece automáticamente una ventana que muestra el contenido. Los archivos en el directorio /dev son esenciales para que el sistema funcione apropiadamente. Los siguientes son ejemplos de archivos comunes en /dev:

/dev/hda - el dispositivo maestro en el canal IDE primario./dev/hdb - el dispositivo esclavo en el canal IDE primario./dev/tty0 - la primera consola virtual./dev/tty1 - la segunda consola virtual./dev/sda - el primer dispositivo en el canal SCSI o SATA primario./dev/lp0 - primer puerto paralelo.

1.2.1.3. El directorio /etc/

El directorio /etc/ está reservado para los archivos de configuración que son locales a su ordenador. No deben colocarse binarios en /etc/. Los binarios que antiguamente se colocaban en /etc/ deberían de colocarse en /sbin/ o en /bin/.

Ejemplos de directorios en /etc son X11/ y skel/:

 /etc |- X11/ |- skel/

El directorio /etc/X11/ es para los archivos de configuración del sistema de ventanas X como xorg.conf. El directorio /etc/skel/ es para archivos "esqueleto" de usuarios, los cuales se utilizan para rellenar el directorio principal de un usuario la primera vez que este es creado. Las aplicaciones también almacenan sus archivos de configuración en este directorio y puede referenciarlos cuando son ejecutados.

1.2.1.4. El directorio /lib/

El directorio /lib/ debería contener sólo las bibliotecas (libraries) necesarias para ejecutar los binarios en /bin/ y en /sbin/. Estas imágenes de bibliotecas compartidas son particularmente importantes para arrancar el sistema y ejecutar comandos en el sistema de archivos raíz.

1.2.1.5. El directorio /media/

El directorio /media/ contiene los subdirectorios utilizados como puntos de montaje para los medios removibles tales como usbs, DVDs, CD-ROMs y discos Zip.

1.2.1.6. El directorio /mnt/

El directorio /mnt/ está reservado para sistemas de archivos montados temporalmente tales como montajes de sistemas de archivos NFS. Para toda los medios removibles utilice el directorio /media/. Los medios removibles detectados automáticamente serán montados en el directorio /media.

Nota

El directorio /mnt no debe ser utilizado por programas de instalación.

1.2.1.7. El directorio /opt/

El directorio /opt/ proporciona un área para almacenar paquetes de software de una aplicación.

Un paquete que coloca archivos en el directorio /opt/ crea un directorio con el mismo nombre del paquete. Este directorio a su vez, guarda archivos que de otra forma estarían esparcidos por el sistema de archivos, dándole así al administrador del sistema una forma fácil de determinar el papel de cada archivo dentro de un paquete particular.

Por ejemplo, si sample fuese el nombre de un paquete de software particular localizado en el directorio /opt/, entonces todos sus archivos podrían ser emplazados en directorios dentro de /opt/sample/, tales como /opt/sample/bin/ para binarios y /opt/sample/man/ para páginas de manual.

Los paquetes que abarcan diferentes subpaquetes, archivos de datos, extra fuentes, clipart, etc también se ubican dentro del directorio /opt/, aportando a este gran paquete un manera de organizarse. De este modo, el paquete sample puede tener diferentes herramientas que cada una irá en su propio subdirectorio tales como /opt/sample/tool1/ y /opt/sample/tool2/ cada uno de los cuales puede tener su propio bin/, man/ y otros directorios similares.

1.2.1.8. El directorio /proc/

El directorio /proc/ contiene archivos especiales que o bien extraen información del kernel o bien la envían a éste. Algunos ejemplos son la memoria del sistema, información sobre la cpu, configuración del hardware, etc.

Debido a la gran variedad de datos disponibles en /proc/ y a la gran cantidad de maneras que se utiliza este directorio para comunicarse con el kernel, se ha dedicado un capítulo entero a este tema. Para mayor información vea el Capítulo 3, El sistema de archivos /proc.

1.2.1.9. El directorio /sbin/

El directorio /sbin/ almacena los ejecutables utilizados por el usuario root. Los ejecutables en /sbin/ sólo se usan para arrancar, para administración del sistema y para realizar operaciones de recuperación del sistema. De este directorio, la FHS dice:

/sbin contiene los archivos binarios esenciales para arrancar, restaurar, recuperar y/o reparar el sistema además de los binarios en /bin. Los programas ejecutados después de /usr/ son montados (si no surge ningún problema) y ubicados en /usr/sbin. Los programas de administración del sistema instalados localmente se deberían ubicar en /usr/local/sbin.

Los siguientes programas deberían encontrarse, al menos, en /sbin/:

arp, clock, halt, init, fsck.*, grub, ifconfig, mingetty, mkfs.*, mkswap, reboot, route, shutdown, swapoff, swapon

1.2.1.10. El directorio /srv/

El directorio /srv/ contiene datos específicos al sitio proporcionados por su sistema ejecutando Red Hat Enterprise Linux. Este directorio le dá a los usuarios la ubicación de los archivos de datos para un servicio en particular tal como FTP, WWW o CVS. Los datos que sólo pertenecen a un usuario específico deben ir en el directorio /home/.

1.2.1.11. El directorio /sys/

El directorio /sys/ utiliza el nuevo sistema de archivos virtual sysfs específico al kernel 2.6. Ahora con el soporte más extendido para los dispositivos de conexión en caliente (hot plug) en el kernel 2.6, el directorio /sys/ contiene información similar a la que se encuentra en /proc/, pero muestra una vista jerárquica de la información de dispositivos específica con relación a los dispositivos de conexión en caliente.

1.2.1.12. El directorio /usr/

El directorio /usr/ es para archivos que puedan ser compartidos a través de muchas máquinas. El directorio /usr/ habitualmente tiene su propia partición y se monta en sólo lectura. Como mínimo, los siguientes directorios deben ser subdirectorios de /usr/:

 /usr |- bin/ |- etc/ |- games/ |- include/ |- kerberos/ |- lib/ |- libexec/ |- local/ |- sbin/ |- share/ |- src/ |- tmp -> ../var/tmp/

Bajo el directorio /usr/, el subdirectorio bin/ contiene ejecutables, el directorio etc/ contiene archivos de configuración del sistema, games es para juegos, include/ contiene los archivos de cabecera C, kerberos/ contiene binarios y otros archivos relacionados con Kerberos y lib/ contiene archivos objeto y bibliotecas que no están diseñadas para ser utilizadas directamente por usuarios o scripts de shell. El directorio libexec/ contiene pequeños programas de ayuda llamados por otros programas, sbin/ es para los binarios de administración del sistema (aquéllos que no pertenecen al directorio /sbin/), share/ contiene archivos que no son de una arquitectura específica, src/ es para código fuente.

1.2.1.13. El directorio /usr/local/

El FHS dice:

La jerarquía /usr/local es para el uso del administrador del sistema al instalar software localmente. Necesita estar protegido contra sobreescrituras cuando se actualiza el software del sistema. Puede ser utilizado por programas y datos compartidos entre grupos de hosts, pero que no se encuentran en /usr.

El directorio /usr/local/ es similar en estructura al directorio /usr/. Tiene los siguientes subdirectorios, que son similares en propósito a los del directorio /usr/:

 /usr/local |- bin/ |- etc/ |- games/ |- include/ |- lib/ |- libexec/ |- sbin/ |- share/ |- src/

En Red Hat Enterprise Linux el propósito del directorio /usr/local/ es ligeramente diferente de lo especificado por FHS. El FHS establece que en /usr/local/ debería memorizarse el software que permanece seguro de las actualizaciones de software de sistemas. Ya que las actualizaciones de sistemas se pueden realizar de forma segura con el Red Hat Package Manager (RPM), no es necesario proteger archivos poniéndolos en /usr/local/. En vez de esto, el directorio /usr/local/ es utilizado para software es decir local a la máquina.

Por ejemplo, si usted ha montado /usr/ sólo lectura de NFS desde un host remoto, aún es posible instalar un paquete o programa bajo el directorio /usr/local/.

1.2.1.14. El directorio /var/

Ya que el FHS requiere que Linux sea capaz de montar /usr/ en sólo lectura, cualquier programa que escriba archivos log o que necesite los directorios spool/ o lock/ debería escribirlos en el directorio /var/. El FHS especifica que /var/ es para:

...archivos de datos variables. Esto incluye archivos y directorios spool, datos de administración, de registro y archivos temporales.

Abajo se muestran algunos de los directorios encontrados dentro del directorio /var/:

 /var |- account/ |- arpwatch/ |- cache/ |- crash/ |- db/ |- empty/ |- ftp/ |- gdm/ |- kerberos/ |- lib/ |- local/ |- lock/ |- log/ |- mail -> spool/mail/ |- mailman/ |- named/ |- nis/ |- opt/ |- preserve/ |- run/ +- spool/ |- at/ |- clientmqueue/ |- cron/ |- cups/ |- exim/ |- lpd/ |- mail/ |- mailman/ |- mqueue/ |- news/ |- postfix/ |- repackage/ |- rwho/ |- samba/ |- squid/ |- squirrelmail/ |- up2date/ |- uucp |- uucppublic/ |- vbox/ |- tmp/ |- tux/ |- www/ |- yp/

Los archivos de registro del sistema tales como messages y lastlog van en el directorio /var/log/. El directorio /var/lib/rpm/ contiene las bases de datos RPM. Los archivos lock van en el directorio /var/lock/, habitualmente en directorios para el programa utilizando el archivo. El directorio /var/spool/ tiene subdirectorios para programas en los que se almacenan archivos de datos.

1.3. Ubicación de Archivos Especiales bajo Red Hat Enterprise Linux

Red Hat Enterprise Linux extiende un poco la estructura de FHS para acomodar archivos especiales.

La mayor parte de los archivos que pertenecen al RPM se encuentran en el directorio /var/lib/rpm/. Para mayor información sobre RPM consulte el capítulo Capítulo 10, Administración de paquetes con RPM.

El directorio /var/cache/yum/ contiene los archivos que usa el Package Updater, incluyendo la información de cabecera del RPM para el sistema. Esta ubicación también se puede utilizar temporalmente para almacenar los RPMs descargados durante la actualización del sistema. Para mayor información sobre Red Hat Network consulte la documentación disponible en el sitio https://rhn.redhat.com/.

Otra de las ubicaciones específicas de Red Hat Enterprise Linux es el directorio /etc/sysconfig/. Este directorio almacena una variedad información de la configuración. Muchos scripts que se ejecutan al iniciar el sistema usan los archivos de este directorio. Consulte el Capítulo 28, El directorio sysconfig para más información sobre lo que se encuentra dentro directorio y el papel de estos archivos en el proceso de arranque.

Capítulo 2. Sistema de archivos ext3

El sistema de archivos por defecto es el sistema de archivos con 'journaling' ext3 .

2.1. Características de ext3

Básicamente, el sistema de archivos ext3 es una versión mejorada de ext2. Las mejoras introducidas proporcionan las siguientes ventajas:

Disponibilidad

Tras un corte eléctrico o una caída inesperada del sistema (también se denomina cierre no limpio del sistema), se debe comprobar la consistencia de cada sistema de archivos ext2 montado en la máquina con el programa e2fsck. El proceso de comprobación lleva mucho tiempo y puede prolongar el tiempo de arranque del sistema de un modo significativo, especialmente si hay grandes volúmenes que contienen un elevado número de archivos. Durante este proceso, no se puede acceder a los datos de los volúmenes.

Con la característica journaling del sistema de archivos ext3 ya no es necesario realizar este tipo de comprobación en el sistema de archivos después de un cierre no limpio del sistema. En el sistema ext3, únicamente se realiza una comprobación de consistencia en los casos puntuales en los que se producen determinados errores de hardware, como, por ejemplo, fallos en el disco duro. El tiempo empleado para recuperar un sistema de archivos ext3 tras un cierre no limpio del sistema no depende del tamaño del sistema de archivos ni del número de archivos, sino del tamaño del journal (diario), utilizado para mantener la consistencia en el sistema. Por defecto, la recuperación del tamaño del "journal" tarda alrededor de un segundo, según la velocidad del hardware.

Integridad de los datos

El sistema de archivos ext3 proporciona una integridad superior de los datos si se produce un cierre no limpio del sistema. El sistema de archivos ext3 le permite seleccionar el tipo y el nivel de protección de los datos. Por defecto, los volúmenes ext3 son configurados para mantener un alto nivel de consistencia de los datos en relación con el estado del sistema de archivos.

Velocidad

El sistema de archivos ext3, aparte de permitir escribir datos más de una vez, en la mayoría de los casos tiene un rendimiento superior al que proporciona ext2 porque los journals de ext3 optimizan el movimiento de los cabezales de los discos duros. Se pueden seleccionar tres modos de journaling para optimizar la velocidad, pero, como contrapartida, la integridad de los datos se verá afectada.

Fácil transición

La migración de ext2 a ext3 es muy sencilla y se pueden aprovechar las ventajas de un sólido sistema de archivos con journaling sin tener que volver a dar formato al sistema. Consulte la Sección 2.3, “Conversión a un sistema de archivos ext3” para obtener más información sobre como realizar esta tarea.

En las siguientes secciones se describirán los pasos para crear y afinar particiones ext3. Para particiones ext2, puede omitir las secciones sobre particionamiento y formateo, y, en su lugar, puede ir directamente a la Sección 2.3, “Conversión a un sistema de archivos ext3”.

2.2. Creación de un sistema de archivos ext3

A menudo es necesario, después de la instalación, crear un nuevo sistema de archivos ext3. Por ejemplo, si añade un nuevo disco duro al sistema, puede desear particionar la unidad y usar el sistema de archivos ext3.

Los pasos para crear un sistema de archivos ext3 son los siguientes:

  1. Dé formato a la partición con el sistema de archivos ext3 usando mkfs.

  2. Etiquete la partición usando e2label.

2.3. Conversión a un sistema de archivos ext3

tune2fs le permite convertir un sistema de archivos ext2 a ext3.

Nota

Siempre utilice la utilidad e2fsck para chequear su sistema de archivos antes y después de utilizar tune2fs. Una instalación predeterminada de Red Hat Enterprise Linux utiliza ext3 para todos los istemas de archivos.

Para convertir un sistema de archivos ext2 a ext3 conéctese como root y escriba el siguiente comando en una terminal:

/sbin/tune2fs -j <block_device>

en donde <block_device> contiene el sistema de archivos ext2 al que desea convertirse.

Un bloque válido de dispositivos puede ser uno de los dos tipos de entradas:

  • Un dispositivo mapeado — Un volúmen logico en un grupo de volumenes, por ejemplo, /dev/mapper/VolGroup00-LogVol02.

  • Un dispositivo estático — Un volúmen de almacenamiento tradicional, por ejemplo, /dev/hdbX, en donde hdb es un nombre de dispositivo de almacenamiento y X es el número de la partición.

Emita el comando df para visualizar los sistemas de archivos montados.

Para el resto de esta seccion los comandos de los ejemplos utilizan el siguiente valor para el dispositivo de bloques:

/dev/mapper/VolGroup00-LogVol02

Debe recrear la imagen initrd para que contenga el módulo del kernel ext3. Para crear esto ejecute el programa mkinitrd. Para obtener mayor información sobre el uso del comando mkinitrd consulte man mkinitrd. Además asegúrese de que su configuración GRUB carga el archivo initrd.

Aunque no consiga realizar este cambio, el sistema se arrancará, pero el sistema de archivos se montará como ext2 en vez de como ext3.

2.4. Volver al sistema de archivos ext2

Para revertir una partición de ext3 a ext2, primero deberá desmontar la partición conectándose como root y escribiendo:

umount /dev/mapper/VolGroup00-LogVol02

A continuación, cambie el tipo del sistema de archivos a ext2. Para ello, escriba el comando siguiente como root:

/sbin/tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02

Compruebe si la partición tiene errores. Para ello, escriba el comando siguiente como root:

/sbin/e2fsck -y /dev/mapper/VolGroup00-LogVol02

A continuación, vuelva a montar la partición como sistema de archivos ext2. Para ello, escriba:

mount -t ext2 /dev/mapper/VolGroup00-LogVol02/mount/point

En el comando anterior, sustituya /mount/point por el punto de montaje de la partición.

Luego, quite el archivo .journal del nivel root de la partición cambiándose al directorio donde está montado y escribiendo:

rm -f .journal

Ahora tendrá una partición ext2.

Si cambia definitivamente la partición a ext2 recuerde que debe actualizar el archivo /etc/fstab.

Capítulo 3. El sistema de archivos /proc

El kernel de Linux tiens dos funciones primarias: controlar el acceso a los dispositivos físicos del ordenador y establecer cuándo y cómo los procesos interactuarán con estos dispositivos. El directorio /proc/ — también llamado el sistema de archivos proc — contiene una jerarquía de archivos especiales que representan el estado actual del kernel — permitiendo a las aplicaciones y usuarios mirar detenidamente en la vista del kernel del sistema.

Dentro del directorio /proc/, se puede encontrar una gran cantidad de información con detalles sobre el hardware del sistema y cualquier proceso que se esté ejecutando actualmente. Además, algunos de los archivos dentro del árbol de directorios /proc/ pueden ser manipulados por los usuarios y aplicaciones para comunicar al kernel cambios en la configuración.

3.1. Sistema de archivos virtual

En Linux, todo se guarda en archivos. La mayoría de usuarios están familiarizados con los dos primeros tipos de archivos, de texto y binarios. Sin embargo, el directorio /proc/ contiene otro tipo de archivos llamado archivo virtual. Por esta razón, es que a menudo se hace referencia a /proc/ como un sistema de archivos virtual.

Estos archivos virtuales poseen cualidades únicas. En primer lugar, la mayoría de ellos tienen un tamaño de 0 bytes. Sin embargo, cuando se visualiza el archivo, éste puede contener una gran cantidad de información. Además, la mayoría de configuraciones del tiempo y las fechas reflejan el tiempo y fecha real, lo que es un indicativo de que están siendo constantemente modificados.

Los archivos virtuales tales como /proc/interrupts, /proc/meminfo, /proc/mounts, y /proc/partitions proporcionan una vista rápida actualizada del hardware del sistema. Otros, como /proc/filesystems y el directorio /proc/sys/, proveen información de configuración del sistema e interfaces.

Para propósitos organizacionales, los archivos que contienen información sobre un tópico similar se agrupan en directorios virtuales y sub-directorios. Por ejemplo, /proc/ide/ contiene información sobre los dispositivos IDE. De la misma forma, los directorios de procesos contienen información sobre cada proceso ejecutándose en el sistema.

3.1.1. Visualización de archivos virtuales

Mediante el uso de los comandos cat, more, o less en los archivos dentro del directorio /proc/, los usuarios pueden inmediatamente acceder una cantidad enorme de información acerca del sistema. Por ejemplo, para desplegar el tipo de CPU que tiene un equipo, escriba cat /proc/cpuinfo para recibir una salida similar a lo siguiente:

processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping : 1 cpu MHz : 400.919 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips : 799.53

Como puede ver en el sistema de archivos /proc/, alguna información tiene sentido, mientras que otras áreas aparecen en un código extraño. Por eso es que existen utilidades para extraer información de los archivos virtuales y mostrarla en una forma útil. Ejemplos de estas utilidades incluyen lspci, apm, free, y top.

Nota

Algunos archivos en el directorio /proc/ están configurados para que se puedan leer sólo por el usuario root.

3.1.2. Cambiar archivos virtuales

Como regla general, la mayoría de los archivos virtuales dentro del directorio /proc solamente se pueden leer. Sin embargo, algunos se pueden usar para ajustar la configuración del kernel. Esto ocurre con los archivos del subdirectorio /proc/sys/.

Para cambiar el valor de un archivo virtual, use el comando echo y el símbolo mayor que (>) para redirigir el nuevo valor al archivo. Por ejemplo, para cambiar el nombre del host rápidamente escriba:

echo www.example.com > /proc/sys/kernel/hostname 

Otros archivos actúan como conmutadores binarios o boleanos. Si escribe cat /proc/sys/net/ipv4/ip_forward verá el valor 0 o el valor 1. El valor 0 indica que el kernel no está realizando el reenvio de paquetes. Si usa el comando echo para cambiar el valor del archivo ip_forward a 1, el kernel activará inmediatamente el reenvio de paquetes.

Sugerencia

Otro comando que se usa para cambiar la configuración en el subdirectorio /proc/sys/ es /sbin/sysctl. Para obtener mayor información consulte la Sección 3.4, “Uso del comando sysctlSección 3.4, “Uso del comando sysctl

Para ver una lista de algunos de los archivos de configuración del kernel disponibles en el subdirectorio /proc/sys/ vaya a la Sección 3.3.9, “/proc/sys/.

3.2. Archivos de alto nivel en el sistema de archivos proc

La siguiente lista expone algunos de los archivos más comunes y útiles que se encuentran en el directorio /proc.

Nota

En la mayoría de los casos, el contenido de los archivos que aparecen en esta sección no será el mismo que el de aquellos instalados en su máquina. Esto se debe a que la mayor parte de la información es específica al hardware en el que esté ejecutando Red Hat Enterprise Linux para esta documentación.

3.2.1. /proc/apm

Este archivo proporciona información acerca del estado de la Administración de la energía avanzada (Advanced Power Management, APM), y es usado por el comando apm. Si un sistema sin batería está conectado a una fuente de poder AC, este archivo virtual se vería similar a:

1.16 1.2 0x07 0x01 0xff 0x80 -1% -1 ?

Al ejecutar el comando apm -v en tal sistema resulta en una salida similar a lo siguiente:

APM BIOS 1.2 (controlador del kernel 1.16ac) AC en-línea, no bateria del sistema

Para sistemas que no usan una batería como fuente de poder, apm sólo será capaz de poner la máquina en modo standby. El comando apm es mucho más útil en portátiles. Por ejemplo, la salida siguiente es del comando cat /proc/apm en una portátil mientras que está conectado a una toma de corriente:

1.16 1.2 0x03 0x01 0x03 0x09 100% -1 ?

Cuando la misma portátil está desconectada de su fuente de energía durante algunos minutos, los contenidos del archivo apm cambiarán a algo como:

1.16 1.2 0x03 0x00 0x00 0x01 99% 1792 min

El comando apm -v muestra información más útil tal como la siguiente:

APM BIOS 1.2 (controlador del kernel 1.16) AC desconectado, estado de la bateria alto: 99% (1 día, 5:52)

3.2.2. /proc/buddyinfo

Este archivo se utiliza principalmente para diagnosticar problemas de fragmentación de memoria. Utilizando el algoritmo buddy, cada columna representa el número de páginas de un cierto orden (de un cierto tamaño) que están disponibles en un momento dado. Por ejemplo, para la zona DMA (acceso directo a memoria), hay 90 de 2^(0*PAGE_SIZE) pedazos de memoria. De forma similar, hay 6 de 2^(1*PAGE_SIZE) pedazos, y 2 de 2^(2*PAGE_SIZE) pedazos de memoria disponibles.

La fila DMA hace referencia a los primeros 16 MB en un sistema, la fila HighMem referencia toda la memoria mayor que 4 GB en un sistema, y la fila Normal se refiere a toda la memoria en medio de las anteriores.

Lo siguiente es un ejemplo de la salida típica de /proc/buddyinfo:

Node 0, zone      DMA     90      6      2      1      1      ... 
Node 0, zone   Normal   1650    310      5      0      0      ... 
Node 0, zone  HighMem      2      0      0      1      1      ...

3.2.3. /proc/cmdline

Este archivo muestra los parámetros pasados al kernel en el momento en que éste inicia. Un ejemplo del archivo /proc/cmdline se vería como sigue?

ro root=/dev/VolGroup00/LogVol00 rhgb quiet 3

Esto nos dice que el kernel está montado como de sólo lectura (representado por (ro)), ubicado en el primer volumen lógico (LogVol00) del primer grupo de volúmenes (/dev/VolGroup00). LogVol00 es el equivalente a una partición de disco en un sistema no-LVM (Logical Volume Management), de la misma forma que /dev/VolGroup00 es un concepto similar a /dev/hda1,

Para obtener más información sobre LVM utilizado en Red Hat Enterprise Linux consulte http://www.tldp.org/HOWTO/LVM-HOWTO/index.html.

Luego, rhgb señala que se ha instalado el paquete rhgb y que se tiene soporte para el arranque gráfico, asumiendo que /etc/inittab muestra un nivel de ejecución por defecto configurado a id:5:initdefault:.

Finalmente, quiet indica que se van a suprimir todos los mensajes al momento del arranque.

3.2.4. /proc/cpuinfo

Este archivo virtual identifica el tipo de procesador usado por su sistema. A continuación se muestra un ejemplo de la salida típica de /proc/cpuinfo:

processor        : 0 
vendor_id        : GenuineIntel 
cpu family        : 15 
model                : 2 
model name        : Intel(R) Xeon(TM) CPU 2.40GHz 
stepping        : 7 cpu 
MHz                : 2392.371 
cache size        : 512 KB 
physical id        : 0 
siblings        : 2 
runqueue        : 0 
fdiv_bug        : no 
hlt_bug                : no 
f00f_bug        : no 
coma_bug        : no 
fpu                : yes 
fpu_exception        : yes 
cpuid level        : 2 
wp                : yes 
flags                : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca  cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
bogomips        : 4771.02
  • processor — Proporciona un número de identificación para cada procesador. En sistemas con un único procesador, tan sólo verá un 0.

  • cpu family — Le da de forma autorizada el tipo de procesador que tiene en el sistema. Para un sistema basado en Intel, ponga el número delante del "86" para calcular el valor. Esto le servirá de ayuda si se está preguntando sobre el tipo de arquitectura de un sistema antiguo tal como 586, 486 o 386. Ya que los paquetes RPM están compilados para cada una de estas arquitecturas particulares, este valor le ayuda a identificar qué paquetes instalar en el sistema.

  • model name — Le indica el nombre conocido del procesador, incluyendo el nombre de proyecto.

  • cpu MHz — Le muestra la velocidad precisa en megahertz de ese procesador en particular en milésimas.

  • cache size — Le indica la cantidad de memoria de nivel 2 de la caché disponible en el procesador.

  • siblings — Lista el número de CPUs hermanos dentro del mismo CPU físico para las arquitecturas que utilizan múltiples hilos (hyper-threading).

  • flags — Define un número de cualidades diferentes del procesador, como la presencia de una unidad de coma flotante (FPU) y la habilidad para procesar instrucciones MMX.

3.2.5. /proc/crypto

Este archivo lista todos los códigos de cifrado utilizados por el kernel de Linux, incluyendo detalles adicionales para cada uno. Un ejemplo del archivo /proc/crypto se vería como sigue:

name         : sha1 
module       : kernel 
type         : digest 
blocksize    : 64 
digestsize   : 20   
name         : md5 
module       : md5 
type         : digest 
blocksize    : 64 
digestsize   : 16

3.2.6. /proc/devices

Este archivo muestra los diversos dispositivos de carácteres y de bloque actualmente configurados (no incluye dispositivos cuyos módulos no están cargados). Una salida de datos de ejemplo de este archivo quedaría de la siguiente manera:

Character devices:  
  1 mem   
  4 /dev/vc/0   
  4 tty   
  4 ttyS   
  5 /dev/tty   
  5 /dev/console   
  5 /dev/ptmx   
  7 vcs  
  10 misc  
  13 input  
  29 fb  
  36 netlink 
  128 ptm 
  136 pts 
  180 usb   
  
Block devices:   
  1 ramdisk   
  3 ide0   
  9 md  
  22 ide1 
  253 device-mapper 
  254 mdp

La salida de datos desde /proc/devices incluye el número mayor y el nombre del dispositivo y se divide en dos secciones: Dispositivos de carácteres y Dispositivos de bloque.

Los Dispositivos de carácteres son similares a los Dispositivos de bloque, excepto por dos diferencias básicas:

  1. Los dispositivos de carácteres no requieren buffering. Los dispositivos de bloque disponen de una memoria intermedia o buffer que les permite ordenar las peticiones antes de tratar con ellas. Esto es muy importante para los dispositivos diseñados para guardar información — tales como discos duros — porque la habilidad de ordenar la información antes de escribirla en el dispositivo permite que ésta se almacene de forma más eficiente.

  2. Los dispositivos de carácteres envían datos sin un tamaño preconfigurado. Los dispositivos de bloque pueden enviar y recibir información en bloques de un tamaño particular, configurable por dispositivo.

Para más información sobre los dispositivos refiérase a la siguiente documentación instalada:

/usr/share/doc/kernel-doc-<version>/Documentation/devices.txt

3.2.7. /proc/dma

Este archivo contiene una lista de los canales registrados DMA ISA en uso. Un ejemplo de los archivos /proc/dma se vería similar a:

4: cascada

3.2.8. /proc/execdomains

Este archivo lista los dominios de ejecución soportados en la actualidad por el kernel de Linux junto con la gama de personalidades que soportan.

0-0   Linux           [kernel]

Piense en los dominios de ejecución como en una especie de "personalidad" de un sistema operativo. Debido a que se pueden usar otros formatos binarios, como Solaris, UnixWare y FreeBSD con Linux, los programadores pueden cambiar el modo en el que el sistema operativo trata las llamadas del sistema desde estos binarios mediante el cambio de la personalidad de la tarea. A excepción del dominio de ejecución PER_LINUX, se puede implementar diferentes personalidades como módulos cargables de forma dinámica.

3.2.9. /proc/fb

Este archivo contiene una lista de dispositivos frame buffer, con el número del dispositivo frame buffer y su controlador. La salida de datos más común de /proc/fb para sistemas que contienen dispositivos de frame buffer se ve similar a:

0 VESA VGA

3.2.10. /proc/filesystems

Este archivo muestra una lista de los tipos del sistema de archivos soportados actualmente por el kernel. A continuación tiene un ejemplo de salida de datos genérica de un archivo /proc/filesystems:

nodev   sysfs 
nodev   rootfs 
nodev   bdev 
nodev   proc 
nodev   sockfs 
nodev   binfmt_misc 
nodev   usbfs 
nodev   usbdevfs 
nodev   futexfs 
nodev   tmpfs 
nodev   pipefs 
nodev   eventpollfs 
nodev   devpts         
        ext2 
nodev   ramfs 
nodev   hugetlbfs         
        iso9660 
nodev   mqueue         
        ext3 
nodev   rpc_pipefs 
nodev   autofs

La primera columna significa si el sistema de archivos está montado en un dispositivo de bloque. Aquellos que comiencen con nodev no están montados en un dispositivo. La segunda columna lista el nombre de los sistemas de archivos soportados.

El comando mount circula por estos sistemas de archivos listados aquí cuando uno no está especificado como un argumento.

3.2.11. /proc/interrupts

Este archivo graba el número de interrupciones por IRQ en la arquitectura x86. Un archivo estándar /proc/interrupts es similar a lo siguiente:

CPU0          
  0:   80448940          XT-PIC  timer   
  1:     174412          XT-PIC  keyboard   
  2:          0          XT-PIC  cascade   
  8:          1          XT-PIC  rtc  
 10:     410964          XT-PIC  eth0  
 12:      60330          XT-PIC  PS/2 Mouse  
 14:    1314121          XT-PIC  ide0  
 15:    5195422          XT-PIC  ide1 
NMI:          0  
ERR:          0

Para una máquina con múltiples procesadores, el archivo aparecerá de forma diferente:

CPU0       CPU1          
  0: 1366814704          0          XT-PIC  timer   
  1:        128        340    IO-APIC-edge  keyboard   
  2:          0          0          XT-PIC  cascade   
  8:          0          1    IO-APIC-edge  rtc  
 12:       5323       5793    IO-APIC-edge  PS/2 Mouse  
 13:          1          0          XT-PIC  fpu  
 16:   11184294   15940594   IO-APIC-level  Intel EtherExpress Pro 10/100 Ethernet  
 20:    8450043   11120093   IO-APIC-level  megaraid  
 30:      10432      10722   IO-APIC-level  aic7xxx  
 31:         23         22   IO-APIC-level  aic7xxx 
NMI:          0 
ERR:          0

La primera columna se refiere al número de IRQ. Cada CPU del sistema tiene su propia columna y su propio número de interrupciones por IRQ. La columna siguiente le indica el tipo de interrupción y la última contiene el nombre del dispositivo que está localizado en ese IRQ.

Cada uno de los tipos de interrupciones vistos en este archivo, que son específicos para la arquitectura, significan algo diferente. Los siguientes valores son comunes para las máquinas x86:

  • XT-PIC — Interrupciones del ordenador AT antiguo que se han producido por un largo periodo de tiempo.

  • IO-APIC-edge — Señal de voltaje de las transacciones interrumpidas desde abajo hasta arriba, creando una edge, en la que la interrupción IO-APIC-level, tan sólo se dan a partir de procesadores 586 y superiores.

  • IO-APIC-level — Genera interrupciones cuando su señal de voltaje se alza hasta que la señal desciende nuevamente.

3.2.12. /proc/iomem

Este archivo muestra el mapa actual de la memoria del sistema para los diversos dispositivos:

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved 
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM 
000f0000-000fffff : System ROM
00100000-07ffffff : System RAM   
00100000-00291ba8 : Kernel code
00291ba9-002e09cb : Kernel data 
e0000000-e3ffffff : VIA Technologies, Inc. VT82C597 [Apollo VP3] e4000000-e7ffffff : PCI Bus #01   
e4000000-e4003fff : Matrox Graphics, Inc. MGA G200 AGP   
e5000000-e57fffff : Matrox Graphics, Inc. MGA G200 AGP 
e8000000-e8ffffff : PCI Bus #01   
e8000000-e8ffffff : Matrox Graphics, Inc. MGA G200 AGP 
ea000000-ea00007f : Digital Equipment Corporation DECchip 21140 [FasterNet]
ea000000-ea00007f : tulip ffff0000-ffffffff : reserved

La primera columna muestra los registros de memoria utilizados por cada uno de los diferentes tipos de memoria. La segunda columna indica el tipo de memoria de dichos registros y muestra qué registros de memoria son usados por el kernel dentro de la RAM del sistema o, si la tarjeta NIC tiene múltiples puertos Ethernet, los registros de memoria asignados para cada puerto.

3.2.13. /proc/ioports

La salida de /proc/ioports proporciona una lista de las regiones de puertos registrados actualmente utilizados para la comunicación de entrada y salida con un dispositivo. Este archivo puede ser muy largo. A continuación se muestra un listado parcial:

0000-001f : dma1 
0020-003f : pic1 
0040-005f : timer 
0060-006f : keyboard 
0070-007f : rtc 
0080-008f : dma page reg 
00a0-00bf : pic2 
00c0-00df : dma2 
00f0-00ff : fpu 
0170-0177 : ide1 
01f0-01f7 : ide0 
02f8-02ff : serial(auto) 
0376-0376 : ide1 
03c0-03df : vga+ 
03f6-03f6 : ide0 
03f8-03ff : serial(auto) 
0cf8-0cff : PCI conf1 
d000-dfff : PCI Bus #01 
e000-e00f : VIA Technologies, Inc. Bus Master IDE   
e000-e007 : ide0   
e008-e00f : ide1 
e800-e87f : Digital Equipment Corporation DECchip 21140 [FasterNet]   
e800-e87f : tulip

La primera columna le indica el rango de direcciones de los puertos de entrada y salida reservado para el dispositivo listado en la segunda columna.

3.2.14. /proc/kcore

Este archivo representa la memoria física del sistema y se almacena en el formato de archivos base. A diferencia de la mayoría de archivos /proc/, kcore muestra un tamaño. Este valor se da en bytes y es igual al tamaño de la memoria física (RAM) utilizada más 4KB.

Sus contenidos están diseñados para que los examine un depurador, como por ejemplo gdb, y no es legible para humanos.

Atención

Evite visualizar el archivo virtual /proc/kcore. El contenido de este archivo codifican el texto de salida a la terminal. Si accidentalmente lo visualiza pulse la combinación de teclas Ctrl-C para detener el proceso y luego escriba reset para llamar la línea de comandos del prompt en que se encontraba.

3.2.15. /proc/kmsg

Este archivo se utiliza para mantener mensajes generados por el kernel. Luego, estos mensajes son recogidos por otros programas, como por ejemplo /sbin/klogd o /bin/dmesg.

3.2.16. /proc/loadavg

Este archivo ofrece una vista de la carga promedio del procesador con respecto al sobretiempo de CPU y de E/S, así como también datos adicionales utilizados por uptime y otros comandos. Una muestra del archivo /proc/loadavg sería similar a lo siguiente:

0.20 0.18 0.12 1/80 11206

The first three columns measure CPU and IO utilization of the last one, five, and 15 minute periods. The fourth column shows the number of currently running processes and the total number of processes. The last column displays the last process ID used.

In addition, load average also refers to the number of processes ready to run (i.e. in the run queue, waiting for a CPU share.

3.2.17. /proc/locks

Este archivo muestra los archivos bloqueados en la actualidad por el kernel. El contenido de este archivo contiene datos internos de depuración y puede variar enormemente, dependiendo del uso del sistema. Este es un ejemplo de archivo /proc/locks de un sistema ligeramente cargado:

1: POSIX  ADVISORY  WRITE 3568 fd:00:2531452 0 EOF 
2: FLOCK  ADVISORY  WRITE 3517 fd:00:2531448 0 EOF 
3: POSIX  ADVISORY  WRITE 3452 fd:00:2531442 0 EOF 
4: POSIX  ADVISORY  WRITE 3443 fd:00:2531440 0 EOF 
5: POSIX  ADVISORY  WRITE 3326 fd:00:2531430 0 EOF 
6: POSIX  ADVISORY  WRITE 3175 fd:00:2531425 0 EOF 
7: POSIX  ADVISORY  WRITE 3056 fd:00:2548663 0 EOF

A cada bloqueo se le asigna un único número al inicio de cada línea. La segunda columna se refiere a la clase de bloqueo utilizado; FLOCK, haciendo referencia al estilo antiguo de bloqueos de archivos desde una llamada de sistema flock y POSIX que representa los bloqueos nuevos POSIX desde la llamada de sistema lockf.

La tercera columna puede tener dos valores. ADVISORY o MANDATORY. ADVISORY significa que el bloqueo no impide que otras personas puedan acceder a los datos; tan sólo previene de que otros intenten establecer un bloqueo. MANDATORY significa que mientras que dura el bloqueo no se permite ningún otro acceso a los datos. La cuarta columna muestra si el bloqueo permite al responsable del mismo acceso de READ o WRITE (lectura y escritura) al archivo. La quinta muestra el ID del proceso que tiene el bloqueo. La sexta columna muestra el ID del archivo bloqueado, en el formato de MAJOR-DEVICE:MINOR-DEVICE:INODE-NUMBER. La séptima y octava columnas muestra el inicio y el final de la región bloqueada del archivo.

3.2.18. /proc/mdstat

Este archivo contiene la información actual sobre las configuración de discos múltiples de RAID. Si su sistema no contiene dicha configuración, el archivo /proc/mdstat será parecido a:

Personalidades: read_ahead no configurado para dispositivos no utilizados: <none>

Este archivo se mantiene en el mismo estado que el mostrado arriba a menos que un software RAID o dispositivo md esté presente. En ese caso, visualice /proc/mdstat para ver el estado actual de los dispositivos RAID mdX.

El archivo /proc/mdstat a continuación, muestra un sistema con su md0 configurado como un dispositivo RAID 1, mientras está resincronizando los discos:

Personalities : [linear] [raid1] read_ahead 1024 sectors 
md0: active raid1 sda2[1] sdb2[0] 9940 blocks [2/2] [UU] resync=1% finish=12.3min algorithm 2 [3/3] [UUU] 
unused devices: <none>

3.2.19. /proc/meminfo

Este es uno de los archivos más utilizados en el directorio /proc/, ya que proporciona mucha información importante sobre el uso actual de RAM en el sistema.

La muestra siguiente del archivo virtual /proc/meminfo es de un sistema con 256 MB de RAM y 512 MB de espacio de intercambio (swap):

MemTotal:       255908 kB 
MemFree:         69936 kB 
Buffers:         15812 kB 
Cached:         115124 kB 
SwapCached:          0 kB 
Active:          92700 kB 
Inactive:        63792 kB 
HighTotal:           0 kB 
HighFree:            0 kB 
LowTotal:       255908 kB 
LowFree:         69936 kB 
SwapTotal:      524280 kB 
SwapFree:       524280 kB 
Dirty:               4 kB 
Writeback:           0 kB 
Mapped:          42236 kB 
Slab:            25912 kB 
Committed_AS:   118680 kB 
PageTables:       1236 kB 
VmallocTotal:  3874808 kB 
VmallocUsed:      1416 kB 
VmallocChunk:  3872908 kB 
HugePages_Total:     0 
HugePages_Free:      0 
Hugepagesize:     4096 kB

La mayoría de la información que está aquí es usada por los comandos free, top y ps. De hecho, la salida de datos del comando free es parecida en apariencia al contenido y estructura de /proc/meminfo. Pero si lee directamente /proc/meminfo, verá más detalles:

  • MemTotal — Cantidad total de RAM física en kilo bytes.

  • MemFree — Cantidad de RAM física, en kilobytes, sin utilizar por el sistema.

  • Buffers — Cantidad de RAM física, en kilobytes, usada para los archivos de memoria intermedia.

  • Cached — Cantidad de RAM física en kilobytes usada como memoria caché.

  • SwapCached — Cantidad de swap en kilobytes usada como memoria caché.

  • Active — Cantidad total de memoria intermedia o caché de página, en kilobytes, que está en uso activo. Esta es memoria que recientemente ha sido utilizada y que usualmente no se reclama para otros propósitos.

  • Inactive — La cantidad total de memoria intermedia o caché de página, en kilobytes, que está libre y disponible. Esta es memoria que no se ha utilizado recientemente y que se puede reclamar para otros propósitos.

  • HighTotal y HighFree — Cantidad total de memoria libre, que no está mapeada en el espacio del kernel. El valor HighTotal puede variar dependiendo del tipo de kernel utilizado.

  • LowTotal y LowFree — Cantidad total de memoria libre implantada directamente en el espacio del kernel. El valor LowTotal puede cambiar dependiendo del tipo de kernel utilizado.

  • SwapTotal — Cantidad total de swap disponible, en kilobytes.

  • SwapFree — Cantidad total de swap libre, en kilobytes.

  • Dirty — La cantidad total de memoria, en kilobytes, esperando a ser escrita al disco.

  • Writeback — Cantidad total de memoria, en kilobytes, que está siendo escrita activamente al disco.

  • Mapped — La cantidad total de memoria, en kilobytes, que se ha utilizado para asignar dispositivos, archivos o bibliotecas, usando el comando mmap.

  • Slab — Cantidad total de memoria, en kilobytes, usada por el kernel para hacer caché de estructuras de datos para su propio uso.

  • Committed_AS — Cantidad total de memoria, en kilobytes, estimadas para completar la carga de trabajo. Este valor representa un escenario del peor caso, y también incluye a la memoria de intercambio o swap.

  • PageTables — Cantidad total de memoria, en kilobytes, dedicada al nivel más bajo de la tabla de páginas.

  • VMallocTotal — Cantidad total memoria, en kilobytes, del espacio total de direcciones virtuales asignadas.

  • VMallocUsed — La cantidad total de memoria en kilobytes, de espacio de direcciones virtuales utilizada.

  • VMallocChunk — El bloque continuo de memoria más grande, en kilobytes, de espacio de direcciones virtuales disponibles.

  • HugePages_Total — El número total de paginas gigantes para el sistema. El número se deriva dividiendo Hugepagesize por los megabytes puestos a un lado para las páginas gigantes especificadas en /proc/sys/vm/hugetlb_pool. Esta estadística sólo aparece en las arquitecturas x86, Itanium y AMD64.

  • HugePages_Free — El número total de páginas gigantes disponibles para el sistema. Esta estadística sólo aparece en las arquitecturas x86, Itanium y AMD64.

  • Hugepagesize — El tamaño para cada unidad de hugepages en kilobytes. Por defecto, el valor es 4096 KB en los kernels de un sólo procesador para las arquitecturas de 32 bits. Para los kernels SMP, hugemem y AMD64, el valor por defecto es 2048 KB. Para las arquitecturas Itanium, el valor por defecto es 262144 KB. Esta estadística solamente aparece en las arquitecturas x86, Itanium y AMD64.

3.2.20. /proc/misc

Este archivo lista varios controladores registrados en el principal dispositivo de misceláneos, que es el número 10:

63 device-mapper 175 agpgart 135 rtc 134 apm_bios

La primera columna es el número menor (minor) de cada dispositivo y la segunda le muestra el controlador en uso.

3.2.21. /proc/modules

Este archivo muestra una lista de todos los módulos cargados en el sistema. Su contenido variará dependiendo de la configuración y uso de su sistema, pero debería organizarse de forma similar al siguiente ejemplo de salida del archivo /proc/modules:

Nota

Se ha vuelto a formatear este ejemplo en un formato legible. La mayoría de esta información también se puede ver a través del comando /sbin/lsmod.

nfs      170109  0 -          Live 0x129b0000 
lockd    51593   1 nfs,       Live 0x128b0000 
nls_utf8 1729    0 -          Live 0x12830000 
vfat     12097   0 -          Live 0x12823000 
fat      38881   1 vfat,      Live 0x1287b000 
autofs4  20293   2 -          Live 0x1284f000 
sunrpc   140453  3 nfs,lockd, Live 0x12954000 
3c59x    33257   0 -          Live 0x12871000 
uhci_hcd 28377   0 -          Live 0x12869000 
md5      3777    1 -          Live 0x1282c000 
ipv6     211845 16 -          Live 0x128de000 
ext3     92585   2 -          Live 0x12886000 
jbd      65625   1 ext3,      Live 0x12857000 
dm_mod   46677   3 -          Live 0x12833000

La primera columna contiene el nombre del módulo.

La segunda columna se refiere al tamaño de la memoria del módulo, en bytes.

La tercera columna lista cuántas instancias del módulo están cargadas actualmente. Un valor de cero representa un módulo sin cargar.

La cuarta columna indica si el módulo depende de que otro módulo esté presente para poder funcionar, y lista esos otros módulos.

La quinta columna lista en qué estado de carga se encuentra el módulo: Live, Loading o Unloading son los únicos valores posibles.

La sexta columna lista el desplazamiento de memoria del kernel actual para el módulo cargado. Esta información puede ser útil para propósitos de depuración o para herramientas de perfiles, tales como oprofile.

3.2.22. /proc/mounts

Este archivo proporciona una lista de todos los montajes en uso por el sistema:

rootfs / rootfs rw 0 0 
/proc /proc proc rw,nodiratime 0 0 none 
/dev ramfs rw 0 0 
/dev/mapper/VolGroup00-LogVol00 / ext3 rw 0 0 
none /dev ramfs rw 0 0 
/proc /proc proc rw,nodiratime 0 0 
/sys /sys sysfs rw 0 0 
none /dev/pts devpts rw 0 0 
usbdevfs /proc/bus/usb usbdevfs rw 0 0 
/dev/hda1 /boot ext3 rw 0 0 
none /dev/shm tmpfs rw 0 0 
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0

La salida de datos que encontramos aquí se parece a /etc/mtab, excepto que /proc/mount está más actualizada.

La primera columna especifica el dispositivo que está montado, la segunda revela el punto de montaje, la tercera indica el tipo de sistema de archivos y la cuarta si está montado en modo sólo lectura (ro) o sólo escritura (rw). La quinta y sexta columna son valores no válidos diseñados para hacer coincidir el formato usado en /etc/mtab.

3.2.23. /proc/mtrr

Este archivo se refiere a la actual Memory Type Range Registers (MTRRs), en uso dentro del sistema. Si la arquitectura de su sistema soporta MTRRs, entonces el archivo /proc/mtrr será algo parecido a:

reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1 
reg01: base=0xe8000000 (3712MB), size=  32MB: write-combining, count=1

Los MTRRs se usan con la familia de procesadores Intel P6 (Pentium II y superior), y controlan el acceso del procesador a los rangos de memoria. Cuando utilice una tarjeta de vídeo en un PCI o un bus AGP, un archivo /proc/mtrr adecuadamente configurado puede incrementar el rendimiento en un 150%.

La mayoría de las veces, por defecto este valor está configurado adecuadamente. Se puede encontrar más información sobre la configuración manual de este archivo en la siguiente ubicación:

/usr/share/doc/kernel-doc-<version>/Documentation/mtrr.txt

3.2.24. /proc/partitions

El archivo contiene información sobre la asignación de bloques de particiones. Un ejemplo de este archivo en un sistema básico se vería como:

major minor  #blocks  name      
  3     0   19531250 hda    
  3     1     104391 hda1    
  3     2   19422585 hda2  
253     0   22708224 dm-0  
253     1     524288 dm-1

La mayoría de la información no es relevante para los usuarios, a excepción de las siguientes líneas:

  • major — Número principal (major number) del dispositivo con esta partición. El número principal en nuestro ejemplo en /proc/partitions (3), corresponde con el dispositivo ide0 en /proc/devices.

  • minor — Número menor del dispositivo con esta partición. Separa las particiones en diferentes dispositivos físicos y los relaciona con el número al final del nombre de la partición.

  • #blocks — Lista el número de bloques de disco físicos contenidos en una partición particular.

  • name — Nombre de la partición.

3.2.25. /proc/pci

El archivo contiene una lista completa de cada dispositivo PCI en su sistema. Dependiendo del número de dispositivos PCI que posea, /proc/pci puede ser bastante largo. Un ejemplo de este archivo en un sistema básico se vería como:

Bus  0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe4000000 [0xe7ffffff].   
Bus  0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3).   Master Capable. Latency=64. Min Gnt=128.   
Bus  0, device 4, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).   
Bus  0, device 4, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f].   
Bus  0, device 4, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 5. Master Capable. Latency=32. I/O at 0xd400 [0xd41f].   
Bus  0, device 4, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). IRQ 9.  
Bus  0, device 9, function 0: Ethernet controller: Lite-On Communications Inc LNE100TX (rev 33). IRQ 5. Master Capable. Latency=32. I/O at 0xd000 [0xd0ff].   
Bus  0, device 12, function  0: VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 1). IRQ 11. Master Capable. Latency=32. Min Gnt=4.Max Lat=255.

Esta salida de datos muestra una lista de todos los dispositivos PCI, en orden de bus, dispositivo y función. Además de proporcionar el nombre y versión del dispositivo, esta lista le proporciona información de IRQ detallada y así un administrador puede rápidamente dar un vistazo para verificar conflictos.

Sugerencia

Para obtener una versión más fácil de leer, escriba:

/sbin/lspci -vb

3.2.26. /proc/slabinfo

Este archivo le da información completa sobre el uso de memoria en el nivel slab. Los kernels Linux superiores a la versión 2.2 usan slab pools para manejar memoria por encima del nivel de página. Los objetos utilizados habitualmente, tienen sus propios slab pools.

En vez de analizar manualmente el largo archivo /proc/slabinfo, el programa /usr/bin/slabtop muestra la información del caché slab del kernel en tiempo real. Este programa permite configuraciones personalizadas, incluyendo el ordenamiento por columnas y la actualización de pantallas.

Una captura de pantalla de /usr/bin/slabtop usualmente se parece a algo como:

Active / Total Objects (% used)    : 133629 / 147300 (90.7%)  
Active / Total Slabs (% used)      : 11492 / 11493 (100.0%)  
Active / Total Caches (% used)     : 77 / 121 (63.6%)  
Active / Total Size (% used)       : 41739.83K / 44081.89K (94.7%)  
Minimum / Average / Maximum Object : 0.01K / 0.30K / 128.00K
OBJS   ACTIVE USE      OBJ   SIZE     SLABS OBJ/SLAB CACHE SIZE NAME  
44814  43159  96%    0.62K   7469      6     29876K ext3_inode_cache
36900  34614  93%    0.05K    492     75      1968K buffer_head  
35213  33124  94%    0.16K   1531     23      6124K dentry_cache   
7364   6463  87%    0.27K    526      14      2104K radix_tree_node   
2585   1781  68%    0.08K     55      47       220K vm_area_struct   
2263   2116  93%    0.12K     73      31       292K size-128   
1904   1125  59%    0.03K     16      119        64K size-32   
1666    768  46%    0.03K     14      119        56K anon_vma   
1512   1482  98%    0.44K    168       9       672K inode_cache   
1464   1040  71%    0.06K     24      61        96K size-64   
1320    820  62%    0.19K     66      20       264K filp    
678    587  86%    0.02K      3      226        12K dm_io   
678    587  86%    0.02K      3      226        12K dm_tio    
576    574  99%    0.47K     72        8       288K proc_inode_cache    
528    514  97%    0.50K     66        8       264K size-512    
492    372  75%    0.09K     12       41        48K bio    
465    314  67%    0.25K     31       15       124K size-256    
452    331  73%    0.02K      2      226         8K biovec-1    
420    420 100%    0.19K     21       20        84K skbuff_head_cache    
305    256  83%    0.06K      5       61        20K biovec-4    
290      4   1%    0.01K      1      290         4K revoke_table    
264    264 100%    4.00K    264        1      1056K size-4096    
260    256  98%    0.19K     13       20        52K biovec-16    
260    256  98%    0.75K     52        5       208K biovec-64

Algunas de las estadísticas usadas más comúnmente en /proc/slabinfo que se incluyen en /usr/bin/slabtop, abarcan:

  • OBJS — El número total de objetos (bloques de memoria), incluyendo aquellos en uso (asignados), y algunos adicionales que no estén en uso.

  • ACTIVE — El número total de objetos (bloques de memoria) utilizados (asignados).

  • USE — Porcentaje de los objetos totales que están activos. ((ACTIVE/OBJS)(100))

  • OBJ SIZE — El tamalo de los objectos.

  • SLABS — El número total de slabs.

  • OBJ/SLAB — El número de objectos que caben en un slab.

  • CACHE SIZE — El tamaño de caché del slab.

  • NAME — Nombre del slab.

Para más información sobre el programa /usr/bin/slabtop, refiérase a la página man de slabtop.

3.2.27. /proc/stat

Este archivo mantiene un registro de las diferentes estadísticas sobre el sistema desde que fue reiniciado por última vez. El contenido de /proc/stat que puede ser muy largo, usualmente empieza de la siguiente manera:

cpu  259246 7001 60190 34250993 137517 772 0 
cpu0 259246 7001 60190 34250993 137517 772 0 
intr 354133732 347209999 2272 0 4 4 0 0 3 1 1249247 0 0 80143 0 422626 5169433 
ctxt 12547729 
btime 1093631447 
processes 130523 
procs_running 1 
procs_blocked 0 
preempt 5651840  
cpu  209841 1554 21720 118519346 72939 154 27168 
cpu0 42536 798 4841 14790880 14778 124 3117 
cpu1 24184 569 3875 14794524 30209 29 3130 
cpu2 28616 11 2182 14818198 4020 1 3493 
cpu3 35350 6 2942 14811519 3045 0 3659 
cpu4 18209 135 2263 14820076 12465 0 3373 
cpu5 20795 35 1866 14825701 4508 0 3615 
cpu6 21607 0 2201 14827053 2325 0 3334 
cpu7 18544 0 1550 14831395 1589 0 3447 
intr 15239682 14857833 6 0 6 6 0 5 0 1 0 0 0 29 0 2 0 0 0 0 0 0 0 94982 0 286812 
ctxt 4209609 
btime 1078711415 
processes 21905 
procs_running 1 
procs_blocked 0

Algunas de las estadísticas más populares incluyen:

  • cpu — Mide el número de instantes (1/100 de segundos para sistemas x86) en los que el sistema ha estado en modo usuario, modo usuario con prioridad baja (nice), modo de sistema, tareas ociosas, esperas de E/S, IRQ (hardirq) y softirq respectivamente. El IRQ (hardirq) es la respuesta directa a un evento de hardware. El IRQ hace el esfuerzo mínimo para encolar el trabajo "pesado" para que lo ejecute el softirq. El softirq se ejecuta a una prioridad más baja que el IRQ y por lo tanto puede ser interrumpido con más frecuencia. El total para todos los CPUs se dá arriba, mientras que cada CPU individual se lista con sus propias estadísticas. El ejemplo siguiente es de una configuración 4-way Intel Pentium Xeon con el multihilos activado, por lo tanto muestra cuatro procesadores físicos y cuatro procesadores virtuales para un total de ocho procesadores.

  • page — Número de páginas que el sistema ha cargado o suprimido del disco.

  • swap — Número de páginas swap que el sistema ha introducido o sacado.

  • intr — Número de interrupciones que ha experimentado el sistema.

  • btime — Tiempo de arranque, medido por el número de segundos desde el 1 de enero de 1970, conocido con el nombre de epoch.

3.2.28. /proc/swaps

Este archivo mide el espacio swap y su uso. Para un sistema con tan sólo una partición de espacio swap, la salida de datos de /proc/swap será similar a lo siguiente:

Filename                          Type        Size     Used    Priority 
/dev/mapper/VolGroup00-LogVol01   partition   524280   0       -1

Mientras que alguna de esta información se puede encontrar en otros archivos en el directorio /proc/, /proc/swap proporciona una instantánea de cada nombre de archivo swap, el tipo de espacio swap, el tamaño total y la cantidad de espacio en uso (en kilobytes). La columna de prioridad es útil cuando se usan múltiples archivos de espacio de intercambio. Cuanto más baja es la prioridad, más probable es que se use el archivo de intercambio.

3.2.29. /proc/sysrq-trigger

Usando el comando echo para escribir a este archivo, un usuario root remoto puede ejecutar la mayoría de los comandos de llave de petición del sistema (System Request Key) remotamente como que si estuviese en el terminal local. Para hacer echo con los valores a este archivo, /proc/sys/kernel/sysrq debe estar configurado con un valor diferente de 0. Para obtener más información sobre System Request Key refiérase a la Sección 3.3.9.3, “/proc/sys/kernel/.

Aún cuando es posible escribir a este archivo, no se puede leer, ni siquiera por el usuario root.

3.2.30. /proc/uptime

El archivo contiene información sobre el tiempo que lleva encendido el sistema desde el último reinicio. La salida de datos de /proc/uptime es mínima:

350735.47 234388.90

El primer número le indica el número total de segundos que el sistema ha estado en funcionamiento. El segundo indica cuánto de ese tiempo, también en segundos, la máquina ha estado inactiva.

3.2.31. /proc/version

Este archivo muestra las versión del kernel de Linux y gcc en uso, así como la versión de Red Hat Enterprise Linux instalada en el sistema:

Linux version 2.6.8-1.523 (user@foo.redhat.com) (gcc version 3.4.1 20040714 \  (Red Hat Enterprise Linux 3.4.1-7)) #1 Mon Aug 16 13:27:03 EDT 2004

Esta información se usa para diversos propósitos, incluyendo la aportación de datos de la versión en el intérprete de comandos de registro estándar.

3.3. Directorios en /proc/

Grupos comunes de información referente al kernel agrupado en directorios y subdirectorios en /proc/.

3.3.1. Directorios de proceso

Cada directorio /proc/ contiene unos cuantos directorios nombrados con un número. Un listado de los mismos se vería de la siguiente manera:

dr-xr-xr-x    3 root     root            0 Feb 13 01:28 1 
dr-xr-xr-x    3 root     root            0 Feb 13 01:28 1010
dr-xr-xr-x    3 xfs      xfs             0 Feb 13 01:28 1087
dr-xr-xr-x    3 daemon   daemon          0 Feb 13 01:28 1123
dr-xr-xr-x    3 root     root            0 Feb 13 01:28 11307
dr-xr-xr-x    3 apache   apache          0 Feb 13 01:28 13660
dr-xr-xr-x    3 rpc      rpc             0 Feb 13 01:28 637
dr-xr-xr-x    3 rpcuser  rpcuser         0 Feb 13 01:28 666

A estos directorios se les llama directorios de proceso, ya que pueden hacer referencia a un ID de proceso y contener información específica para ese proceso. El propietario y grupo de cada directorio de proceso está configurado para que el usuario ejecute el proceso. Cuando se finaliza el proceso, el directorio del proceso /proc/ desaparece.

Cada uno de los directorios de procesos contiene los siguientes archivos:

  • cmdline — Contiene el comando que se ejecutó cuando se arrancó el proceso.

  • cwd — Enlace simbólico al directorio actual en funcionamiento para el proceso.

  • environ — Le da una lista de variables de entorno para el proceso. La variable de entorno viene dada toda en mayúsculas y el valor en minúsculas.

  • exe — Enlace simbólico al ejecutable de este proceso.

  • fd — Directorio que contiene todos los descriptores de archivos para un proceso en particular. Vienen dados en enlaces numerados:

    total 0 
    lrwx------    1 root     root           64 May  8 11:31 0 -> /dev/null
    lrwx------    1 root     root           64 May  8 11:31 1 -> /dev/null
    lrwx------    1 root     root           64 May  8 11:31 2 -> /dev/null
    lrwx------    1 root     root           64 May  8 11:31 3 -> /dev/ptmx
    lrwx------    1 root     root           64 May  8 11:31 4 -> socket:[7774817] 
    lrwx------    1 root     root           64 May  8 11:31 5 -> /dev/ptmx
    lrwx------    1 root     root           64 May  8 11:31 6 -> socket:[7774829] 
    lrwx------    1 root     root           64 May  8 11:31 7 -> /dev/ptmx
    
  • maps — Contiene mapas de memoria para los diversos ejecutables y archivos de bibliotecas asociados con este proceso. Este archivo puede ser bastante largo, dependiendo de la complejidad del proceso. Una muestra de la salida de datos desde el proceso sshd empezaría de la siguiente manera:

    08048000-08086000 r-xp 00000000 03:03 391479     /usr/sbin/sshd
    08086000-08088000 rw-p 0003e000 03:03 391479        /usr/sbin/sshd
    08088000-08095000 rwxp 00000000 00:00 0
    40000000-40013000 r-xp 0000000 03:03 293205        /lib/ld-2.2.5.so
    40013000-40014000 rw-p 00013000 03:03 293205        /lib/ld-2.2.5.so 
    40031000-40038000 r-xp 00000000 03:03 293282        /lib/libpam.so.0.75
    40038000-40039000 rw-p 00006000 03:03 293282        /lib/libpam.so.0.75
    40039000-4003a000 rw-p 00000000 00:00 0
    4003a000-4003c000 r-xp 00000000 03:03 293218        /lib/libdl-2.2.5.so 
    4003c000-4003d000 rw-p 00001000 03:03 293218        /lib/libdl-2.2.5.so
    
  • mem — Memoria del proceso.

  • root — Enlace al directorio root del proceso.

  • stat — Estado del proceso.

  • statm — Estado de la memoria en uso por el proceso. Ejemplo de archivos statm:

    263 210 210 5 0 205 0
    

    Las siete columnas se relacionan a diferentes estadísticas de memoria para el proceso. Dependiendo de como se visualizan, de derecha a izquierda, remiten diferentes aspectos de la memoria utilizada:

    1. Tamaño total del programa, en kilobytes.

    2. Tamaño de las porciones de memoria, en kilobytes.

    3. Número de páginas compartidas.

    4. Número de páginas que son código.

    5. Número de páginas de datos/pila.

    6. Número de páginas de bibliotecas.

    7. Número de páginas sucias.

  • status — Proporciona el estado del proceso en una forma mucho más legible que stat o statm. Un ejemplo de salida de datos de sshd se vería similar a:

    Name:        sshd 
    State:        S (sleeping) 
    Tgid:        797 
    Pid:        797 
    PPid:        1 
    TracerPid:        0 
    Uid:        0        0        0        0 
    Gid:        0        0        0        0 
    FDSize:        32 
    Groups:         
    VmSize:            3072 kB 
    VmLck:               0 kB 
    VmRSS:             840 kB 
    VmData:             104 kB 
    VmStk:              12 kB 
    VmExe:             300 kB 
    VmLib:            2528 kB 
    SigPnd:        0000000000000000 
    SigBlk:        0000000000000000 
    SigIgn:        8000000000001000 
    SigCgt:        0000000000014005 
    CapInh:        0000000000000000 
    CapPrm:        00000000fffffeff 
    CapEff:        00000000fffffeff
    

    La información en esta salida incluye el nombre y ID del proceso, el estado (tal como S (sleeping) o R (running)), ID del usuario/grupo ejecutando el proceso y detalles sobre el uso de la memoria.

3.3.1.1. /proc/self

El directorio /proc/self es un enlace al proceso en ejecución. Esto le permite verse a si mismo sin tener que conocer su ID de proceso.

Dentro de un entorno de la shell, una lista del directorio /proc/self produce el mismo contenido que una lista del directorio del proceso para ese proceso.

3.3.2. /proc/bus/

Este directorio contiene información específica sobre los diversos buses disponibles en el sistema. Por ejemplo, en un sistema estándar que contenga buses PCI y USB, los datos actuales en cada uno de estos buses están disponibles en un subdirectorio bajo /proc/bus/ con el mismo nombre, tal como /proc/bus/pci/ .

Los subdirectorios y archivos disponibles dentro de /proc/bus/ varían dependiendo de los dispositivos conectados al sistema. Sin embargo, cada tipo de bus tiene al menos un directorio. Dentro de estos directorios de buses normalmente están, al menos, un subdirectorio con un nombre numérico, tal como 001, el cual contiene los archivos binarios.

Por ejemplo, el subdirectorio /proc/bus/usb/ contiene archivos que hacen un seguimiento de los diferentes dispositivos en cualquier bus USB, así como los controladores requeridos para su uso. El siguiente es un listado de ejemplo de un directorio /proc/bus/usb/

total 0 dr-xr-xr-x    1 root     root            0 May  3 16:25 001 
-r--r--r--    1 root     root            0 May  3 16:25 devices 
-r--r--r--    1 root     root            0 May  3 16:25 drivers

El directorio /proc/bus/usb/001/ contiene todos los dispositivos del primer bus USB y el archivo devices identifica el concentrador raíz USB en la tarjeta madre.

Lo siguiente es un ejemplo de un archivo /proc/bus/usb/devices:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2 
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0 
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1 
P:  Vendor=0000 ProdID=0000 Rev= 0.00 
S:  Product=USB UHCI Root Hub 
S:  SerialNumber=d400 
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA 
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub 
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms

3.3.3. /proc/driver/

Este directorio contiene información para drivers específicos que el kernel está utilizando.

rtc es un archivo habitual aquí, que proporciona la salida desde el controlador para el reloj del sistema (Real Time Clock (RTC)): el dispositivo que mantiene la hora mientras que el sistema está apagado. Un ejemplo de salida de datos desde /proc/driver/rtc sería similar a:

rtc_time        : 16:21:00 
rtc_date        : 2004-08-31 
rtc_epoch       : 1900 
alarm           : 21:16:27 
DST_enable      : no 
BCD             : yes 
24hr            : yes 
square_wave     : no 
alarm_IRQ       : no 
update_IRQ      : no 
periodic_IRQ    : no 
periodic_freq   : 1024 
batt_status     : okay

Para más información sobre RTC, refiérase a la siguiente documentación instalada:

/usr/share/doc/kernel-doc-<version>/Documentation/rtc.txt.

3.3.4. /proc/fs

Este directorio muestra qué sistemas de archivos están siendo exportados. Si está usando un servidor NFS escriba cat /proc/fs/nfsd/exports para visualizar los sistemas de archivos que se comparten y los permisos acordados a esos sistemas de archivos. Para mayor información sobre archivos compartidos con NFS consulte el Capítulo 19, Sistema de archivos de red (NFS).

3.3.5. /proc/ide/

Este directorio contiene información sobre los dispositivos IDE del sistema. Cada canal IDE está representado como un directorio separado, tal como /proc/ide/ide0 y /proc/ide/ide1. Además, también está disponible un archivo drivers proporcionando el número de versión de los varios controladores usados en los canales IDE:

ide-floppy version 0.99.
newide ide-cdrom version 4.61 
ide-disk version 1.18

Muchos chipsets también proporcionan un archivo en este directorio con datos adicionales referentes a las unidades conectadas a través de los canales. Por ejemplo, un chipset genérico Intel PIIX4 Ultra 33 produce el archivo /proc/ide/piix que le informará de si DMA o UDMA está o no habilitado para los dispositivos en los canales IDE:

Intel PIIX4 Ultra 33 Chipset. 
------------- Primary Channel ---------------- Secondary Channel -------------                  
                enabled                          enabled 
                
------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------ 
DMA enabled:    yes              no              yes               no  
UDMA enabled:   yes              no              no                no  
UDMA enabled:   2                X               X                 X 
UDMA DMA PIO

Al navegar en un directorio para un canal IDE, como ide0, otorga información adicional. El archivo channel proporciona el número de canal, mientras que el model indica el tipo de bus para el canal (tal como pci).

3.3.5.1. Directorios de dispositivos

Dentro de cada directorio de canal IDE hay un directorio de dispositivos. El nombre del directorio de dispositivos corresponde a la letra de la unidad en el directorio /dev/. Por ejemplo, la primera unidad IDE en ide0 sería hda.

Nota

Existe un enlace simbólico para cada uno de estos directorios de dispositivos en el directorio /proc/ide/.

Cada dispositivo, como un disco duro o un CD-ROM, tendrá en ese canal su propio directorio en el que están incluidas su propia recopilación de información y estadísticas. Los contenidos de esos directorios varían de acuerdo con el tipo de dispositivo conectado. Algunos de los archivos más útiles habituales en diferentes dispositivos incluyen:

  • cache — La caché del dispositivo.

  • capacity — La capacidad del dispositivo, en bloques de 512 bytes.

  • driver — El controlador y la versión usados para controlar el dispositivo.

  • geometry — La geometría física y lógica del dispositivo.

  • media — El tipo de dispositivo, como por ejemplo un disk.

  • model — El nombre del modelo del dispositivo.

  • settings — Recopilación de parámetros actuales del dispositivo. Este archivo usualmente contiene bastante información técnica útil. Un ejemplo de archivo settings para un disco duro IDE estándar, se vería similar a lo siguiente:

    name                value          min          max          mode 
    ----                -----          ---          ---          ---- 
    acoustic            0              0            254          rw 
    address             0              0            2            rw 
    bios_cyl            38752          0            65535        rw 
    bios_head           16             0            255          rw 
    bios_sect           63             0            63           rw 
    bswap               0              0            1            r 
    current_speed       68             0            70           rw 
    failures            0              0            65535        rw 
    init_speed          68             0            70           rw 
    io_32bit            0              0            3            rw 
    keepsettings        0              0            1            rw 
    lun                 0              0            7            rw 
    max_failures        1              0            65535        rw 
    multcount           16             0            16           rw 
    nice1               1              0            1            rw 
    nowerr              0              0            1            rw 
    number              0              0            3            rw 
    pio_mode            write-only     0            255          w 
    unmaskirq           0              0            1            rw 
    using_dma           1              0            1            rw 
    wcache              1              0            1            rw
    

3.3.6. /proc/irq/

Este directorio se usa para configurar la afinidad de una IRQ con una CPU, lo que le permite conectar una IRQ particular a una sola CPU. De manera alternativa, puede evitar que una CPU manipule cualquier IRQ.

Cada IRQ tiene su propio directorio, permitiendo que cada IRQ sea configurada individualmente. El archivo /proc/irq/prof_cpu_mask es una máscara de bits que contiene los valores predeterminados para el archivo smp_affinity en el directorio IRQ. Los valores en smp_affinity especifican qué CPUs manipulan esa IRQ en particular.

Para más información sobre el directorio /proc/irq/refiérase a la siguiente información instalada:

/usr/share/doc/kernel-doc-<versión>/Documentation/filesystems/proc.txt

3.3.7. /proc/net/

El directorio proporciona una visión exhaustiva de diversos parámetros y estadísticas de red. Cada directorio y archivo virtual dentro de este directorio describe aspectos sobre la configuración de la red en el sistema. Abajo se muestra un listado parcial del directorio /proc/net/:

  • arp — Lista la tabla del kernel ARP. Este archivo es particularmente útil para conectar la dirección del hardware a una dirección IP de un sistema.

  • Directorio atm/ — Los archivos dentro de este directorio contienen las configuraciones de Asynchronous Transfer Mode (ATM) y estadísticas. Este directorio es principalmente usado con redes ATM y tarjetas ADSL.

  • dev — Lista los diferentes dispositivos de red configurados en el sistema, complementado con estadísticas de transmisión y recepción. Este archivo le indica el número de paquetes que cada interfaz ha enviado y recibido, el número de paquetes entrantes y salientes, número de errores vistos, el número de paquetes abandonados y mucho más.

  • dev_mcast — Lista los grupos multicast Layer2 en los que cada dispositivo esté escuchando.

  • igmp — Lista las direcciones IP con destinatarios múltiples (multicast) a las que el sistema se ha incorporado.

  • ip_conntrack — Lista las conexiones de red para las máquinas que están reenviando conexiones IP.

  • ip_tables_names — Lista los tipos de iptables en uso. Este archivo sólo está presente si iptables esta activo en el sistema y contiene uno o más de los siguientes valores: filter, mangle o nat.

  • ip_mr_cache — Lista de la caché de routing de múltiple destinatario.

  • ip_mr_vif — Lista las interfaces virtuales de múltiple destinatario (multicast).

  • netstat — Contiene una amplia colección de estadísticas de red, incluyendo la temporización TCP, los cookies enviados y recibidos y mucho más.

  • psched — Lista de parámetros de planificación global del paquete.

  • raw — Lista las estadísticas de dispositivo brutos (raw).

  • route — Lista la tabla de enrutamiento del kernel.

  • rt_cache — Contiene la caché de ruta actual.

  • snmp — Lista de los datos del protocolo Simple Network Management Protocol (SNMP) para varios protocolos de red en uso.

  • sockstat — Proporciona estadísticas de socket.

  • tcp — Contiene información detallada del socket TCP.

  • tr_rif — Lista la tabla de enrutamiento de token ring RIF.

  • udp — Contiene información detallada del socket UDP.

  • unix — Lista sockets de dominio UNIX.

  • wireless — Lista datos de la interfaz de radio.

3.3.8. /proc/scsi/

Este directorio es análogo al directorio /proc/ide/, sin embargo, es sólo para dispositivos SCSI conectados.

El archivo primario aquí es /proc/scsi/scsi, que contiene una lista de cada dispositivo SCSI reconocido. A partir de esta lista se puede obtener el tipo de dispositivo, así como también el nombre del modelo, fabricante, canal SCSI y el ID.

Por ejemplo, si un sistema contiene un CD-ROM SCSI, una unidad de cinta, un disco duro y un controlador RAID, este archivo se parecerá a:

Attached devices:  
Host: scsi1 
Channel: 00 
Id: 05 
Lun: 00   
Vendor: NEC      
Model: CD-ROM DRIVE:466 
Rev: 1.06   
Type:   CD-ROM                          
ANSI SCSI revision: 02 
Host: scsi1 
Channel: 00 
Id: 06 
Lun: 00   
Vendor: ARCHIVE  
Model: Python 04106-XXX 
Rev: 7350   
Type:   Sequential-Access                
ANSI SCSI revision: 02 
Host: scsi2 
Channel: 00 
Id: 06 
Lun: 00   
Vendor: DELL     
Model: 1x6 U2W SCSI BP  
Rev: 5.35   
Type:   Processor                        
ANSI SCSI revision: 02 
Host: scsi2 
Channel: 02 
Id: 00 
Lun: 00   
Vendor: MegaRAID 
Model: LD0 RAID5 34556R 
Rev: 1.01   
Type:   Direct-Access                    
ANSI SCSI revision: 02

Cada controlador SCSI usado por el sistema tiene su propio directorio en /proc/scsi/, que contiene archivos específicos para cada controlador SCSI usando ese controlador. En el ejemplo anterior, los directorios aic7xxx y megaraid están presentes, puesto que hay dos controladores en uso. Los archivos en cada uno de los directorios contienen típicamente un rango de direcciones de E/S, información de IRQ y estadísticas para el controlador SCSI particular usando ese controlador. Cada controlador puede remitir un tipo y cantidad de información diferente. El archivo del adaptador Adaptec AIC-7880 Ultra SCSI en este ejemplo produce una salida como la siguiente:

Adaptec AIC7xxx driver version: 5.1.20/3.2.4 
Compile Options:   
TCQ Enabled By Default : Disabled   
AIC7XXX_PROC_STATS     : Enabled   
AIC7XXX_RESET_DELAY    : 5  
Adapter Configuration:            
SCSI Adapter: Adaptec AIC-7880 Ultra SCSI host adapter                            
Ultra Narrow Controller     PCI MMAPed 
I/O Base: 0xfcffe000  
Adapter SEEPROM Config: SEEPROM found and used.       
Adaptec SCSI BIOS: Enabled                     
IRQ: 30                    
SCBs: Active 0, Max Active 1, Allocated 15, HW 16, Page 255              
Interrupts: 33726       
BIOS Control Word: 0x18a6    
Adapter Control Word: 0x1c5f   
Extended Translation: Enabled 
Disconnect Enable Flags: 0x00ff      
Ultra Enable Flags: 0x0020  
Tag Queue Enable Flags: 0x0000 
Ordered Queue Tag Flags: 0x0000 
Default Tag Queue Depth: 8     
Tagged Queue By Device array for aic7xxx 
host instance 1:       {255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}     
Actual queue depth per device for aic7xxx host instance 1:       {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}
Statistics:   

(scsi1:0:5:0) Device using Narrow/Sync transfers at 20.0 MByte/sec, offset 15   
Transinfo settings: current(12/15/0/0), goal(12/15/0/0), user(12/15/0/0)   
Total transfers 0 (0 reads and 0 writes)              
                < 2K      2K+     4K+     8K+    16K+    32K+    64K+   128K+    
Reads:        0       0       0       0       0       0       0       0   
Writes:       0       0       0       0       0       0       0       0   

(scsi1:0:6:0) Device using Narrow/Sync transfers at 10.0 MByte/sec, offset 15   
Transinfo settings: current(25/15/0/0), goal(12/15/0/0), user(12/15/0/0)   
Total transfers 132 (0 reads and 132 writes)              
                < 2K      2K+     4K+     8K+    16K+    32K+    64K+   128K+    
Reads:        0       0       0       0       0       0       0       0   
Writes:       0       0       0       1     131       0       0       0

Esta salida revela la velocidad de transmisión a los dispositivos SCSI conectados al controlador basado en el canal ID, así como estadísticas detalladas referentes a la cantidad y tamaño de los archivos leídos o escritos por ese dispositivo. Por ejemplo, este controlador se está comunicando con el CD-ROM a 20 megabytes por segundo, mientras que la unidad de cinta sólo se está comunicando a 10 megabytes por segundo.

3.3.9. /proc/sys/

El directorio /proc/sys/ es diferente de otros en /proc/ porque no sólo proporciona información sobre el sistema pero también permite al administrador activar y desactivar inmediatamente características del kernel.

Atención

Tenga mucho cuidado al cambiar la configuración de un sistema en producción usando los diversos archivos en el directorio /proc/sys/. La modificación del valor incorrecto puede dejar el kernel inestable, requiriendo que se reinicie el sistema.

Por esta razón, asegúrese de que las opciones sean válidas para ese archivo antes de intentar cambiar un valor en /proc/sys/.

Una buena forma de determinar si un archivo particular se puede configurar o si tan sólo está diseñado para proporcionar información, es listándolo con la opción -l en el intérprete de comandos de la shell. Si se puede escribir en el archivo, quizás podrá utilizarlo para configurar el kernel de algún modo. Por ejemplo, un listado parcial de /proc/sys/fs sería de la siguiente manera:

-r--r--r--    1 root     root            0 May 10 16:14 dentry-state
-rw-r--r--    1 root     root            0 May 10 16:14 dir-notify-enable 
-r--r--r--    1 root     root            0 May 10 16:14 dquot-nr 
-rw-r--r--    1 root     root            0 May 10 16:14 file-max 
-r--r--r--    1 root     root            0 May 10 16:14 file-nr

En este listado, los archivos dir-notify-enable y file-max pueden escribirse y, por consiguiente, usarse para la configuración del kernel. Los otros archivos sólo proporcionan retroalimentación sobre las configuraciones actuales.

Para cambiar un valor en el archivo /proc/sys tiene que repetir el valor nuevo en el archivo. Por ejemplo, para habilitar la System Request Key en un kernel en ejecución, escriba el comando:

echo 1 > /proc/sys/kernel/sysrq

Esto cambiará el valor para sysrq de 0 (off) a 1 (on).

Unos cuantos archivos de configuración /proc/sys contienen más de un valor. Para enviar nuevos valores correctamente, coloque un espacio entre cada valor traspasado con el comando echo, como se ha hecho a continuación:

echo 4 2 45 > /proc/sys/kernel/acct

Nota

Cualquier cambio de configuración que haga mediante el comando echo desaparecerá cuando vuelva a iniciar el sistema. Para hacer que los cambios en la configuración tengan efecto después de que el sistema es reiniciado consulte la Sección 3.4, “Uso del comando sysctl.

El directorio/proc/sys contiene directorios diferentes que controlan diferentes aspectos de la ejecución de un kernel.

3.3.9.1. /proc/sys/dev/

Este directorio proporciona parámetros para dispositivos particulares en el sistema. La mayoría de sistemas tienen al menos dos directorios cdrom y raid. Los kernels personalizados pueden tener otros directorios, tales como parport, que proporciona la habilidad de compartir un puerto paralelo entre múltiples controladores de dispositivo.

El directorio cdrom contiene un archivo llamado info que revela algunos parámetros importantes del CD-ROM:

CD-ROM information, Id: cdrom.c 3.20 2003/12/17   
drive name:             hdc 
drive speed:            48 
drive # of slots:       1 
Can close tray:         1 
Can open tray:          1 
Can lock tray:          1 
Can change speed:       1 
Can select disk:        0 
Can read multisession:  1 
Can read MCN:           1 
Reports media changed:  1 
Can play audio:         1 
Can write CD-R:         0 
Can write CD-RW:        0 
Can read DVD:           0 
Can write DVD-R:        0 
Can write DVD-RAM:      0 
Can read MRW:           0 
Can write MRW:          0 
Can write RAM:          0

Este archivo se puede escanear con la finalidad de descubrir las cualidades de un CD-ROM desconocido. Si tiene a su disposición múltiples CD-ROMs en un sistema, cada dispositivo tendrá su propia columna de información.

Se pueden utilizar diversos archivos en /proc/sys/dev/cdrom, como autoclose y checkmedia, para controlar el CD-ROM del sistema. Use el comando echo para activar o desactivar estas características.

Si se compila el soporte RAID en el kernel, tendrá a su disposición un directorio /proc/sys/dev/raid/ con al menos dos archivos dentro del mismo: speed_limit_min y speed_limit_max. Estas configuraciones determinan la aceleración de los dispositivos RAID para tareas intensivas de E/S, tales como la resincronización de discos.

3.3.9.2. /proc/sys/fs/

Este directorio contiene un compendio de opciones y de información referente a varios aspectos del sistema de archivos, incluyendo la información de cuotas, manipulación del archivos, inode y dentry.

El directorio binfmt_misc se usa para proporcionar soporte del kernel para formatos binarios misceláneos.

Los archivos importantes en /proc/sys/fs/ incluyen:

  • dentry-state — Proporciona el estado del directorio de la caché. El archivo se vería de la siguiente manera:

    57411        52939        45        0        0        0
    

    El primer número revela el número total de las entradas de la caché del directorio, mientras que el segundo número visualiza el número de entradas inutilizadas. El tercero, le indica el número de segundos en que un directorio ha sido liberado y puede ser reclamado y el cuarto mide las páginas que han sido requeridas por el sistema en la actualidad. Los últimos dos números no están en uso y tan sólo visualizan ceros.

  • dquot-nr — Muestra el número máximo de entradas de cuota de disco cacheado.

  • file-max — Lista el número máximo de manejadores de archivos que el kernel puede asignar. Si incrementa el valor de este archivo puede solucionar los errores causados por la falta de manejadores de archivos disponibles.

  • file-nr — Lista el número de manejadores de archivos asignados, manipuladores de archivos usados, así como el número máximo de manejadores de archivos.

  • overflowgid y overflowuid — Define el ID de grupo establecido y el ID de usuario, respectivamente, para el uso con el sistema de archivos que tan sólo soporta los IDs de grupo y usuario de 16 bits.

  • super-max — Controla el número máximo de superbloques disponible.

  • super-nr — Visualiza el número actual de superbloques en uso.

3.3.9.3. /proc/sys/kernel/

Este directorio contiene una variedad de archivos de configuración diferentes que afectan directamente a la operación del kernel. Algunos de los archivos más importantes incluyen:

  • acct — Controla la suspensión del proceso de contabilización basado en el porcentaje de espacio libre disponible en el sistema de archivos conteniendo el registro (log). Por defecto, el archivo aparecerá de la siguiente manera:

    4        2        30
    

    El primer valor fija el porcentaje de espacio libre necesario para reanudar el proceso de inicio de sesión, mientras que el segundo valor indica el umbral del porcentaje de espacio libre cuando se suspende el inicio de sesión. El tercer valor fija el intervalo en segundos, en que el kernel interroga al sistema de archivos para ver si el inicio de sesión se suspende o continua.

  • cap-bound — Controla las configuraciones de las capability bounding, que proporcionan una lista de capacidades para cualquier proceso en el sistema. Si una capacidad no está listada aquí, ningún proceso, por muy privilegiado que sea éste, puede realizarlo. La idea inicial es hacer que el sistema sea más seguro asegurando que no acontezcan ciertas cosas, por lo menos llegados a un cierto nivel del proceso de arranque.

    Para una lista de los valores válidos para este archivo virtual, refiérase a la siguiente documentación instalada:

    /lib/modules/<kernel-version>/build/include/linux/capability.h.

  • ctrl-alt-del — Controla si Ctrl-Alt-Delete reiniciará el ordenador adecuadamente mediante el uso de init (0) o si forzará un rearranque inmediato sin la sincronización de los buffers modificados al disco (1).

  • domainname — Configura el nombre de dominio del sistema, tal como example.com.

  • exec-shield — Configura la característica Exec Shield del kernel. Exec Shield proporciona protección en contra de ciertos tipos de ataques de sobrecarga de la memoria intermedia.

    Hay dos valores posibles para este archivo virtual:

    • 0 — Inhabilita Exec Shield.

    • 1 — Habilita Exec Shield. Este es el valor predeterminado.

    Importante

    Si un sistema está ejecutando aplicaciones de seguridad confidencial que se iniciaron mientras Exec Shield estaba desactivado, estas aplicaciones se deberan iniciar una vez más cuando Exec Shield esté habilitado nuevamente.

  • exec-shield-randomize — Habilita la ubicación aleatoria de varios elementos en memoria. Esto ayuda a impedir que atacantes potenciales puedan ubicar programas y demonios en memoria. Cada vez que un programa o demonio arranca, se coloca en un espacio de memoria diferente, nunca la dirección de memoria es estática o absoluta.

    Hay dos valores posibles para este archivo virtual:

    • 0 — Desactiva la aleatorización de Exec Shield. Esto puede ser útil para propósitos de depuración de aplicaciones.

    • 1 — Permite la aleatorización de Exec Shield. Este es el valor predeterminado. Nota: el archivo exec-shield también se debe colocar a 1 para que exec-shield-randomize esté activo.

  • hostname — Configura el nombre del sistema host, por ejemplo www.example.com.

  • hotplug — Configura la utilidad a utilizar cuando se detecta un cambio en la configuración del sistema. Principalmente se usa con USB y Cardbus PCI. El valor por defecto de /sbin/hotplug no debería ser cambiado a menos que esté probando un nuevo programa para cumplir con este papel.

  • modprobe — Fija la ubicación del programa a usar para cargar los módulos del kernel. El valor por defecto es /sbin/modprobe que significa que kmod lo llamará para cargar el módulo cuando un hilo del kernel llame kmod.

  • msgmax — Fija el tamaño máximo de cualquier mensaje enviado desde un proceso a otro y está fijado en 8192 bytes por defecto. Debería tener cuidado al incrementar este valor, ya que los mensajes en cola entre procesos son almacenados en una memoria de kernel sin memoria de intercambio (swap). Cualquier incremento en msgmax incrementará los requerimientos de RAM de su sistema.

  • msgmnb — Establece el número máximo de bytes en una única cola de mensajes. Por defecto es 16384.

  • msgmni — Establece el número máximo de identificadores de la cola de mensajes. Por defecto, 16.

  • osrelease — Lista el número de versión del kernel de Linux. Este archivo tan sólo puede ser alterado al cambiar la fuente del kernel y recompilarla.

  • ostype — Visualiza el tipo de sistema operativo. Por defecto, este archivo está configurado para Linux y este valor tan sólo puede ser cambiado al cambiar la fuente del kernel y recompilarla.

  • overflowgid y overflowuid — Define el ID de grupo establecido y el ID de usuario, respectivamente, para el uso con llamadas del sistema a arquitecturas que tan sólo soportan IDs de grupo y usuario de 16 bits.

  • panic — Define el número de segundos que el kernel pospone el arranque del sistema cuando se experimenta una emergencia en el kernel. Por defecto, el valor está establecido en 0, lo que deshabilita el rearranque automático tras una emergencia.

  • printk — Este archivo controla una variedad de configuraciones relacionadas con la impresión o los mensajes de error de registro. Cada mensaje de error remitido por el kernel tiene un nivel de registro asociado a éste que define la importancia del mensaje. Los valores de loglevel aparecen en el orden siguiente:

    • 0 — Emergencia del Kernel. No se puede utilizar el sistema.

    • 1 — Alerta del kernel. Se debe actuar inmediatamente.

    • 2 — La condición del kernel se considera crítica.

    • 3 — Condición de error general del kernel.

    • 4 — Condición de aviso general del kernel.

    • 5 — Nota del kernel de una condición normal pero significativa.

    • 6 — Mensaje informativo del kernel.

    • 7 — Mensajes de depuración del kernel.

    En el archivo printk aparecen cuatro valores:

    6     4     1     7
    

    Cada uno de estos valores define una regla diferente para tratar con los mensajes de error. El primer valor, llamado nivel de registro de consola, define la prioridad más baja de mensajes que se imprimirán en la consola. (Observe que, cuanto más baja sea ésta, más alto será el número de nivel de registro.) El segundo valor establece el nivel de registro por defecto para mensajes sin un nivel de registro explícito. El tercer valor establece el nivel de registro más bajo posible para el nivel de registro de la consola. El último valor establece el valor por defecto para el nivel de registro de la consola.

  • Directorio random — Lista un número de valores relacionados a la generación de números aleatorios para el kernel.

  • rtsig-max — Configura el número máximo de señales en tiempo real POSIX que el sistema podría haber puesto en cola en un momento dado. El valor por defecto es 1024.

  • rtsig-nr — Lista el número actual de señales POSIX en tiempo real que el kernel ha puesto en cola.

  • sem — Configura los valores de semáforo dentro del kernel. Un semáforo es un objeto System V IPC que es usado para controlar la utilización de un proceso particular.

  • shmall — Establece la cantidad total de memoria que se puede utilizar de una sola vez en el sistema, en bytes. Por defecto, este valor es 2097152.

  • shmmax — Establece el mayor tamaño de segmento de memoria compartida que permite el kernel, en bytes. Por defecto, este valor es 33554432. No obstante, el kernel soporta valores con mucho más margen.

  • shmmni — Establece el número máximo de segmentos de memoria compartida para el sistema completo, en bytes. Por defecto, este valor es 4096

  • sysrq — Activa la llave de petición de sistema, si este valor difiere del establecido por defecto 0.

    La llave de petición del sistema permite darle entradas inmediatas al kernel mediante combinaciones simples de teclas. Por ejemplo, se puede usar la llave de petición del sistema para apagar de inmediato el sistema o para reiniciarlo, sincronizar todos los sistemas de archivos montados o volcar información importante a la consola. Para iniciar una llave de petición del sistema escriba Alt-SysRq-<system request code>. Reemplace <system request code> con uno de los siguientes códigos de petición de sistema:

    • r — Inhabilita el modo sin formato para el teclado y lo configura a XLATE (un modo de teclado más limitado el cual no reconoce modificadores tales como Alt, Ctrl, o Shift para todas las teclas).

    • k — Mata todos los procesos activos en una consola virtual. También llamada Llave de Acceso Segura (SAK), a menudo se utiliza para verificar que el indicador de comandos del inicio de conexión es generado desde init y no una copia troyana diseñada para capturar nombres de usuarios y contraseñas.

    • b — Reinicia el kernel sin primero desmontar los sistemas de archivos o sincronizar los discos conectados al sistema.

    • c — Apaga el sistema sin primero desmontar los sistemas de archivos o sincronizar los discos conectados al sistema.

    • o — Apaga el sistema.

    • s — Intenta sincronizar los discos conectados al sistema.

    • u — Intenta desmontar y volver a montar todos los sistemas de archivos como de sólo lectura.

    • p — Coloca en la salida todas las banderas y registros a la consola.

    • t — Coloca en la consola una lista de los procesos.

    • m — Coloca en la consola las estadísticas de la memoria.

    • 0 hasta 9 — Configura el nivel de registro para la consola.

    • e — Mata todos los procesos usando SIGTERM, excepto init.

    • i — Mata todos los procesos usando SIGKILL, excepto init.

    • l — Mata todos los procesos usando SIGKILL (incluyendo init). Después de emitir este código de llave de petición del sistema, el sistema no se puede utilizar.

    • h — Muestra texto de ayuda.

    Esta característica es útil cuando se utiliza un kernel de desarrollo o cuando se estén experimentando congelamientos del sistema.

    Atención

    La característica de llave del petición del sistema es considerada un riesgo de seguridad porque una consola desatendida puede permitir a un atacante obtener acceso al sistema. Por esta razón, esta desactivada por defecto.

    Para obtener más información sobre la llave de petición del sistema, remítase a /usr/share/doc/kernel-doc-<version>/Documentation/sysrq.txt

  • sysrq-key — Define el código para la Llave de petición de sistema, (por defecto es 84).

  • sysrq-sticky — Define si la llave de petición del sistema es una combinación de llaves acorde. Los valores aceptados son como sigue:

    • 0Alt-SysRq y el código solicitado por el sistema debe ser presionado de forma simultánea. Este es el valor por defecto.

    • 1Alt-SysRq se deben presionar simultáneamente pero el código de petición del sistema se puede presionar en cualquier momento antes de que se cumplan el número de segundos especificados en /proc/sys/kernel/sysrq-timer.

  • sysrq-timer — Configura el número máximo de segundos que pueden pasar antes de presentar el código de petición del sistema. El valor por defecto es 10.

  • tainted — Indica si hay un módulo no GPL cargado.

    • 0 — No se cargó ningún módulo no GPL.

    • 1 — Está cargado al menos un módulo sin una licencia GPL (incluyendo módulos sin licencia).

    • 2 — Al menos un módulo fué cargado a la fuerza con el comando insmod -f.

  • threads-max — Establece el número máximo de hilos que puede usar el kernel, con un valor por defecto de 2048.

  • version — Visualiza la fecha y la hora en los que el kernel fue compilado por última vez. El primer campo en este archivo, tal como #3, está relacionado con el número de veces que se ha construido un kernel desde la base de la fuente.

3.3.9.4. /proc/sys/net

Este directorio contiene diversos subdirectorios que tratan tópicos sobre redes. Las diferentes configuraciones en el momento en que el kernel fue compilado colocan diferentes directorios aquí tales como ethernet/, ipv4/, ipx/ y ipv6/. Los administradores de sistemas podrán ajustar la configuración de la red en un sistema en funcionamiento alterando los archivos en estos directorios.

Debido a la amplia variedad de posibles opciones de red disponibles con Linux, tan sólo se comentarán los directorios /proc/sys/net/.

El directorio /proc/sys/net/core/ contiene una variedad de configuraciones que controlan la interacción entre el kernel y las capas de red. Los archivos más importantes son:

  • message_burst — Configura la cantidad de tiempo en décimas de segundos requeridos para escribir un mensaje nuevo de aviso. Este valor se utiliza para prevenir ataques de Rechazo de servicios (o Denial of Service, DoS) y la configuración por defecto es 50.

  • message_cost — Configura un costo en cada mensaje de aviso. Cuanto más alto es el valor de este archivo (por defecto 5), más probable es que el mensaje de aviso sea ignorado. También se utiliza para prevenir ataques de DoS.

    La idea de un ataque DoS es bombardear su sistema con peticiones que generen errores y llenen sus particiones con archivos logs o necesiten todos los recursos del sistema para manipular el registro de errores. Las configuraciones en message_burst y message_cost están diseñadas para ser modificadas basándose el riesgo aceptable del sistema contra la necesidad de un registro exhaustivo.

  • netdev_max_backlog — Establece el número máximo de paquetes permitido para hacer cola cuando una interfaz en particular recibe paquetes a una velocidad superior de la que el kernel puede procesarlos. El valor por defecto para este archivo es 300.

  • optmem_max — Configura el tamaño máximo de la memoria intermedia auxiliar por socket.

  • rmem_default — Establece el tamaño por defecto de la memoria intermedia de recepción del socket en bytes.

  • rmem_max — Establece el tamaño máximo de la memoria intermedia de recepción en bytes.

  • wmem_default — Establece el tamaño por defecto de la memoria intermedia de envíos del socket en bytes.

  • wmem_max — Establece el tamaño máximo de la memoria intermedia de envíos del socket en bytes.

El directorio /proc/sys/net/ipv4/ contiene configuraciones de red adicionales. Muchas de estas configuraciones, usadas en conjunto, son muy útiles para prevenir ataques al sistema o cuando se usa el sistema para que actúe como un enrutador.

Atención

Un cambio erróneo en estos archivos puede afectar la conectividad remota del sistema.

Aquí tiene una lista de algunos de los archivos más importantes en el directorio /proc/sys/net/ipv4/:

  • icmp_destunreach_rate, icmp_echoreply_rate, icmp_paramprob_rate y icmp_timeexeed_rate — Establece la tasa máxima de paquetes ICMP a enviar, en centésimas de un segundo, para hosts bajo ciertas condiciones. Una configuración de 0 elimina cualquier retraso y no es una buena idea.

  • icmp_echo_ignore_all y icmp_echo_ignore_broadcasts — Permite que el kernel ignore paquetes ICMP ECHO desde cada host o tan sólo aquéllos que se originen desde direcciones broadcast y de destinatario múltiple, respectivamente. 0 permite que el kernel responda, mientras un 1 ignora los paquetes.

  • ip_default_ttl — Establece el Time To Live (TTL) predeterminado, que limita el número de saltos que un paquete puede efectuar antes de alcanzar su destino. Si incrementa este valor, la ejecución del sistema puede disminuir.

  • ip_forward — Permite interfaces en el sistema para reenviar paquetes a otro. Por defecto, este archivo está fijado en 0. Si se configura este valor a 1 activa el reenvío de paquetes.

  • ip_local_port_range — Especifica el rango de puertos a usar por TCP o UDP cuando se necesita un puerto local. El primer número es el puerto más bajo que puede utilizar, y el segundo especifica el puerto más alto. Cualquier sistema que se crea que necesitará más puertos que los predeterminados 1024 hasta 4999 debería usar el rango 32768 hasta 61000.

  • tcp_syn_retries — Proporciona un límite en el número de veces que el sistema retransmitirá un paquete SYN cuando se intenta establecer una conexión.

  • tcp_retries1 — Establece el número de retransmisiones permitidas que intentan responder una conexión de entrada. 3 por defecto.

  • tcp_retries2 — Establece el número de retransmisiones permitidas de paquetes TCP. 15 por defecto.

El archivo llamado

/usr/share/doc/kernel-doc-<versión>/Documentation/networking/ ip-sysctl.txt

contiene una lista completa de archivos y opciones disponibles en el directorio /proc/sys/net/ipv4/:

Existe un número de otros directorios dentro del directorio /proc/sys/net/ipv4/ y cada uno cubre un aspecto diferente de la pila de red. El directorio /proc/sys/net/ipv4/conf/ permite a cada interfaz del sistema ser configurada en diferentes formas, incluyendo el uso de valores por defecto para dispositivos no configurados (en el subdirectorio /proc/sys/net/ipv4/conf/default/) y configuraciones que invalidan todas las configuraciones especiales (en el subdirectorio /proc/sys/net/ipv4/conf/all/).

El directorio /proc/sys/net/ipv4/neigh/ contiene configuraciones para la comunicación con un host que está conectado directamente al sistema (llamado un vecino de red) y también contiene configuraciones diferentes para sistemas que están a más de un salto de distancia.

Enrutamiento por encima de IPV4 también tiene su propio directorio /proc/sys/net/ipv4/route/. A diferencia de conf/ y neigh/, el directorio /proc/sys/net/ipv4/route/ contiene especificaciones que aplican al enrutamiento con cualquier interfaz en el sistema. Muchas de estas configuraciones tal como max_size, max_delay y min_delay están relacionadas con el control del tamaño de la caché de enrutamiento. Para limpiar la caché de enrutamiento escriba cualquier valor al archivo flush.

Encontrará información adicional sobre estos directorios y los posibles valores de sus archivos de configuración en:

/usr/share/doc/kernel-doc-<versión>/Documentation/filesystems/proc.txt

3.3.9.5. /proc/sys/vm/

Este directorio facilita la configuración del subsistema de memoria virtual (VM) del kernel de Linux. El kernel hace un uso extensivo e inteligente de la memoria virtual, conocida comunmente como espacio swap.

Los siguientes archivos se encuentran habitualmente en el directorio /proc/sys/vm:

  • block_dump — Configura la depuración de bloques de E/S cuando está activo. Se registran todas las operaciones de lectura/escritura o que impliquen ensuciar bloques hechas a archivos. Esto puede ser muy útil para efectos de diagnóstico del giros del disco para la conservación de la batería de las portátiles. Se pueden recuperar todas las salidas cuando block_dump está activado, mediante dmesg. El valor por defecto es 0.

    Sugerencia

    Si block_dump está activado a la vez que la depuración del kernel, es prudente detener el demonio klogd, pues generará actividad del disco errónea causada por block_dump.

  • dirty_background_ratio — Configura la escritura de los datos sucios a este porcentaje total de memoria, a través del demonio pdflush. El valor por defecto es 10.

  • dirty_expire_centisecs — Define cuando los datos en memoria que se encuentran marcados como 'dirty' son lo suficientemente antiguos como para ser candidatos a escritura. Los datos en memoria por más tiempo que este intervalo, son escritos la próxima vez que se active un demonio pdflush. El valor por defecto es 3000, expresado en cientos de segundos.

  • dirty_ratio — Comienza la escritura activa de los datos sucios a este porcentaje total de memoria para el generador de datos sucios, a través de pdflush. El valor por defecto es 40.

  • dirty_writeback_centisecs — Define el intervalo entre activaciones del demonio pdflush, que escribe periódicamente los datos en memoria al disco. El valor por defecto es 500, expresado en cientos de segundos.

  • laptop_mode — Minimiza el número de veces que un disco duro necesita girar manteniendo los giros por el mayor tiempo posible, y por ende, conservando energía en las baterías de las portatiles. Esto inclementa la eficiencia al combinar todos los procesos futuros de E/S juntos, reduciendo la frecuencia de los giros. El valor por defecto es 0, pero se activa automáticamente en caso de que se use la bateria en la portátil.

    Este valor es controlado automáticamente por el demonio acpid una vez que se le notifica al usuario que la energía de la batería está activada. No se necesitan modificaciones o interacciones por parte del usuario si la portátil soporta la especificación de ACPI (Advanced Configuration and Power Interface).

    Para más información, consulte la siguiente documentación instalada:

    /usr/share/doc/kernel-doc-<version>/Documentation/laptop-mode.txt

  • lower_zone_protection — Determina qué tan agresivo es el kernel en defender las zonas de ubicación de memoria baja. Esto es efectivo cuando se utiliza con máquinas configuradas con el espacio de memoria highmem activado. El valor por defecto es 0, sin protección. Todos los demás valores enteros están en megabytes, y por lo tanto, la memoria lowmem está protegida de ser asignada por los usuarios.

    Para más información, consulte la siguiente documentación instalada:

    /usr/share/doc/kernel-doc-<versión>/Documentation/filesystems/proc.txt

  • max_map_count — Configura el número máximo de áreas de mapa de memoria que puede tener un proceso. En la mayoría de los casos, el valor por defecto de 65536 es apropiado.

  • min_free_kbytes — Obliga a que Linux VM (el gestor de memoria virtual) mantenga un número mínimo de kilobytes libres. El VM utiliza este número para computarizar un valor pages_min para cada zona lowmem en el sistema. El valor por defecto es en relación al número total de memoria en la máquina.

  • nr_hugepages — Lista el número actual de páginas hugetlb configuradas en el kernel.

    Para más información, consulte la siguiente documentación instalada:

    /usr/share/doc/kernel-doc-<version>/Documentation/vm/hugetlbpage.txt

  • nr_pdflush_threads — Indica el número de demonios pdflush que se están ejecutando actualmente. Este archivo es de sólo lectura, y no debería ser cambiado por el usuario. Bajo grandes cargas de E/S, el kernel incrementa el valor por defecto de dos.

  • overcommit_memory — Configura las condiciones bajo las cuales una petición de gran memoria es aceptada o rechazada. Están disponibles los siguientes tres modos:

    • 0 — El kernel lleva a cabo un manejo de memoria heurístico, estimando la cantidad de memoria disponible y suspendiendo las peticiones que son obviamente inválidas. Desafortunadamente, puesto que la memoria es asignada usando heurísticas en vez de un algoritmo preciso, esta configuración puede algunas veces ocasionar la sobrecarga de la memoria disponible en el sistema. Esta es la configuración por defecto.

    • 1 — El kernel no lleva a cabo ningún manejo de asignaciones extra de memoria. Con esta configuración, el potencial de sobrecarga de memoria se incrementa, pero también el rendimiento para las tareas intensivas de memoria (tales como aquellas ejecutadas por software científico).

    • 2 — El kernel suspende las peticiones de memoria que consumen todo el swap más el porcentaje de memoria física RAM especificado en /proc/sys/vm/overcommit_ratio. Esta configuración es mejor para aquellos que deseen menos riesgos de comprometer en exceso la memoria.

      Nota

      Esta configuración solamente es recomendada para los sistemas con áreas swap más grandes que la memoria física.

  • overcommit_ratio — Especifica el porcentaje de memoria física RAM considerada cuando /proc/sys/vm/overcommit_memory es configurado a 2. El valor por defecto es 50.

  • page-cluster — Establece el número de páginas leídas en un solo intento. El valor por defecto de 3 establecido en 16 páginas, es apropiado para la mayoría de los sistemas.

  • swappiness — Establece cuánto swap debería hacer una máquina. Mientras más alto es el número, ocurrirá mayor swapping. Por defecto, este valor es 60.

Toda la documentación basada en el kernel se puede encontrar en la ubicación local siguiente:

/usr/share/doc/kernel-doc-<version>/Documentation/, la cual contiene información adicional.

3.3.10. /proc/sysvipc

Este directorio contiene información sobre los recursos System V IPC. Los archivos de este directorio están relacionados con las llamadas al System V IPC de mensajes (msg), semáforos (sem), y memoria compartida (shm).

3.3.11. /proc/tty/

Este directorio contiene información sobre los dispositivos tty disponibles y usados actualmente en el sistema. Originalmente conocido como dispositivos teletipo, cualquier terminal de datos basado en carácteres se le conoce como dispositivos tty.

En Linux existen tres tipos diferentes de dispositivos tty. Los Dispositivos serial son usados con conexiones seriales, tales como un módem o usando un cable serial. Los Terminales virtuales crean las conexiones de consola comunes, tales como las consolas virtuales disponibles al pulsar Alt-<F-key> en la consola del sistema. Los Pseudo terminales crean una comunicación de dos sentidos que usan las aplicaciones de nivel alto, tales como XFree86. El archivo drivers es una lista de dispositivos tty actualmente en uso, como en el ejemplo siguiente:

serial               /dev/cua        5  64-127 serial:callout 
serial               /dev/ttyS       4  64-127 serial 
pty_slave            /dev/pts      136   0-255 pty:slave 
pty_master           /dev/ptm      128   0-255 pty:master 
pty_slave            /dev/ttyp       3   0-255 pty:slave 
pty_master           /dev/pty        2   0-255 pty:master 
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster 
/dev/ptmx            /dev/ptmx       5       2 system 
/dev/console         /dev/console    5       1 system:console 
/dev/tty             /dev/tty        5       0 system:/dev/tty 
unknown              /dev/vc/%d      4    1-63 console

El archivo /proc/tty/driver/serial lista las estadísticas en uso y el estado de cada una de las líneas de serie tty.

Para que se puedan utilizar los dispositivos tty como dispositivos de red, el kernel de Linux reforzará la disciplina de línea en el dispositivo. Esto permite que el controlador coloque un tipo específico de encabezamiento con cada bloque de datos transmitido por el dispositivo, haciendo posible que el lado remoto de la conexión vea el bloque de datos como uno más en la línea de bloques de datos. SLIP y PPP son disciplinas de línea comunes y se usan a menudo para conectar sistemas en un enlace serial.

En el archivo ldiscs encontrará disciplinas de líneas registradas e información más detallada en el directorio ldisc.

3.4. Uso del comando sysctl

El comando /sbin/sysctl es usado para visualizar, configurar y automatizar configuraciones del kernel en el directorio /proc/sys/.

Para tener una vista rápida de todas las variables configurables en el directorio /proc/sys/, escriba el comando /sbin/sysctl -a como root. Esto creará una lista grande y exhaustiva, de la cual le mostramos un pequeño parte:

net.ipv4.route.min_delay = 2 kernel.sysrq = 0 kernel.sem = 250     32000     32     128

Esta es la misma información que vería si echara un vistazo a cada uno de los archivos individualmente. La única diferencia es la localización del archivo. Por ejemplo, el archivo /proc/sys/net/ipv4/route/min_delay está representado por net.ipv4.route.min_delay, con las barras oblicuas del directorio sustituídas por puntos y la porción asumida proc.sys.

El comando sysctl se puede usar en vez de echo para asignar valores a los archivos en los que se puede escribir en el directorio /proc/sys/ . Por ejemplo, en vez de usar el comando

echo 1 > /proc/sys/kernel/sysrq

utilice el comando sysctl equivalente como se muestra:

sysctl -w kernel.sysrq="1"
kernel.sysrq = 1

A pesar de que es muy útil durante las pruebas el poder rápidamente efectuar configuraciones de valores simples en /proc/sys/, esto no funciona bien en un ambiente de producción puesto que las configuraciones especiales en /proc/sys/ se pierden cuando se vuelve a arrancar el sistema. Para conservar las configuraciones personalizadas, añádalas al archivo /etc/sysctl.conf.

Cada vez que el sistema arranque, el programa init ejecuta el script /etc/rc.d/rc.sysinit. Este script contiene un comando para ejecutar sysctl mediante el uso de /etc/sysctl.conf para determinar los valores pasados al kernel. Cualquier valor añadido a /etc/sysctl.conf surtirá efecto cada vez que el sistema arranque.

3.5. Recursos adicionales

A continuación están las fuentes adicionales de información sobre el sistema de archivos proc.

3.5.1. Documentación instalada

Algunas de la mejor documentación sobre el archivo proc está instalada por defecto en el sistema.

  • /usr/share/doc/kernel-doc-<version>/Documentation/filesystems/proc.txt — Contiene información variada, pero limitada, sobre todos los aspectos del directorio /proc/.

  • /usr/share/doc/kernel-doc-<version>/Documentation/sysrq.txt — Una descripción general de las opciones para la llave de petición del sistema.

  • /usr/share/doc/kernel-doc-<version>/Documentation/sysctl/ — Un directorio conteniendo una variedad de sugerencias para sysctl, incluyendo la modificación de valores referentes al kernel (kernel.txt), accediendo al sistema de archivos (fs.txt) y el uso de memoria virtual (vm.txt).

  • /usr/share/doc/kernel-doc-<version>/Documentation/networking/ip-sysctl.txt — Una descripción detallada de las varias opciones IP de red.

3.5.2. Sitios web útiles

  • http://www.linuxhq.com/ — Este sitio mantiene una base de datos completa de fuentes, parches y documentación para varias versiones del kernel de Linux.

Capítulo 4. Array Redundante de Discos Independientes (RAID)

La idea básica detrás de RAID es combinar pequeños y baratos controladores de discos en un array para alcanzar metas de rendimiento y redundancia que no se pueden lograr con un controlador caro y grande. El computador toma este array de controladores como un disco o unidad de almacenamiento lógico individual.

4.1. ¿Qué es RAID?

RAID permite que la información acceda a varios discos. RAID utiliza técnicas como separación de disco (Nivel 0 RAID), copia espejo de disco (Nivel 1 RAID) y separación de disco con paridad (Nivel 5 RAID) para lograr redundancia, menos latencia, mayor amplitud de banda y una mayor abilidad para recuperarse de fallos del disco duro.

El concepto básico del RAID es que los datos se pueden distribuir entre los discos del grupo de manera consistente. Para hacer esto, primero se deben dividir los datos en partes iguales (a menudo de 32k o 64k, aunque también se pueden usar otros tamaños). Cada parte es escrita en los discos duros en el array RAID de acuerdo con el nivel RAID empleado. Cuando se leen los datos el proceso sucede al contrario, dando la impresión de que muchos discos son combinados en uno solo.

4.2. ¿Quién debe utilizar RAID?

Los administradores del sistema y aquellos que necesitan controlar grandes cantidades de datos se benificiarían del uso de la tecnología RAID. Los motivos principales para utilizar RAID son:

  • Aumento de la velocidad

  • Aumento de la capacidad de almacenamiento mediante el uso de un disco virtual

  • MInimiza los fallos del disco

4.3. RAID: Hardware vs. Software

Existen dos posibles enfoques a RAID: RAID Hardware o Software.

4.3.1. Hardware RAID

Las soluciones hardware gestionan el subsistema RAID independientemente del host presentándole un solo disco.

Un dispositivo de hardware RAID se conecta al controlador SCSI que presenta al sistema un único disco SCSI. Un sistema RAID externo se encarga de la gestión del RAID con el controlador localizado en el subsistema externo de los discos. Todo el subsistema está conectado a un host a través de un controlador SCSI normal y se le presenta al host como un solo disco.

Existen también controladores RAID en forma de tarjetas que se comportan como un controlador SCSI con el sistema operativo, pero gestionan todas las comunicaciones reales entre los discos de manera autónoma. En estos casos, basta con conectar los discos a un controlador RAID, como lo haría con un controlador SCSI, pero después puede configurarlo como un controlador RAID sin que el sistema operativo aprecie la diferencia.

4.3.2. Software RAID

El RAID Software implementa los diferentes niveles de RAID en el código del kernel que tienen que ver con la gestión del disco (block device). Ofrece la solución menos costosa ya que no se requieren las tarjetas caras de controladores de disco o chasis hot swap [1]. El software RAID también funciona con discos IDE menos costosos así como con discos SCSI. Con las rápidas CPU de hoy en día, las prestaciones del software RAID software pueden competir con las del hardware RAID.

El controlador MD del kernel de Linux es un ejemplo de que la solución RAID es completamente independiente del hardware. Las prestaciones de un RAID basado en el software dependen del desempeño y de la carga del CPU.

Para aquéllos que estén interesados en saber lo que el software RAID ofrece aquí tiene una breve lista de algunas de sus características más importantes:

  • Proceso de reconstrucción entrelazado.

  • Configuración basada en kernel

  • Portabilidad de RAID entre computadores Linux sin reconstruir.

  • Reconstrucción del array en segundo plano usando recursos no utilizados del sistema.

  • Soporte para discos hot-swappable.

  • Reconocimiento automático de la CPU para disfrutar de algunas de sus optimizaciones.

4.4. Niveles de RAID y Soporte Lineal

RAID soporta varias configuraciones incluyendo los niveles 0, 1, 4, 5 y el soporte lineal. Estos tipos de RAID se definen de la siguiente manera:

  • Nivel 0 — El RAID nivel 0, a menudo llamado "striping" es una técnica orientada al rendimiento de mapeo de datos separados. Esto quiere decir que los datos que son escritos en el array son divididos en líneas y escritos en discos miembros del array. Esto permite un alto rendimiento de E/S con un bajo costo pero no proporciona redundancia. La capacidad de almacenamiento del array de nivel 0 es igual a la capacidad total de los discos miembros en un hardware RAID o a la capacidad total de las particiones miembros en un software RAID.

  • Nivel 1 — El RAID nivel 1, o mirroring se viene utilizando desde hace mucho más tiempo que cualquier otra forma de RAID. El nivel 1 proporciona redundancia escribiendo datos idénticos en cada disco miembro del array, dejando una copia idéntica en cada uno de los discos. El mirroring es muy popular a causa de su simplicidad y el alto nivel de disponibilidad de datos que tiene. El nivel 1 opera con dos o más discos que pueden utilizar una modalidad de acceso paralelo para transferir de manera rápida datos de lectura, pero más comunmente opera de manera independiente para ocuparse de valores altos de transacciones de E/S. El nivel 1 proporciona una alta fiabilidad y mejora el rendimiento de las aplicaciones de lectura de datos pero con un coste relativamente elevado. [2] La capacidad de almacenamiento del nivel l del array es igual a la capacidad de un disco duro espejo en una hardware RAID o la de las particiones espejo en un software RAID.

  • Nivel 4 — El nivel 4 utiliza la paridad [3] concentrado en un solo disco para la protección de los datos. Está más orientado a la transacción de E/S que para la transferencia de archivos grandes. Ya que el disco dedicado a la paridad representa un inherente cuello de botella, el nivel 4 se utiliza raramente sin usar la tecnología write-back caching. A pesar de que el RAID de nivel 4 es una opción en algunos esquemas de reparticionamiento RAID, no es una opción permitida en la instalación RAID Red Hat Enterprise Linux. [4] La capacidad del nivel 4 del hardware RAID equivale a la de los discos miembros menos la capacidad de un disco miembro. La capacidad de alamacenamiento del nivel 4 del software RAID equivale a la capacidad de las particiones miembros menos el tamaño de una de las particiones si éstas son del mismo tamaño.

  • Nivel 5 — Es el tipo más común de RAID. Distribuyendo la paridad entre algunos o todos los discos miembros, el RAID nivel 5 elimina el cuello de botella inherente al nivel 4. El único cuello de botella es el proceso del cálculo de la paridad. Con las modernas CPU y el software RAID esto no representa un gran problema. Como con el nivel 4, el resultado es un rendimiento muy elevado, con lecturas sustancialmente más rápidas que las escrituras. El nivel 5 se utiliza a menudo con el write-back caching para reducir la asimetría. La capacidad de alamacenamiento del hardware RAID nivel 5 equivale a la de los discos miembros menos la capacidad de un disco miembro. La capacidad de archivo del software RAID nivel 5 equivale a la capacidad de las particiones miembro, menos el tamaño de una de las particiones si éstas son del mismo tamaño.

  • RAID lineal — El RAID lineal es una simple agrupación de discos de manera que se crea un disco virtual más grande. En el RAID lineal, las partes están dispuestas secuencialmente y se pasa de un disco miembro al disco siguiente una vez que el primer disco ha sido completado en su totalidad. Este agrupamiento no tiene ninguna ventaja en cuanto a rendimiento pues es improbable que alguna operación de E/S sea divida entre los discos miembros. El RAID lineal no ofrece redundancia y de hecho disminuye la fiabilidad -- si uno de los discos se daña, no se puede utilizar el array. La capacidad es el total de todos los discos miembros.

4.5. Configuración de Software RAID

El Software RAID puede configurarse durante el proceso de instalación gráfica, el proceso de instalación basada en texto o durante una instalación de inicio rápido (kickstart). Este capítulo discute como configurar el software RAID durante la instalación usando la aplicación Disk Druid.

  • Aplique particiones de software RAID a los discos duros físicos.

    Para añadir una partición boot (/boot/) a una partición RAID asegúrese de que se encuentra en una partición RAID1.

  • Creación de dispositivos RAID desde las particiones del software RAID.

  • Opcional: Configuración LVM de los dispositivos RAID.

  • Creación de sistemas de archivos desde los dispositivos RAID.

Nota

Aunque este procedimiento cubre la instalación con una aplicación GUI, los administradores del sistema pueden hacer lo mismo con una instalación basado en texto.

La configuración del software RAID se deber eralizar manualmente en Disk Druid durante el proceso de instalación.

Estos ejemplos utilizan dos controladores SCSI 9.1 GB SCSI (/dev/sda y /dev/sdb) para ilustrar la creación de las configuraciones simples de RAID1. Detallan como crear una configuración RAID 1 simple implementando múltiples dispositivos RAID.

En la pantalla Configuración de la partición del disco, seleccione Partición manual con Disk Druid.

4.5.1. Creación de Particiones RAID

En una situación típica los controladores de disco son nuevos o se encuentran formateados. Ambos controladores aparecen como dispositivos sin ninguna configuración de partición en Figura 4.1, “Dos Controladores en Blanco Listos para Configuración”.

Dos Controladores en Blanco Listos para Configuración

Dos Controladores en Blanco Listos para la Configuración

Figura 4.1. Dos Controladores en Blanco Listos para Configuración

  1. En Disk Druid seleccione RAID para ingresar la pantalla de creación de software RAID.

  2. Seleccione Crear una partición de software RAID para crear una partición RAID como se muestra en Figura 4.2, “Opciones de Particiones RAID”. Observe que no se encuentran disponibles otras opciones RAID hasta que se creen las particiones RAID así como los dispositivos RAID.

    Opciones de Particiones RAID

    Opciones de Particiones RAID

    Figura 4.2. Opciones de Particiones RAID

  3. Una partición de software RAID debería estar limitada a una unidad. Para las Unidades admisibles seleccione la unidad donde quiere crear RAID. Si tiene varias unidades, por defecto se seleccionaran todas y usted deberá anular la selección de las unidades que no quiere.

    Añadir una Partición RAID

    Añadir una Partición RAID

    Figura 4.3. Añadir una Partición RAID

  4. Introduzca el tamaño que desea para la partición.

  5. Seleccione Tamaño fijo para hacer la partición de un tamaño especifico, seleccione Ocupar todo el espacio hasta (MB) e introduzca un tamaño en MBs para especificar el rango del tamaño de la partición. Seleccione Ocupar todo el espacio disponible para hacerlo crecer hasta ocupar todo el tamaño disponible en el disco duro. Si hace crecer a más de una partición, éstas compartirán el espacio libre disponible en el disco.

  6. Seleccione Forzar para que sea una partición primaria si quiere que la partición sea primaria. Una partición primaria es una de las cuatro primeras particiones en el disco duro. Si no es seleccionada, la partición es creada como una partición lógica. Debería considerar el dejarla no seleccionada si ya cuenta con otros sistemas operativos en el sistema. Para obtener mayor información sobre particiones primarias vs. lógicas/estendidas consulte el apéndice del Manual de Instalación de Red Hat Enterprise Linux.

  7. Repita estos pasos para crear tantas particiones como necesite para sus particiones.

Repita estos pasos para crear tantas particiones como necesita para su configuración RAID. Tenga en cuenta que no todas las particiones tienen que ser RAID. Por ejemplo, puede configurar tan sólo la partición /boot/ como un dispositivo RAID por software, dejando la partición root (/), /home/ y cambiando como los sistemas de archivos comunes. Figura 4.4, “Particiones Listas RAID 1, Pre-Dispositivo y Creación de Puntos de Montaje” muestra el espacio asignado exitosamente para la configuración RAID1 (para /boot/), la cual ahora se encuentra lista para la creación de un dispoditivos RAID y un punto de montaje.

Particiones Listas RAID 1, Pre-Dispositivo y Creación de Puntos de Montaje

Particiones Listas RAID 1, Pre-Dispositivo y Creación de Puntos de Montaje

Figura 4.4. Particiones Listas RAID 1, Pre-Dispositivo y Creación de Puntos de Montaje

4.5.2. Creación de Dispositivos RAID y Puntos de Montaje

Una vez que haya creado todas sus particiones como particiones software RAID debe crear el dispositivo RAID y el punto de montaje.

  1. Seleccione el botón RAID en la pantalla principal de particionamiento de Disk Druid (vea la Figura 4.5, “Opciones RAID”).

  2. Figura 4.5, “Opciones RAID” aparecerá. Seleccione Crear un dispositivo RAID.

    Opciones RAID

    Opción Seleccionar RAID

    Figura 4.5. Opciones RAID

  3. A continuación, aparecerá la Figura 4.6, “Creación de un Dispositivo RAID y Asignación a un Punto de Montaje” donde puede crear un dispositivo RAID y asignar un punto de montaje.

    Creación de un Dispositivo RAID y Asignación a un Punto de Montaje

    Creación de un Dispositivo RAID y Asignación a un Punto de Montaje

    Figura 4.6. Creación de un Dispositivo RAID y Asignación a un Punto de Montaje

  4. Seleccione un punto de montaje.

  5. SEleccione el tipo de sistema de archivps para la partición. En este momento puede configurar un sistema de archivos LVM o un sistema de archivos ext2/ext3 estático tradicional. Para obtener mayor información sobre como configurar LVM sobre un dispositivo RAID seleccione Volúmen Físico (LVM). Si no necesita LVM continue con las siguientes instrucciones.

  6. Seleccione un nombre de dispositivo tal como md0 para el dispositivo RAID.

  7. Escoja el nivel de RAID. Puede elegir entre RAID 0, RAID 1 y RAID 5.

    Nota

    Si está creando una partición RAID de /boot/ deberá elegir RAID de nivel 1 y debería utilizar una de las primeras dos unidades (IDE primero, SCSI segundo). Si no está creando una partición RAID de /boot/ pero quiere crear una partición RAID del sistema de archivos root (/) deberá ser de tipo RAID nivel 1 y debería estar situada en una de las primeras dos unidades (IDE primero, SCSI de segundo).

    El Error de Montaje /boot/

    El Error de Montaje /boot/

    Figura 4.7. El Error de Montaje /boot/

  8. Las particiones RAID que acaba de crear aparecerán en la lista Miembros RAID. Seleccione cuáles de estas particiones se deben utilizar para crear el dispositivo RAID.

  9. Si está configurando RAID 1 o RAID 5, especifique el número de particiones de reserva. Si una partición de software RAID falla, la de reserva se usará automáticamente como reemplazo. Para cada partición de reserva que desee especificar, deberá crear una partición de software RAID adicional (además de las particiones para el dispositivo RAID). Seleccione las particiones para el dispositivo RAID y la(s) particion(es) de reserva.

  10. Después de hacer click en OK el dispositivos RAID aparece en la lista Resumen de Discos.

  11. Repita el proceso completo explicado en este capítulo para configurar particiones, dispositivos y puntos de montaje adicionales tal como la partición root (/), /home/ o swap.

Después de completar toda la configuración, la figura que se muestra en Figura 4.8, “Configuración Final de Ejemplo de RAID” se parece a la configuración predeterminada a excepción del uso de RAID.

Configuración Final de Ejemplo de RAID

Configuración Final de Ejemplo de RAID

Figura 4.8. Configuración Final de Ejemplo de RAID

La figura que se muestra en Figura 4.9, “Configuración Final de Ejemplo de RAID con LVM” es un ejemplo de una configuración RAID y LVM.

Configuración Final de Ejemplo de RAID con LVM

Configuración Final de Ejemplo de RAID con LVM

Figura 4.9. Configuración Final de Ejemplo de RAID con LVM

Puede continuar con el proceso de instalación. Consulte el Manual de Instalación de Red Hat Enterprise Linux para obtener mayores instrucciones.



[1] Un chasis hot-swap le permite eliminar un disco rígido sin tener que apagar el sistema

[2] El RAID nivel 1 tiene un alto costo ya que escribe la misma información en todos los discos del array malgastando de este modo el espacio del disco. Por ejemplo, si ha configurado el RAID nivel 1 de manera que su partición (/) (root) se expanda a través de dos discos de 40G. Tiene un total de 80G pero sólo puede acceder a 40 de los 80G. Los otros 40G se comportan como un espejo de los primeros 40G.

[3] La información sobre la paridad es calculada con base en el contenido del resto de los discos miembros del array. Esta información puede ser utilizada para la reconstrucción de datos cuando uno de los discos del array se daña. Los datos reconstruidos se pueden utilizar para satisfacer las peticiones de E/S del disco que ha fallado y para volver a escribir ese disco después de haber sido reparado o sustituido.

[4] El nivel 4 tiene la misma cantidad de espacio que el nivel 5, pero este último ofrece más ventajas y es por esta razón que no se soporta el nivel 4.

Capítulo 5. Espacio Swap

5.1. ¿Qué es el espacio Swap?

Se utiliza el espacio swap en Linux cuando la cantidad de memoria física (RAM) está llena. Si el sistema necesita más recursos de memoria y la memoria física está llena, las páginas inactivas de la memoria se mueven al espacio swap. Mientras que el espacio swap puede ser de ayuda para las máquinas con poca memoria RAM, no debería considerarse como algo que pueda sustituir a más RAM. El espacio swap se encuentra en los discos duros, los cuales tienen un tiempo de acceso más lento que la memoria física.

El espacio Swap puede ser una partición swap dedicada (recomendable), un archivo swap o una combinación de particiones y archivos swap.

El swap debe ser equivalente a 2X memorias físicas RAM para hasta 2 GB de memoria física RAM y después 1x memoria física RAM adicional por cualquier cantidad por encima de 2 GB pero nunca menos de 32 MB.

Así que si:

M = Cantidad de RAM en GB y S = Cantidad de swap en GB entonces

If M < 2
        S = M *2
Else
        S = M + 2

Utilizando esta fómula un sistema de 2 GB de memoria física RAM tendrían 4 GB de swap, mientras que una com 3 GB de memoria física RAM tendrían 5 GB de swap. El crear una partición de espacio swap grande puede ser bastante útil si planea modernizar su RAM en un futuro.

Para sistemas con cantidades realmente grandes de RAM (más de 32 GB) probablemente podrá salirse con las suyas con una partición swap más pequeña (alrededor de 1x o menos de emoria física RAM).

Importante

Los sistemas de archivos y volúmenes LVM2 asignados como espacio swap nose pueden encontrar en uso cuando están siendo modificados. Por ejemplo, al espacio swap no se le puede asignar procesos del sistema y el kernel tampoco debe asignar o utilizar cantidades de swap. Utilice los comandos free y cat /proc/swaps para verificar cuanto y donde se utiliza swap.

La mejor manera para lograr modificaciones de espacio swap es arrancar el sistema en modo de rescate y luego seguir las instrucciones (para cada escenario) en lo que queda de este capítulo. Consulte el Manual de Instalación de Red Hat Enterprise Linux para obtener instrucciones sobre cómo arrancar en modo rescate. Cuando se le pida que monte el sistema de archivos seleccione Saltar.

5.2. Añadir el espacio Swap

A veces es necesario añadir más espacio swap después de la instalación. Por ejemplo, puede actualizar la cantidad de RAM en su sistema de 128 MB a 256 pero hay tan sólo 256 MB de espacio swap. Sería conveniente aumentar la cantidad de espacio swap hasta 512 MB sobre todo si lleva a cabo operaciones de uso intensivo de memoria o si ejecuta aplicaciones que requieran gran cantidad de memoria.

Tiene tres opciones: crear una nueva partición swap, creae un nuevo archivo swap o extender swap en un volúmen lógico LVM2 ya existente. Se recomeinda que extienda un volúmen lógico ya existente.

5.2.1. Extensión de Swap en un Volumen Lógico LVM2

Para extender un volumen lógico swap LVM2 ( asumiendo que /dev/VolGroup00/LogVol01 es el volumen que quiere extender):

  1. Desactivar sawpping para el volumen lógico asociado:

    # swapoff -v /dev/VolGroup00/LogVol01
    
  2. Modificar el tamaño del volumen lógico LVM2 a 256 MB:

    # lvm lvresize /dev/VolGroup00/LogVol01 -L +256M
    
  3. Formatear el nuevo espacio swap:

    # mkswap /dev/VolGroup00/LogVol01
    
  4. Activar el volumen logico extendido:

    # swapon -va
    
  5. Probar que el volumen logico ha sido extendido apropiadamente:

    # cat /proc/swaps # free
    

5.2.2. Creación de un Volumen Lógico LVM2 para Swap

Para añadir un grupo de volumen swap ( asumiendo que /dev/VolGroup00/LogVol02 es el volumen swap que quiere añadir):

  1. Crear el volumen lógico LVM2 de tamaño 256 MB:

    # lvm lvcreate VolGroup00 -n LogVol02 -L 256M
    
  2. Formatear el nuevo espacio swap:

    # mkswap /dev/VolGroup00/LogVol02
    
  3. Añada la siguiente entrada al archivo /etc/fstab:

    /dev/VolGroup00/LogVol02 swap swap defaults 0 0
    
  4. Activar el volumen logico extendido:

    # swapon -va
    
  5. Probar que el volumen logico ha sido extendido apropiadamente:

    # cat /proc/swaps # free
    

5.2.3. Creación de un Archivo Swap

Para añadir un archivo swap:

  1. Determine el tamaño en megabytes del nuevo archivo swap y multipliquelo por 1024 para determinar el número de bloques. Por ejemplo, el tamaño de bloque de un archivo swap de 64 MB es 65536.

  2. En un indicador de comandos shell como root, escriba el siguiente comando con count lo que equivale al tamaño de bloque deseado:

    dd if=/dev/zero of=/swapfile bs=1024 count=65536
    
  3. Configure el archivo swap con el comando:

    mkswap /swapfile
    
  4. Para activar el archivo swap inmediatamente pero no automáticamente cuando se arranca:

    swapon /swapfile
    
  5. Para activarlo al momento del arranque edite /etc/fstab para incluir la siguiente entrada:

    /swapfile swap swap defaults 0 0
    

    La próxima vez que se arranque el sistema, se activará el nuevo archivo swap.

  6. Después de haber añadido el nuevo archivo swap y de haberlo activado, asegúrese de que está activado visualizando el resultado del comando cat /proc/swaps o con el comando free.

5.3. Eliminar el espacio Swap

A veces es prundente reducir el espacio swap después de la instalación. Por ejemplo, digamos que redujo la cantidad de RAM en su sistema de 1GB a 512 MB pero aún hay 2 GB de espacio swap por asignar. Puede llegar a ser una ventaja el reducir la cantidad de espacio swap a 1 GB debido a que el de 2 GB puede estar desperdiciando espacio de disco.

Tiene tres opciones: eliminar por completo un volumen lógico LVM2 utilizado por swap, eliminar un archivo swap o reducir el espacio swap en un volumen lógico LVM2 ya existente.

5.3.1. Reducción de Swap en un Volumen Lógico LVM2

Para reducir un volumen lógico swap LVM2 ( asumiendo que /dev/VolGroup00/LogVol01 es el volumen que quiere extender):

  1. Desactivar sawpping para el volumen lógico asociado:

    # swapoff -v /dev/VolGroup00/LogVol01
    
  2. Reducir el volumen lógico LVM2 a 512MB:

    # lvm lvreduce /dev/VolGroup00/LogVol01 -L -512M
    
  3. Formatear el nuevo espacio swap:

    # mkswap /dev/VolGroup00/LogVol01
    
  4. Activar el volumen logico extendido:

    # swapon -va
    
  5. Probar que el volumen lógico has sido reducido apropiadamente:

    # cat /proc/swaps # free
    

5.3.2. Eliminación de un Volumen Lógico LVM2 por Swap

The swap logical volume cannot be in use (no system locks or processes on the volume). The easiest way to achieve this it to boot your system in rescue mode. Refer to for instructions on booting into rescue mode. When prompted to mount the file system, select Skip.

Para eliminar un grupo de volúmenes lógicos ( asumiendo que /dev/VolGroup00/LogVol02 es el volumen swap que quiere eliminar):

  1. Desactivar sawpping para el volumen lógico asociado:

    # swapoff -v /dev/VolGroup00/LogVol02
    
  2. Elimine el volumen lógico LVM2 de tamaño 512 MB:

    # lvm lvremove /dev/VolGroup00/LogVol02
    
  3. Elimine la siguiente entrada desde el archivo /etc/fstab:

    /dev/VolGroup00/LogVol02 swap swap defaults 0 0
    
  4. Probar que el volumen logico ha sido extendido apropiadamente:

    # cat /proc/swaps # free
    

5.3.3. Eliminar el Archivo Swap

Para eliminar un archivo swap:

  1. En un indicador de comandos shell como usuario root, ejecute el comando siguiente para desactivar el archivo swap (donde /swapfile es el archivo swap):

    # swapoff -v /swapfile
    
  2. Elimine su entrada del archivo /etc/fstab.

  3. Elimine el archivo actual:

    # rm /swapfile
    

5.4. Mover el espacio Swap

Para mover el espacio swap de un emplazamiento a otro, siga los pasos para eliminar el espacio swap y a continuación los pasos para añadir el espacio swap.

Capítulo 6. Gestión del almacenamiento en disco

6.1. Particiones Estándares utilizando parted

La utilidad parted permite a los usuarios:

  • Ver la tabla de particiones existentes

  • Redimensionar la partición existentes

  • Añadir las particiones del espacio libre o de los discos duros adicionales

Por defecto, el paquete parted se encuentra incluido cuando instala Red Hat Enterprise Linux. Para iniciar parted inicie sesión como root y escriba el comando parted /dev/sda en un intérprete de comandos del shell (en donde /dev/sda es el nombre del dispositivo para el disco duro que quiere configurar).

Un dispositivoque tiene una partición no se debe encontrar en uso si dicha partición se va a eliminar o a redimensionar. De manera similar, al crear una partición en un dispositivo dicho dispositivo no debe estar en uso.

Para que un dispositivo no se encuentre en uso, ninguna de las particiones en el dispositivo pueden ser montadas y cualquier espacio swap en el dispositivo no debe ser activado.

De igual manera, la tabla de particiones no debe ser modificada mientras que se encuentra en uso ya que puede que el kernel no reconozca apropiadamente los cambios. Si la tabla de particiones no coincide con el estado actual de las particiones montadas, se puede llegar a escribir información en la partición equivocada lo cual causa la perdida o sobreescritura de datos.

La manera más fácil de conseguir esto es arrancar el sistema en modo de rescate. Cuando se le pida que monte el sistema de archivos seleccione Skip.

Por otro lado, si la unidad no contiene ninguna partición en uso (los procesos del sistema que utilizan o bloquean el sistema de archivos para que no se desmonten) puede desmontarlas con el comando umount y desactivar todo el espacio swap del disco duro con el comando swapoff.

Tabla 6.1, “parted commands” La Tabla 6.1, “parted commands” contiene una lista de los comandos parted más utilizados. Las siguientes secciones explican algunos de estos comandos en más detalle.

Comando Descripción
check minor-num Ejecuta un chequeo sencillo del sistema de archivos
cp desdea Copiar un sistema de archivos desde una partición a otra; desde y hasta son los números 'minor' de las particiones
help Muestra una lista de los comandos disponibles
mklabel label Crea una etiqueta de disco para la tabla de particiones
mkfs numero-minortipo-de-sistema-de-archivos Crea un sistema de archivos del tipo tipo-de-sistema-de-archivos
mkpart tipo-particiontipo-sastart-mbend-mb Crea una partición sin crear un nuevo sistema de archivos
mkpartfs tipo-particiontipo-sastart-mbend-mb Crea una partición y crea un nuevo sistema de archivos
move numero-minorstart-mbend-mb Mueve la partición
name minor-numname Nombra la partición para etiquetas de discos Mac y PC98 solamente
print Visualiza la tabla de particiones
quit Sale de parted
rescuestart-mbend-mb Rescata una particion perdida desde start-mb a end-mb
resize numero-minorstart-mbend-mb Redimensiona la partición desde start-mb a end-mb
rm numero-minor Elimina la partición
select dispositivo Selecciona un dispositivo diferente a configurar
set numero-minorbanderaestado Coloca una bandera a la partición; estado es 'on' o 'off'
toggle [NUMBER [FLAG] Cambia el estado de BANDERA en la partición NUMERO
unidad UNIDAD Configura la unidad predeterminada a UNIDAD
Tabla 6.1. parted commands

6.1.1. Visualizar la tabla de particiones

Después de iniciar parted escriba el comando print para visualizar la tabla de particiones. Aparecerá una tabla similar a la siguiente:

Model: ATA ST3160812AS (scsi)
Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size    Type      File system  Flags
 1      32.3kB  107MB  107MB   primary   ext3         boot
 2      107MB   105GB  105GB   primary   ext3
 3      105GB   107GB  2147MB  primary   linux-swap
 4      107GB   160GB  52.9GB  extended                      root
 5      107GB   133GB  26.2GB  logical   ext3
 6      133GB   133GB  107MB   logical   ext3
 7      133GB   160GB  26.6GB  logical                lvm

La primera línea contiene el tipo de disco, el fabricante, el número del modelo y la interfaz y la segunda línea presenta el tipo de etiqueta del disco. La salida restante después de la cuarta línea muestra la tabla de particiones.

En la tabla de particiones el número Minor el es number de la partición. Por ejemplo, la partición con el número minor 1 corresponde a /dev/sda1. Los valores Start y End se encuentran en megabytes. Type válidos son metadatos, libres, primarios, extendidos o lógicos. El Filesystem es el tipo del sistema de archivos, el cual puede ser uno de los siguientes:

  • ext2

  • ext3

  • fat16

  • fat32

  • hfs

  • jfs

  • linux-swap

  • ntfs

  • reiserfs

  • hp-ufs

  • sun-ufs

  • xfs

Si un Filesystem de un dispositivo no muestra ningún valor esto significa que desconoce el tipo de sistema de archivos.

La columna Flags enumera las banderas establecidaspara la partición. Las banderas disponibles son boot, root, swap, hidden, raid, lvm, o lba.

Sugerencia

Para seleccionar un dispositivo diferente sin tener que reiniciar parted use el comando select seguido del nombre del dispositivo ( por ejemplo, /dev/sda). Esto le permitirá ver o configurar la tabla de partición de un dispositivo.

6.1.2. Creación de una partición

Aviso

No intente crear una partición en un dispositivo que se encuentre en uso.

Antes de crear una partición, arranque en modo de rescate (o desmonte cualquier partición en el dispositivo y elimine cualquier espacio swap).

Inicie parted, en donde /dev/sda es el dispositivo en el cual se creará la partición:

parted /dev/sda

Visualice la tabla de particiones actual para determinar si hay suficiente espacio libre:

print

Si no hay suficiente espacio libre puede redimensionar una partición existente. Consulte Sección 6.1.4, “Redimensionar una partición” para obtener más detalles.

6.1.2.1. Crear la partición

Desde la tabla de particiones determine los puntos de comienzo y fin de la nueva partición y qué tipo de partición debe ser. Puede tener solamente cuatro particiones primarias (sin partición extendida) en un dispositivo. Si necesita más de cuatro particiones puede tener tres particiones primarias, una partición extendida y varias particiones lógicas dentro de la extendida. Para obtener una sinopsis de las particiones de disco consulte el apéndice Introducción a la Creación de Particiones de Disco en el Manual de Instalación de Red Hat Enterprise Linux.

Por ejemplo, para crear una partición primaria con un sistema de archivos ext3 desde 1024 megabytes hasta 2048 megabytes en un disco duro, escriba el siguiente comando:

mkpart primary ext3 1024 2048

Sugerencia

Si en cambio usa el comando mkpartfs, el sistema de archivos se creará después de que se haya creado la partición. Sin embargo, parted no soporta crear un sistema de archivos ext3. Por ello, si desea crear un sistema de archivos ext3 use mkpart y cree el sistema de archivos con el comando mkfs como se describe a continuación.

Los cambios se harán efectivos tan pronto como presione Intro, por tanto revise bien el comando antes de ejecutarlo.

Después de crear la partición, use el comando print para confirmar que está en la tabla de particiones con el tipo de partición, tipo de sistema de archivos y tamaño correctos. Recuerde también el número minor de la nueva partición, de modo que pueda etiquetarla. También debería visualizar la salida de

cat /proc/partitions

para asegurarse de que el kernel reconoce la nueva partición.

6.1.2.2. Formatear la partición

La partición no tiene todavía un sistema de archivos. Cree el sistema de archivos:

/sbin/mkfs -t ext3 /dev/sda6

Aviso

Al formatear la partición se destruirán permanentemente los datos que existan en la partición.

6.1.2.3. Etiquetar la partición

A continuación dele una etiqueta a la partición. Por ejemplo, si la nueva partición es /dev/sda6 y quiere etiquetarla /work:

e2label /dev/sda6 /work

Por defecto, el programa de instalación utiliza el punto de montaje de la partición como la etiqueta para asegurarse de que la etiqueta es única. Puede utilizar cualquier etiqueta que desee.

6.1.2.4. Crear un punto de montaje

Como usuario root, cree un punto de montaje:

mkdir /work

6.1.2.5. Añadir /etc/fstab

Como root, edite el archivo /etc/fstab para incluir la nueva partición. La nueva línea debe ser parecida a la siguiente:

LABEL=/work /work ext3 defaults 1 2

La primera columna debe contener LABEL= seguida de la etiqueta que usted dió a la partición. La segunda columna debe contener el punto de montaje para la nueva partición y la columna siguiente debería ser el tipo de sistema de archivo (por ejemplo, ext3 o swap). Si necesita más información sobre el formato, lea la página man con el comando man fstab.

Si la cuarta columna es la palabra defaults, la partición se montará en el momento de arranque. Para montar la partición sin arrancar de nuevo, como root, escriba el comando:

mount /work

6.1.3. Eliminar una partición

Aviso

No intente eliminar una partición en un dispositivo que se encuentre en uso.

Antes de eliminar una partición, arranque en modo de rescate (o desmonte cualquier partición en el dispositivo y elimine cualquier espacio swap).

Inicie parted, en donde /dev/sda es el dispositivo en el cual se eliminará la partición:

parted /dev/sda

Visualice la tabla de particiones actual para determinar el número minor de la partición que se quiere eliminar:

print

Elimine la partición con el comando rm. Por ejemplo, para eliminar la partición con un número minor 3:

rm 3

Los cambios comienzan a efectuarse en el momento en que usted presiona Intro, así que revise el comando antes de ejecutarlo.

Luego de eliminar la partición, use el comando print para confirmar que se ha eliminado de la tabla de particiones. Debería también visualizar la salida de datos de

cat /proc/partitions

para asegurarse de que el kernel sabe que la partición se ha eliminado.

El último paso es eliminarla del archivo /etc/fstab. Encuentre la línea que dice que la partición ha sido borrada y bórrela del archivo.

6.1.4. Redimensionar una partición

Aviso

No intente cambiar el tamaño de una partición en un dispositivo que se encuentra en uso.

Antes de cambiar el tamaño a una partición, arranque en modo de rescate (o desmonte cualquier partición en el dispositivo y elimine cualquier espacio swap en el dispositivo).

Inicie parted, en donde /dev/sda es el dispositivo en el cual se redimensiona la partición:

parted /dev/sda

Visualice la tabla de particiones actual para determinar el número minor de la partición que se quiere redimensionar, así como los puntos de comienzo y fin para la partición:

print

Para redimensionar la partición, use el comando resize seguido del número minor de la partición, el lugar comienzo y fin en megabytes. Por ejemplo:

resize 3 1024 2048

Aviso

Una partición no puede agrandarse más alla del espacio disponible en el dispositivo

Después de cambiar el tamaño a la partición, use el comando print para confirmar que se ha cambiado el tamaño de la partición correctamente, que es el tipo de partición y de sistema de archivos correcto.

Después de reiniciar el sistema el modo normal, use el comando df para asegurarse que la partición fué montada y que es reconocida con el nuevo tamaño.

6.2. Administración de la Partición LVM

Los siguientes comandos se pueden encontrar al escribir lvm help en un intérprete de comandos.

Comando Descripción
dumpconfig Vuelque la configuración activa
formatos Enumere los formatos de metadatos disponibles
help Muestra los comandos de ayuda
lvchange Cambia los atributos de volumen(es) lógicos
lvcreate Crea un volumen lógico
lvdisplay Presenta información sobre un volumen lógico
lvextend Añade espacio a un volumen lógico
lvmchange Debido al uso del mapeador de dispositivos, este comando ha sido descontinuado
lvmdiskscan Enumera dispositivos que se pueden utilizar como volúmenes físicos
lvmsadc Recopilar datos sobre actividad
lvmsar Crear un informe sobre actividad
lvreduce Reducir el tamaño de un volumen lógico
lvremove Eliminar volumen(es) lógicos del sistema
lvrename Renombrar un volúmen lógico
lvresize Redimensionar un volumen lógico
lvs Presentar información sobre volúmenes lógicos
lvscan Enumerar todos los volúmenes lógicos en todos los grupos de volúmenes lógicos
pvchange Cambiar los atributos de los volúmenes físicos
pvcreate Inicializar los volúmenes físicos para que LVM los utilice
pvdata Presenta los metadatos en disco para los volúmenes físicos
pvdisplay Presenta varios atributos de los volúmenes físicos
pvmove Move extiende desde un volumen físico a otro.
pvremove Elimina etiquetas LVM de los volúmenes físicos
pvresize Redimensionar un volumen físico en usar por el grupo de volumen.
pvs Presenta información sobre volúmenes físicos
pvscan Enumera todos los volúmenes físicos
segtypes Enumera los tipos de segmentos disponibles
vgcfgbackup Copia de seguridad de la configuración del grupos de volúmenes
vgcfgrestore Restaura la configuración del grupo de volúmenes
vgchange Cambia los atributos del grupo de volúmenes
vgck Verifica la consistencia de un grupo de volúmenes
vgconvert Cambia el formato de metadatos del grupo de volúmenes
vgcreate Crear un grupo de volúmenes
vgdisplay Despliega información sobre el grupo de volúmenes
vgexport Elimina el registro de un grupo de volúmenes del sistema
vgextend Añade volúmenes físicos a un grupo de volúmenes
vgimport Registra un grupo de volúmenes exportado con el sistema
vgmerge Combina grupos de volúmenes
vgmknodes Crea los archivos especiales para dispositivos de grupos de volúmenes en /dev/
vgreduce Elimina un volumen físico de un grupo de volúmenes
vgremove Elimina un grupo de volúmenes
vgrename Renombra un grupo de volúmenes
vgs Presenta información sobre el grupo de volúmenes
vgscan Busca todos los grupos de volúmenes
vgsplit Mueve los volúmenes físicos a un nuevo grupo de volúmenes
version Despliega información sobre la versión del controlador y del software
Tabla 6.2. comandos LVM

Capítulo 7. Implementación de cuotas de disco

El espacio de disco se puede restringir mediante la implementación de cuotas de disco de manera que el administrador es notificado antes de que un usuario consuma demasiado espacio en disco o antes de que una partición se llene.

Las cuotas de disco se pueden configurar para usuarios individuales o para grupos. Este tipo de flexibilidad hace posible darle a cada usuario una pequeña porción del disco para que maneje sus archivos personales (tal como correo electrónico), mientras que se le permite tener más espacio para manejar los proyectos en los que estén trabajando o cuotas más grandes (asumiendo que se les dá sus propios grupos a los proyectos).

Además, se puede configurar las cuotas no sólo para que controlen el número de bloques de disco pero también el número de inodes (estructuras de datos que incluyen información sobre los archivos en los sistemas de archivos UNIX). Debido a que los inodes son usados para contener información relacionada con los archivos, esto permite controlar el número de archivos que se pueden crear.

Para implementar las cuotas de disco debe tener instalado el RPM quota.

Nota

Para obtener mayor información sobre la instalación de los paquetes RPM consulte Parte II, “Administración de paquetes”.

7.1. Configuración de cuotas de disco

Para implementar cuotas de disco, siga los pasos siguientes:

  1. Active cuotas por sistema de archivo modificando /etc/fstab.

  2. Vuelva a montar el sistema de archivos.

  3. Cree los archivos de base de datos de cuota y genere la tabla de uso del espacio en disco.

  4. Asigne las políticas de cuota.

A continuación se describen cada uno de estos pasos en detalle.

7.1.1. Activar cuotas

Como usuario root, use un editor de texto y modifique el archivo /etc/fstab. Añada las opciones usrquota y/o grpquota al sistema de archivos que requiere cuotas:

 /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol02 /home ext3 defaults,usrquota,grpquota 1 2 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 . . . 

En este ejemplo, el sistema de archivos /home tiene cuotas de usuario y grupo ambas activadas.

Nota

Los siguientes ejemplos asumen que se creó una partición separada /home durante la instalación de Red Hat Enterprise Linux. La partición root (/) se puede utilizar para configurar las políticas de cuotas en el archivo /etc/fstab.

7.1.2. Volver a montar un sistema de archivos

Después de agregar las opciones usrquota y/o grpquota, vuelva a montar cada sistema de archivos cuyas entradas fstab hayan sido modificadas. Si el sistema de archivo no está siendo usado por ningún proceso, use uno de los siguientes métodos:

  • Emita el comando umount seguido de mount para volver a montar el sistema de archivos (vea la página del manual man para umount y mount para obtener la sintaxis especifica para montar y desmontar varios tipos de sistemas de archivos).

  • Emita el comando mount -o remount <file-system> (en donde <file-system> es el nombre del sistema de archivos) para volver a montar el sistemas de archivo. Por ejemplo, para volver a montar el sistema de archivos /home debe emitir el comando mount -o remount /home.

Si el sistema de archivos se encuentra en uso, la manera más fácil de volver a montar el sistema de archivos es reiniciar el sistema.

7.1.3. Creación de Archivos de Base de Datos de Cuotas

Después de volver a montar cada sistema de archivos con cuotas, el sistema puede funcionar con cuotas de disco. Sin embargo, el sistema de archivos mismo no está listo para soportar cuotas. El próximo paso es ejecutar el comando quotacheck.

El comando quotacheck examina los sistemas de archivos con cuotas activadas y construye una tabla del uso del disco por sistema de archivo. La tabla es luego usada para actualizar la copia del uso del disco del sistema operativo. Además, los archivos de cuotas de disco del sistema de archivos, son actualizados.

Para crear los archivos de cuotas (aquota.user y aquota.group) en el sistema de archivos, use la opción -c del comando quotacheck. Por ejemplo, si las cuotas del usuario y grupos están activadas para el sistema de archivos /home, cree los archivos en el directorio /home:

quotacheck -cug /home

La opción -c especifica que los archivos de cuota deberían ser creados para cada sistema de archivos con cuotas activadas, la opción -u especifica que se debe verificar por cuotas de usuario, y la opción -g indica verificar por cuotas de grupo.

Si no se especifican ninguna de las opciones -u ni -g, sólo se creará el archivo de cuota de usuario. Si únicamente se especifica la opción -g, sólo se creará el archivo de cuota de grupo.

Después de creados los archivos, ejecute el comando siguiente para generar la tabla del uso actual del disco duro por el sistema de archivos con cuotas activadas:

quotacheck -avug

Las opciones usadas son como se muestra a continuación:

  • a — Verifica todos los sistemas de archivos montados localmente con cuotas activadas

  • v — Muestra detalles informativos a medida que la verificación de cuotas se ejecuta

  • u — Verifica la información de cuota de disco

  • g — Verifica la información de cuota de disco del grupo

Después que quotacheck ha terminado, los archivos de cuotas correspondiente a las cuotas activas (usuario y/o grupos) son poblados con datos para cada sistema de archivos con cuotas activadas tal como /home.

7.1.4. Asignación de cuotas por usuario

El último paso es asignar las cuotas de disco con el comando edquota.

Para configurar la cuota por usuario, como usuario root en el intérprete shell, ejecute el comando:

edquota username

Ejecute este paso para cada usuario que necesita una cuota. Por ejemplo, si una cuota es activada en /etc/fstab para la partición /home (/dev/VolGroup00/LogVol02 en el ejemplo a continuación) y se ejecuta el comando edquota testuser, se mostrará lo siguiente en el editor configurado como predeterminado en su sistema:

 Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/VolGroup00/LogVol02 440436 0 0 37418 0 0 

Nota

El editor de texto definido por la variable de ambiente EDITOR es usado por edquota. Para cambiar el editor, configure la variable de ambiente EDITOR en su archivo ~/.bash_profile a la ruta completa del editor que prefiera.

La primera columna es el nombre del sistema de archivos que tiene una cuota activada. La segunda columna muestra cuántos bloques está usando el usuario actualmente. Las próximas dos columnas son usadas para colocar límites de bloques duros y suaves para el usuario del sistema de archivos. La columna inodes muestra cuántos inodes está usando el usuario actualmente. Las últimas dos columnas son usadas para colocar los límites duros y suaves para los inodes del usuario en el sistema de archivos.

Un límite duro es la cantidad máxima absoluta de espacio en disco que un usuario o grupo puede utilizar. Una vez que se alcance el límite no se puede usar más espacio.

El límite suave define la cantidad máxima de espacio en disco que puede ser utilizado. Sin embargo, a diferencia del límite duro, el límite suave puede ser excedido durante cierto tiempo. Este tiempo es conocido como período de gracia. El período de gracia se puede expresar en segundos, minutos, horas, días, semanas o meses.

Si cualquiera de los valores está especificado a 0, ese límite no está configurado. En el editor de texto, cambie los límites deseados. Por ejemplo:

Disk quotas for user testuser (uid 501): Filesystem blocks soft hard inodes soft hard /dev/VolGroup00/LogVol02 440436 500000 550000 37418 0 0

Para verificar que la cuota para el usuario ha sido configurada, use el comando:

quota testuser

7.1.5. Asignación de cuotas por grupo

Las cuotas también pueden ser asignadas por grupos. Por ejemplo, para configurar una cuota de grupo para el grupo devel use el comando (el grupo debe existir antes de configurar la cuota):

edquota -g devel

Este comando muestra la cuota existente para el grupo en el editor de texto:

 Disk quotas for group devel (gid 505): Filesystem blocks soft hard inodes soft hard /dev/VolGroup00/LogVol02 440400 0 0 37418 0 0 

Modifique los límites y luego guarde el archivo.

Para verificar que la cuota del grupo ha sido definida, use el comando:

quota -g devel

7.1.6. Configuración del Periodo de Gracia de los Límites Suaves

Si se configuran límites suaves para una cuota dada (ya sea inode o bloque y para usuarios o grupos) el periodo de gracia o la cantidad de tiempo que un límite suave se puede exceder debe configurarse con el comando:

edquota -t

Mientras que otros comandos edquota en una cuota de grupo o usuario en particular, la opción -t opera en todo sistema de archivos con cuatoas activadas.

7.2. Administración de cuotas de disco

Si se implementan las cuotas, estas necesitan mantenimiento — en gran parte en la manera en que observan si las cuotas son excedidas y asegurándose de que las cuotas son acertadas.

Por supuesto, si los usuarios repetidamente superan sus cuotas o regularmente alcanzan el límite suave, el administrador tiene algunas decisiones que tomar dependiendo del tipo de usuario y el impacto del espacio en disco en el trabajo del mismo. El administrador puede ayudar al usuario a que administre mejor su espacio o incrementar la cuota de disco, si se necesita.

7.2.1. Activación y desactivación de cuotas

Es posible desactivar cuotas sin tener que colocarlas en 0. Para desactivar todos los usuarios y grupos, use el siguiente comando:

quotaoff -vaug

Si ninguna de las opciones -u o -g son especificadas, solamente se desactivarán las cuotas de usuarios. Si únicamente se especifica -g, sólo se desactivarán las cuotas de grupo. El interruptor -v hace que aparezca información sobre el estatus verboso mientras se ejecuta el comando.

Para activar las cuotas nuevamente, use el comando quotaon con las mismas opciones.

Por ejemplo, para activar las cuotas de usuarios y grupos para todos los sistemas de archivos, utilice el siguiente comando:

quotaon -vaug

Para activar cuotas para un sistema de archivos específico tal como /home, utilice el siguiente comando:

quotaon -vug /home

Si no se especifican ninguna de las opciones -u ni tampoco -g, sólo se activarán las cuotas de usuarios. Si sólo se escribe la opción -g, únicamente las cuotas de grupo serán activadas.

7.2.2. Informes de cuotas de disco

Para crear un informe del uso del disco debe usar la utilidad repquota. Por ejemplo, el comando repquota /home produce la siguiente salida:

*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 36 0 0 4 0 0 kristin -- 540 0 0 125 0 0 testuser -- 440400 500000 550000 37418 0 0

Para ver el informe sobre el uso del disco por parte de todos los sistemas de archivos con cuotas (opción -a), use el siguiente comando:

repquota -a

Aún cuando el informe es fácil de leer, es importante resaltar algunos puntos. La marca -- mostrada luego de cada usuario es una forma rápida de determinar si los límites del bloque o inode han sido excedidos. Si el límite suave es excedido aparecerá un símbolo + en lugar del correspondiente -; el primer - representa el límite del bloque, y el segundo el límite del inode.

La columna grace está normalmente en blanco. Si se ha excedido el límite suave, la columna contiene una especificación de tiempo igual al tiempo restante en el período de gracia. Si el período de gracia ha expirado, aparecerá none en su lugar.

7.2.3. Mantenimiento de la precisión de las cuotas

Cada vez que el sistema de archivos se desmonta de forma inadecuada (debido a una falla del sistema, por ejemplo), es necesario ejecutar quotacheck. Sin embargo, quotacheck puede ser ejecutado de manera regular aún cuando el sistema no haya fallado. Mediante la ejecución regular de este comando se ayuda a mantener la exactitud de las cuotas (las opciones usadas son descritas en la Sección 7.1.1, “Activar cuotas”):

quotacheck -avug

La forma más fácil de ejecutar esto periódicamente es usando cron. Como root, puede bien sea usar el comando crontab -e para planificar un quotacheck periódicamente, o colocar un script que ejecute quotacheck en cualquiera de los directorios siguientes (usando el intervalo que más le convenga):

  • /etc/cron.hourly

  • /etc/cron.daily

  • /etc/cron.weekly

  • /etc/cron.monthly

Las estadísticas de cuotas más exactas pueden se obtenidas cuando el sistema de archivos analizado no está en uso activo. Por tanto, la tarea cron debería ser planificada cuando se esté usando lo menos posible el sistema de archivos. Si esta hora varía para diferentes sistemas de archivos con cuotas, ejecute quotacheck para cada sistema de archivos en las diferentes horas mediante múltiples tareas cron.

Consulte el Capítulo 35, Tareas automáticas para obtener más información sobre la configuración de cron.

7.3. Recursos adicionales

Para más información sobre cuotas de disco, consulte los siguientes recursos.

7.3.1. Documentación instalada

  • Las páginas de manual de quotacheck, edquota, repquota, quota, quotaon, y quotaoff

7.3.2. Libros relacionados

  • Introducción a la Administración de Sistemas de Red Hat Enterprise Linux; Red Hat, Inc. — Disponible en http://www.redhat.com/docs/ y en el CD de Documentación, este manual contiene información de fondo sobre la administración del almacenamiento (incluyendo cuotas) para nuevos administradores de sistemas Red Hat Enterprise Linux .

Capítulo 8. Listas de Control de Acceso

Los archivos y directorios tienen conjuntos de permisos configurados para el propietario del archivo, el grupo asociado con el archivo y todos los otros usuarios del sistema. Sin embargo, estos permisos tienen sus limitaciones. Por ejemplo, no se pueden configurar diferentes permisos para usuarios diferentes. Por ello, se implementaron las Listas de Control de Acceso (ACLs - Access Control Lists).

El kernel de Red Hat Enterprise Linux 5 proporciona soporte para ACL para el sistema de archivos ext3 y los sistemas de archivos con exportaciones NFS. También se reconocen las ACLs en sistemas de archivos ext3 accedidos a través de Samba.

Se requiere el paquete acl para implementar ACLs junto con el soporte en el kernel. Este contiene utilidades usadas para añadir, modificar, eliminar y recuperar información de ACL.

Los comandos cp y mv copian o mueven cualquier ACLs asociado con archivos y directorios.

8.1. Montaje de sistemas de archivos

Antes de usar ACL para un archivo o directorio, la partición para el archivo o directorio debe ser montada con soporte ACL. Si es un sistema de archivos local, se puede montar con el comando siguiente:

mount -t ext3 -o acl <device-name><partition>

Por ejemplo:

mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work

Alternativamente, si la partición esta listada en el archivo /etc/fstab, la entrada para la partición puede incluir la opción acl:

LABEL=/work /work ext3 acl 1 2

Si se accede a un sistema de archivos ext3 a través de Samba y se tiene activado las ACLs para este, las ACLs serán reconocidas porque Samba ha sido compilado con la opción --with-acl-support. No se requiere ningún indicador especial cuando se este montando una compartición Samba.

8.1.1. NFS

Por defecto, si el sistema de archivos que está siendo exportado por un servidor NFS soporta ACLs y el cliente NFS puede leer ACLs, los ACLs seran utilizados por el sistema cliente.

Para desactivar ACLs en sistemas de archivos NFS cuando se esté configurando el servidor, incluya la opción no_acl en el archivo /etc/exports. Para desactivar ACLs en una sistema compartido NFS cuando se esté montando en un cliente, móntelo con la opción no_acl a través de la línea de comandos o del archivo /etc/fstab.

8.2. Configuración de acceso a ACLs

Existen dos tipos de ACLs: acceso ACLs y ACLs predeterminado. Un acceso a ACLs es la lista de control de acceso para un archivo o directorio específico. Un ACLs predeterminado sólo puede ser asociado con un directorio, si un archivo dentro del directorio no tiene un ACL, el archivo utilizará las reglas del ACL predeterminado para el directorio. Los ACLs predeterminado son opcionales.

Los ACLs se pueden configurar:

  1. Por usuario

  2. Por grupo

  3. A través de la máscara de derechos efectivos

  4. Para usuarios que no estén en el grupo de usuarios para el archivo

La utilidad setfacl configura ACLs para archivos y directorios. Utilice la opción -m para añadir o modificar el ACL de un archivo o directorio:

setfacl -m <rules><files>

Las reglas (<rules>) deben ser especificadas en los formatos siguientes. Se pueden especificar múltiples reglas en el mismo comando si estas se encuentran separadas por comas.

u:<uid>:<perms>

Configura el acceso ACL para un usuario. Se debe especificar el nombre del usuario o su UID. El usuario puede ser cualquier usuario válido en el sistema.

g:<gid>:<perms>

Configura el acceso ACL para un grupo. Se debe especificar el nombre del grupo o su GID. El grupo puede ser cualquier grupo válido en el sistema.

m:<perms>

Configura la máscara de derechos efectivos. La máscara es la unión de todos los permisos del grupo propietario y todas las entradas del usuario y grupo.

o:<perms>

Configura el acceso ACL para otros usuarios que no esten en el grupo para el archivo.

Se ignoran los espacios en blanco. Los permisos (<perms>) deben ser una combinación de los caracteres r, w y x para lectura, escritura y ejecución respectivamente.

Si un archivo o directorio ya tiene una ACL y se usa el comando setfacl, se añaden las reglas adicionales al ACL existente o la regla existente es modificada.

Por ejemplo, para otorgar permisos de lectura y escritura para el usuario andrius:

setfacl -m u:andrius:rw /project/somefile

Para eliminar todos los permisos para un usuario, grupo u otros, utilice la opción -x y no especifique ningún permiso:

setfacl -x <rules><files>

Por ejemplo, para eliminar todos los permisos del usuario con UID 500:

setfacl -x u:500 /project/somefile

8.3. Configurar ACLs predeterminados

Para configurar un ACLs predeterminado, añada d: antes de la regla y especifique un directorio en vez de un nombre de archivo.

Por ejemplo, para configurar el ACL predeterminado para el directorio /share/ para que lea y ejecute para los usuarios que no se encuentren en el grupo del usuario (un acceso ACL para un archivo individual puede anularlo):

setfacl -m d:o:rx /share

8.4. Recuperar ACLs

Para determinar la existencia de ACLs para un archivo o directorio, utilice el comando getfacl. En el siguiente ejemplo, getfacl se utiliza para determinar los ACLs existentes para un archivo.

getfacl home/john/picture.png

El comando anterior devuelve la siguinete salida:

# file: home/john/picture.png # owner: john # group: john user::rw- group::r-- other::r--

Si se especifica un directorio y tiene un ACL predeterminado, el ACL por defecto también se presenta como se ve a continuación.

[john@main /]$ getfacl home/sales/# file: home/sales/ # owner: john # group: john user::rw- user:barryg:r-- group::r-- mask::r-- other::r-- default:user::rwx default:user:john:rwx default:group::r-x default:mask::rwx default:other::r-x

8.5. Archivar sistemas de archivos con ACLs

Aviso

Los comandos tar y dumpno respaldan ACLs.

La utilidad star es similar a la utilidad tar en que se puede utilizar para generar archivos de ficheros; sin embargo, algunas de sus opciones son diferentes. Consulte la Tabla 8.1, “Opciones de línea de comandos para star para obtener una lista de las opciones utilizadas con más frecuencia. Para ver todas las opciones disponibles, consulte la página del manual star. Se requiere el paquete star para utilizar esta utilidad.

Opción Descripción
-c Crea un paquete de archivos.
-n No extrae los archivos; úselo en conjunto -x para mostrar qué hace la extracción de archivos.
-r Reemplaza archivos en el paquete. Los archivos son escritos al final del paquete de archivos, reemplazando cualquier archivo con la misma ruta y nombre de archivo.
-t Muestra los contenidos de un paquete de archivos.
-u Actualiza el paquete de archivos. Los archivos son escritos al final del paquete si no existen en el paquete o si los archivos son más recientes que los archivos del mismo nombre en el paquete. Esta opción sólo funciona si el paquete es un archivo o una cinta no bloqueada en la que se pueda grabar en diferentes ubicaciones.
-x Extrae los archivos del paquete. Si se utiliza con -U y un archivo en el paquete es más antiguo que el archivo correspondiente en el sistema de archivos, el archivo no es extraído.
-help Muestra las opciones más importantes.
-xhelp Despliega las opciones menos importantes.
-/ No quita las barras oblicuas al comienzo de los nombres de archivos cuando se extraen archivos desde un paquete. Por defecto, estos son removidos cuando se extraen los archivos.
-acl Cuando se cree o extraiga, empaquete o restaure cualquier ACL asociado con los archivos y directorios.
Tabla 8.1. Opciones de línea de comandos para star

8.6. Compatibilidad con sistemas antiguos

Si se ha configurado un ACL en cualquier archivo en un sistema de archivos dado, ese archivo tiene el atributo ext_attr. Este atributo se puede ver usando el comando siguiente:

tune2fs -l <filesystem-device>

Se puede montar un sistema de archivos que haya adquirido el atributo ext_attr con kernels más viejos, pero estos kernels no hacen cumplir ningún ACLs que se haya configurado.

Las versiones de la utilidad e2fsck incluídas en la versión 1.22 y posteriores del paquete e2fsprogs (incluyendo las versiones en Red Hat Enterprise Linux 2.1 y 4) pueden verificar un sistema de archivos con el atributo ext_attr. Las versiones anteriores no lo hacen.

8.7. Recursos adicionales

Consulte los recursos siguientes para más información.

8.7.1. Documentación instalada

  • Página man de acl — Descripción de ACLs

  • Página man de getfacl — Discute cómo obtener las listas de control de acceso

  • Página man de setfacl — Explica cómo configurar listas de control de acceso de archivos

  • Página man de star — Explica más detalles sobre la utilidad star y sus opciones

8.7.2. Sitios Web de utilidad

Capítulo 9. LVM (Administrador de Volúmenes Lógicos)

9.1. ¿Qué es LVM?

LVM es una herramienta para la administración de volúmenes lógicos que incluye la asignación de discos, copias espejo y modificación de tamaño de los volumenes lógicos.

Con LVM, un disco duro o un grupo de ellos son asignados a uno o más physical volúmenes físicos. Los volúmenes físicos LVM se pueden poner en dispositivos de bloques que pueden tomar dos o más discos.

Los volúmenes físicos se combinan en volúmenes lógicos con la excepción de la partición /boot/. La partición /boot/ no puede estar en un grupo de volúmenes lógicos ya que el gestor de arranque no puede leerlo. Si la partición raíz (/) se encuentra en un volumen lógico entonces crea una partición /boot/ por separado, la cual no es parte de un grupo de volúmenes.

Ya que un volumen físico no puede abarcar múltiples discos, para poder abarcar más de un disco cree uno o más volúmenes físicos por disco.

Volúmenes lógicos

Grupo LVM

Figura 9.1. Volúmenes lógicos

Los grupos de volúmenes se pueden dividir en volúmenes lógicos, a los cuales se les asigna puntos de montaje tal como /home y/ y tipos de sistemas de archivos tal como ext2 o ext3. Cuando las "particiones" alcanzan su capacidad máxima se puede añadir espacio libre del grupo de volúmenes al volumen lógico para incrementar el tamaño de la partición. Cuando se añade un nuevo disco al sistema se puede añadir al grupo de volúmenes y se puede incrementar el tamaño de aquellas particiones que son volúmenes lógicos.

Volúmenes lógicos

Volúmenes lógicos

Figura 9.2. Volúmenes lógicos

Por otra parte, si un sistema está particionado con un sistema de archivos ext3, el disco duro se divide en particiones de tamaños definidos. Si una partición está completa, no es sencillo expandir el tamaño de la partición. Incluso si la partición se mueve a otro disco duro, el espacio del disco duro original deberá ser recolocado como una partición diferente o sin usar.

Para aprender cómo configurar LVM durante el proceso de instalación remítase al Sección 9.2, “Configuración de LVM”.

9.1.1. ¿Qué es LVM2?

La versión 2 de LVM o LVM2 es la predeterminada para Red Hat Enterprise Linux 5, la cual utiliza el disco de mapeo de dispositivos que se encuentra en el kernel 2.6. LVM2 de las versiones de Red Hat Enterprise Linux se puede actualizar ejecutando el kernel 2.4.

9.2. Configuración de LVM

Se puede configurar LVM durante el proceso gráfico de instalación, el proceso de instalación basado en texto o durante una instalación kickstart. Puede utilizar system-config-lvm para crear su propia configuración posterior a la instalación de LVM. Las próximas dos secciones se enfocan en utilizar Disk Druid durante la instalación para completar esta tarea. La tercera sección introduce la utilidad LVM (system-config-lvm) la cual le permite administrar sus volúmenes LVM en ventanas X o de maner gráfica.

Consulte Sección 9.1, “¿Qué es LVM?” primero para aprender sobre LVM. Una sinopsis sobre los pasos que se necesitan para configurar LVM incluye:

  • Crear volúmenes físicos desde los discos duros.

  • Crear volúmenes de grupos desde los volúmenes físicos.

  • Crear volúmenes lógicos desde los grupos de volúmenes y asignar puntos de montaje a los volúmenes lógicos.

Dos discos SCSI 9.1 GB (/dev/sda y /dev/sdb) se utilizan en los siguientes ejemplos. Describen como crear una configuración simple utilizando un sólo grupo de volúmenes LVM con volúmenes lógicos asociados durante la instalación.

9.3. Particionamiento automático

En la pantalla Configuración del particionamiento del disco, seleccione Particionamiento automático.

Para Red Hat Enterprise Linux, LVM es el método predeterminado para particionamiento de discos. Si no desea tener LVM implementado o si necesita un particionamiento RAID entonces necesitará un particionamiento manual de disco por medio de Disk Druid.

Las siguientes propiedades componen la configuración creada de manera automática:

  • La partición /boot/ se encuentra en su propia partición no LVM. En el siguiente ejemplo es la primera partición en el primer disco (/dev/sda1). Las particiones arrancables no se pueden encontrar en volúmenes lógicos LVM.

  • Se crea un sólo grupo de volúmenes LVM (VolGroup00), el cual abarca todos los discos seleccionados y todo el espacio disponible que queda. En el siguiente ejemplo, lo que queda del primer disco (/dev/sda2) y todo el segundo disco (/dev/sdb1) son asignados al grupo de volúmenes.

  • SE crean dos volúmenes lógicos LVM (LogVol00 and LogVol01) desde el nuevo grupo de volúmenes recién creado. En el siguiente ejemplo, el espacio swap recomendado es calculado automáticamente y asignado a LogVol01 y lo que queda se asigna al sistema de archivos root, LogVol00.

Configuración automática de LVM con dos discos SCSI

Configuración automática de LVM con dos discos SCSI

Figura 9.3. Configuración automática de LVM con dos discos SCSI

Nota

Si le interesa saber sobre cómo habiliatr cuotas puede llegar a ser mejor el modificar la configuración automática para incluir otros puntos de montaje tal como /home/ o /var/ para que cada sistema de archivos tenga sus límites de configuración de cuota independientes.

En la mayoría de los casos, el particionamiento LVM automático predeterminado es suficiente pero las implementaciones avanzadas podrían garantizar la modificación o configuración manual de la tablas de partición.

Nota

Si espera tener actualizaciones de memoria en el futuro, el dejar algo de espacio libre en el grupo de volúmenes permitiría una fácil expansión futura del volúmen lógico de espacio swap en el sistema, en cuyo caso la configuración automática de LVM debe modificarse para dejar espacio disponible para un crecimiento en el futuro.

9.4. Particionamiento manual de LVM

La siguiente sección explica como configurar manualmente LVM para Red Hat Enterprise Linux. Debido a que hay numerosas mmaneras de configurar manualmente un sistema con LVM, el siguientes ejemplo es similar a la configuración predeterminada que se realiza en Sección 9.3, “Particionamiento automático”.

En la pantalla Configuración del particionamiento del disco, seleccione Particionamiento manual con Disk Druid.

9.4.1. Creación de la partición /boot/

En una situación típica, los discos son nuevos o sin formatos. La siguiente figura Figura 9.4, “Dos discos en blanco listos para la configuración” muestra ambos discos como dispositivos crudos sin nigún particionamiento configurado.

Dos discos en blanco listos para la configuración

Dos discos en blanco listos para la configuración

Figura 9.4. Dos discos en blanco listos para la configuración

Aviso

La partición /boot/ no se puede encontrar en un volumen LVM ya que el el gestor de arranque GRUB no lo puede leer.

  1. Seleccione Nuevo.

  2. Seleccione /boot del menú deplegable Punto de montaje.

  3. Seleccione ext3 del menú deplegable Tipo de sistema de archivos.

  4. Seleccione sólamente la casilla sda del área Discos permitidos.

  5. Deje 100 (el predeterminado) en el menú Tamaño (MB).

  6. Deje el botón del radio seleccionado Tamaño fijo (el predeterminado) en el área Opciones adicionales de tamaño.

  7. Seleccione Forzar a ser partición primaria para hacer que la partición sea una partición primaria. Una partición primaria es una de las primeras cuatro particiones en el disco duro. Si no se selecciona la partición se crea como una partición lógica. Si ya hay otros sistemas operativos en el sistema debe considerar el deseleccionar esta opción. Para obtener mayor información sobre particiones primarias versus particiones lógicas/extendidas consulte el apéndice del Manual de Instalación de Red Hat Enterprise Linux.

Consulte Figura 9.5, “Creación de la partición boot” para verificar los valores introducidos:

Creación de la partición boot

Creación de la partición boot

Figura 9.5. Creación de la partición boot

Pulse OK para volver a la pantalla principal. La siguiente figura presenta la partición boot correctamente configurada:

La partición /boot/ visualizada

La partición /boot/ visualizada

Figura 9.6. La partición /boot/ visualizada

9.4.2. Creación de los volúmenes físicos LVM

Una vez se crea la partición boot lo que queda del espacio del disco se puede asignar a las particiones LVM. El primer paso para crear una implementación LVM exitosa es la creación de volúmenes físicos.

  1. Seleccione Nuevo.

  2. Seleccione volumen fisico (LVM) del menú desplegable Tipo de sistema de archivos como se muestra en Figura 9.7, “Creación de un volumen físico”.

    Creación de un volumen físico

    Creación de un volumen físico

    Figura 9.7. Creación de un volumen físico

  3. Todavía no puede introducir un punto de montaje (esto lo puede hacer una vez que haya creado todos sus volúmenes físicos y después todos los grupos de volúmenes).

  4. Un volumen físico debe ser restringido a un solo disco. Para Allowable Drives seleccione en el cual el volumen físico es creado. Si tiene múltiples discos todos los discos serán seleccionados y usted debe deseleccionarlos y dejar sólo uno.

  5. Introduzca el tamaño que desea que posea el volumen físico.

  6. Seleccione Tamaño fijo para hacer el volumen físico del tamaño especificado, seleccione Llene todo el espacio hasta (MB) e introduzca un tamaño en MBg para dar el rango del tamaño del volumen físico o seleccione Llenar hasta el tamaño máximo permitido para que crezca y llene todo el espacio disponible en el disco duro. Si le da la opción de crecer a mas de uno entonces compartirán en espacio disponible en el disco.

  7. Seleccione Forzar para que sea una partición primaria si desea que la partición sea una partición primaria.

  8. Pulse OK para volver a la pantalla principal.

Repita estos pasos para crear tantos volúmenes físicos como necesite para su configuración LVM. Por ejemplo, si quiere que el grupo de volúmenes abarque más de un disco cree un volumen físico en cada uno de los discos. La siguiente figura muetra ambos discos completados después de repetir el proceso:

Dos volúmenes físicos creados

Dos volúmenes físicos creados listos para grupos de volúmenes

Figura 9.8. Dos volúmenes físicos creados

9.4.3. Crear el grupo de volúmenes LVM

Una vez se crean todos los volúmenes físicos entonces se pueden crear los grupos de volúmenes:

  1. Pulse el botón LVM para reunir los volúmenes físicos en grupos de volúmenes. Un grupo de volumen es básicamente una colección de volúmenes físicos. Puede poseer múltiples volúmenes lógicos, pero un volumen físico tan sólo puede estar en un grupo de volumen.

    Nota

    Hay un espacio de disco reservado en el grupo de volúmenes en caso de saturación. El tamaño del grupo de volúmenes es un poco más pequeño que el total de los tamaños de los volúmenes físicos.

    Creación de un grupo de volúmenes LVM

    Creación de un grupo de volúmenes LVM

    Figura 9.9. Creación de un grupo de volúmenes LVM

  2. Cambie el Nombre del grupo de volumen si lo desea.

  3. Se deben asignar todos los volúmenes lógicos dentro del grupo de volúmenes en unidades de extensión física. Una extensión física es la asignación de unidades para datos.

  4. Seleccione los volúmenes físicos a usar para el grupo de volumen.

9.4.4. Creación de volúmenes lógicos LVM

Cree volúmenes lógicos con puntos de montaje tales como /, /home/ y espacio swap. Recuerde que /boot no puede ser un volumen lógico. Para añadir un volumen lógico haga click en el botón Añadir en la sección Volúmenes lógicos. Aparece una ventana como se muestra en Figura 9.10, “Creación de un volumen lógico”.

Creación de un volumen lógico

Creación de un volumen lógico

Figura 9.10. Creación de un volumen lógico

Repita estos pasos para cada grupo de volumen que desee crear.

Sugerencia

Puediese dejar algo de espacio libre en el grupo de volúmenes para poder expandir los volúmenes lógicos más adelante. La configuración automática predeterminada no hace esto pero este ejemplo de configuración manual — aproximadamente se deja 1 GB de espacio libre en caso de una expansión futura.

Volúmenes lógicos pendientes

Volúmenes lógicos pendientes

Figura 9.11. Volúmenes lógicos pendientes

Haga clic sobre OK para aplicar el grupo de volúmenes y todos los volúmenes lógicos asociados.

La siguiente figura muestra la configuración manual final:

Configuración manual final

Configuración manual final

Figura 9.12. Configuración manual final

9.5. Usar la utilidad LVM system-config-lvm

La utilidad LVM le permite administrar volúmenes lógicos dentro de ventanas X o de manera gráfica. Puede acceder a la aplicación al seleccionar del menú Sistema => Administración => Administración de volúmenes lógicos. Alternativamente puede iniciar la utilidad de administración de volúmenes lógicos escribiendo system-config-lvm en una terminal.

En el ejemplo que se utilizó en esta sección los siguientes son los detalles para el grupo de volúmenes que se creó durante la instalación:

/boot - (Ext3) file system. Displayed under 'Uninitialized Entities'. (DO NOT initialize this partition).
LogVol00 - (LVM) contains the (/) directory (312 extents).
LogVol02 - (LVM) contains the (/home) directory (128 extents).
LogVol03 - (LVM) swap (28 extents).

Los volúmenes lógicos anteriores se crearon en una entidad de disco /dev/hda2 mientras que /boot se creó en /dev/hda1. El sistema también cosiste de entidades no inicializadas las cuales se encuentran ilustradas en Figura 9.17, “Entidades no inicializadas”. La figura a continuación ilustra la ventana principal en la utilidad LVM. A continuación encontrará la perspectiva física y lógica de la configuración anterior. Los tres volúmenes lógicos existen en el mismo volumen lógico (hda2).

Ventana principal LVM

Ventana principal LVM

Figura 9.13. Ventana principal LVM

La figura a continuación ilustra la vista física para el volumen. En esta ventana puede seleccionar y remover un volumen de un grupo de volúmenes o migrar extensiones de un volumen a otro grupo de volúmenes. Los pasos para migrar extenciones se discuten en Figura 9.22, “Migración de extenciones”.

Ventana de vista física

Ventana de vista física

Figura 9.14. Ventana de vista física

La figura a continuación ilustra la vista lógica para el grupo de volúmenes seleccionado. El tamaño para el volumen lógico también se indica con los tamaños de volúemenws lógicos individuales ilustrados.

Ventana de vista lógica

Ventana de vista lógica

Figura 9.15. Ventana de vista lógica

En la columna izquierda puede seleccionar los volúmenes lógicos individuales en el grupo de volúmenes para ver más detalles sobre cada uno. En este ejemplo, el objetivo es renombrar el volumen lógico de 'LogVol03' a 'Swap'. Para realizar esta operación seleccione el volumen lógico respectivo y haga click en el botón Modificar propiedades. Esto presentará la ventana de modificación de volúemens lógicos desde la cual puede modificar el nombre del volumen lógico, el tamaño (en extensión) y también puede utilizar el espacio disponible en un grupo de volúmenes lógicos. La figura que se encuentra a continuación ilustra esto.

Observe que no se puede cambiar el tamaño de este volumen lógico ya que actualmente no hay espacio libre en el grupo de volúmenes. Si hubiese espacio libre se activaria esta opción (consulte Figura 9.31, “Modificación de un volumen lógico”). Haga click en el botón OK para guardar sus cambios (esto volverá a montar el volumen). Para cancelar los cambios ahaga click en el botón Cancelar. Para volver a la configuración previa haga click en el botón Revertir. Se puede crear una instantánea al hacer click en en botón Crear instantánea en la ventana de la utilidad LVM. Si (por ejemplo) el sistema / (root) se encuentra utilizando el volumen lógico seleccionado el directorio, esta tarea no tendrá exito ya que no se puede desmontar el volumen.

Modificar un volumen lógico

Modificar volumen lógico

Figura 9.16. Modificar un volumen lógico

9.5.1. Uso de entidades no incializadas

Las 'Entidades no inicializadas' consisten de espacio no particionado y de sistemas de archivos no LVM. En este ejemplo, las particiones 3, 4, 5, 6 y 7 fueron creadas durante la instalación y se dejó algo de espacio no particionado en el disco duro. Vea cada partición y asegúrese de leer las 'propiedades para entidades del disco' en la columna derecha de la ventana para estar seguro de que no va a borrar datos importantes. En este ejemplo la partición 1 no se puede inicializar ya que es /boot. Las entidades no inicializadas se ilustran a continuación.

Entidades no inicializadas

Entidades no inicializadas

Figura 9.17. Entidades no inicializadas

En este ejemplo, la partición 3 será inicializada y añadida a un grupo de volúmenes existente. Para inicializar una partición o un espacio no particionado selecciones la partición y haga click en el botón Inicializar entidad. Una vez inicializada se enumerará un volumen en la lista de 'Volúmenes no asignados'.

9.5.2. Añadir volúmened no asignados a un grupo de volúmenes

Una vez inicializado el volumen será enumerado en la lista de 'Volúmenes no asignados'. La figura a continuación ilustra una partición no asignada (partición 3). Los botones respectivos al final de la ventana le permitirán:

  • crear un nuevo grupo de volúmenes,

  • añadir el volumen no asignado a un grupo de volúmenes ya existente,

  • remover el volumen de LVM.

Para añadir el volumen a un grupo de volúmenes existente haga click en el botón Añadir a un grupo de volúmenes existente button.

Volúmenes no asignados

Volúmenes no asignados

Figura 9.18. Volúmenes no asignados

Al hacer click en el botón Añadir al volumen existente aparacerá una ventana emergente que lista los grupos de volúmenes existentes a los cuales usted puede añadir el volumen físico que está a punto de inicializar. Un grupo de volúmenes puede abarcar uno o más dicos duros. En este ejemplo, sólo existe un grupo de volúmenes como se muestra a continuación.

Añadir el volumen físico al grupo de volúmenes

Añadir el volumen físico al grupo de volúmenes

Figura 9.19. Añadir el volumen físico al grupo de volúmenes

Una vez es añadido al grupo de volúmenes existentes el nuevo volumen lógico es añadido automáticamnete al espacio no utilizado del grupo de volúmenes seleccionado. Puede usar el espacio no utilizado para:

  • crear un nuevo volumen lógico (haga click en el botón Crear nuevo(s) volúmen(es) lógicos,

  • seleccionar uno de los volúmenes lógicos ya existentes e incrementar las extensiones (ver Sección 9.5.6, “Entensión de un grupo de volúmenes”),

  • seleccionar un volumen lógico ya existente y removerlo del grupo de volúmenes al hacer click en el botón Remover volumen(es) lógicos seleccionados. Observe que no puede seleccionar espacio no utilizado para realizar esta operación.

La figura a continuación ilustra la vista lógica de 'VolGroup00' después de añadir el nuevo grupo de volúmenes.

Vista lógica del grupo de volúmenes

Vista lógica del grupo de volúmenes

Figura 9.20. Vista lógica del grupo de volúmenes

En la figura de a continuación las entidades no inicializadas (particiones 3, 5, 6 y 7) se añadieron a 'VolGroup00'.

Vista lógica del grupo de volúmenes

Vista lógica del grupo de volúmenes

Figura 9.21. Vista lógica del grupo de volúmenes

9.5.3. Migración de extenciones

Para migrar las extensiones desde un volumen lógico seleccione el volumen y haga click en el botón Migrar extensiones seleccionadas desde el volumen. Observe que necesita tener un número suficiente de extensiones para migrar extensiones dentro de un grupo de volúmenes. SE presentará un mensaje de error si no tiene el número suficiente de extensiones libres. Para resolver este problema extienda su grupo de volúmenes (vea Sección 9.5.6, “Entensión de un grupo de volúmenes”). Si se detecta un número de extensiones libres en el grupo de volúmenes aparecerá una ventana emergente de la cual el destino para las extensiones o también puede dejar escoger automáticamente al LVM los volúmenes físiscos a los cuales migrar. Esto se ilustra a continuación.

Migración de extenciones

Migración de extenciones

Figura 9.22. Migración de extenciones

La figura a continuación ilustra una migración de extensiones en curso. En este ejemplo, las extensiones fueron migradas a la 'Partición 3'.

Migración de extenciones en curso

Migración de extenciones en curso

Figura 9.23. Migración de extenciones en curso

Una vez se han migrado las extensiones el espacio no utilizado se deja en el volumen físico. La figura a continuación ilustra la vista lógica y física para el grupo de volúmenes. Observe que las extensiones de LogVol00 que se encontraban inicialmente en hda2 ahora están en hda3. El migrar las extensiones le permite mover volúmenes lógicos en caso de actualizaciones de discos duros o para administrar el espacio de su disco de una mejor manera.

Vista lógica y física de un grupo de volúmenes

Vista lógica y física de un grupo de volúmenes

Figura 9.24. Vista lógica y física de un grupo de volúmenes

9.5.4. Añadir un nuevos disco duro utilizando LVM

En ste ejemplo, se añadió un nuevo disco duro IDE. La figura a continuación ilustralos detalles del nuevo disco duro. De la figura a continuación, el disco es inicializado y no montado. Para inicializar una partición haga click en el botón Inicializar entidad. Para obtener más detalles vea Sección 9.5.1, “Uso de entidades no incializadas”. Una vez inicializado LVM añadirá el nuevo volumen a la lista de volúmenes no asignados como se ilustra en Figura 9.26, “Crear un nuevo grupo de volúmenes”.

Disco duro no inicializado

Disco duro no inicializado

Figura 9.25. Disco duro no inicializado

9.5.5. Añadir un nuevo grupo de volúmenes

Una vez inicializado, LVM añadirá el nuevo volumen a la lista de volúmenes no asignados en donde pueda añadirla a un grupo de volúmenes ya existente o crear un nuevo grupo de volúmenes. También puede remover el volumen para LVM. Si se remueve el volumen del LVM será enumerado en la lista de entidades no inicializadas como se ilustra en Figura 9.25, “Disco duro no inicializado”. En este ejemplo, se creó un nuevo grupo de volúmenes como se ilustra a continuación.

Crear un nuevo grupo de volúmenes

Crear un nuevo grupo de volúmenes

Figura 9.26. Crear un nuevo grupo de volúmenes

Una vez creado se presentará un grupo de volúmenes nuevo en la lista de grupos de volúmenes existentes como se ilustra a continuación. La vista lógica presentará el nuevo grupo de volúmenes con espacio no utilizado ya que no se han creado volúmenes lógicos. Para crear un volúmen lógico seleccione el grupo de volúmenes y haga click en el botón Crear un nuevo volumen lógico como se ilustra a continuación. Seleccione las extensiones que quiere utilizar en el grupo de volúmenes. En este ejemplo, todas las extensiones en el grupo de volúmenes se utilizaron para crear el nuevo volumen lógico.

Crear un nuevo volumen lógico

Crear un nuevo volumen lógico

Figura 9.27. Crear un nuevo volumen lógico

La figura a continuación ilustra la vista física del nuevo grupo de volúmenes. El nuevo volumen lógico llamado 'Backups'en este grupo de volúmenes también se lista.

Vista física del nuevo grupo de volúmenes

Vista física del nuevo grupo de volúmenes

Figura 9.28. Vista física del nuevo grupo de volúmenes

9.5.6. Entensión de un grupo de volúmenes

En este ejemplo, el objetivo era extender el nuevo grupo de volúmenes para incluir una entidad no inicializada (partición). Esto era para incrementar el tamaño o número de extensiones para el grupo de volúmenes. Para extender el grupo de volúmenes haga click en el botón Extender grupo de volúmenes. Esto presentará la ventana 'Extender grupo de volúmenes' como se ilustra a continuación. En esta ventana puede seleccionar las entidades de disco (particiones) para añadir al grupo de volúmenes. Asegúrese de que chequear el contenido de cualquiera de las 'Entidades de disco no inicializadas' (particiones) para evitar borra datos importantes (vea Figura 9.25, “Disco duro no inicializado”). En el ejemplo, se seleccionó la entidad de disco (partición) /dev/hda6 como se ilustra a continuación.

Selección de entidades de disco

Selección de entidades de disco

Figura 9.29. Selección de entidades de disco

Una vez añadido, el nuevo volumen será añadido como 'espacio no utilizado' en el grupo de volúmenes. La figura a continuación ilustra la vista lógica y física del grupo de volúmenes después de que fue extendido.

Vista lógica y física de un grupo de volúmenes extendidos

Vista lógica y física de un grupo de volúmenes extendidos

Figura 9.30. Vista lógica y física de un grupo de volúmenes extendidos

9.5.7. Modificación de un volumen lógico

La utilidad LVM le permite seleccionar un volumen lógico en el grupo de volúmenes y modificar su nombre, tamaño y especificar sus opciones de sistemas de archivos. En este ejemplo, el volumen lógico llamado 'Backups' fue extendido al espacio que quedaba para el grupo de volúmenes.

Al hacer click en el botón Modificar propiedades se presentará una ventana emergente para 'Modificar Volumen Lógico' desde la cual puede editar las propiedades del volumen lógico. En esta ventana también puede montar el volumen después de realizar los cambios y montarlos cuando se reinicie el sistema. Observe que debe indicar el punto de montaje. Si el punto de montaje que espcifica no existe aparecerá una ventana emergente que le pedirá que lo cree. La ventana 'Modificar Volumen Lógico' se ilustra a continuación.

Modificación de un volumen lógico

Modificación de un volumen lógico

Figura 9.31. Modificación de un volumen lógico

Si desea montar el volumen seleccione la casilla 'Montar' indicando el punto de montaje preferido. Para montar el volumen cuando el sistema es reiniciado seleccione la casilla 'Montar al reiniciar'. En este ejemplo, el volumen nuevo será montado en /mnt/backups. Esto se ilustra en la figura a continuación.

Modificación de un volumen lógico - especicación de opciones de montaje

Modificación de un volumen lógico - especicación de opciones de montaje

Figura 9.32. Modificación de un volumen lógico - especicación de opciones de montaje

La figura a continuación ilustra la vista lógica y física del grupo de volúmenes desde de que se ha extendido un volumen lógico al espacio no utilizado. Observe que en este ejemplo el volumen lógico llamado 'Backups'abarca dos discos duros. Un volumen se puede extender a través de dos o más dispositivos físicos utilizando LVM.

Modificación de un volumen lógico

Modificación de un volumen lógico

Figura 9.33. Modificación de un volumen lógico

9.6. Recursos adicionales

Utilice estos recursos para aprender más sobre LVM

9.6.1. Documentación instalada

  • rpm -qd lvm2 — This command shows all the documentation available from the lvm package, including man pages.

  • lvm help — Este comando muestra todos los comandos LVM disponibles.

9.6.2. Sitios Web de utilidad

Parte II. Administración de paquetes

Capítulo 10. Administración de paquetes con RPM

El Gestor de paquetes RPM (RPM) es un sistema de empaquetado de código abierto que trabaja en Red Hat Enterprise Linux así como también en otros sistemas Linux y UNIX. Red Hat, Inc. fomenta el uso de RPM por parte de otros vendedores para sus propios productos. RPM se distribuye bajo los términos de la licencia GPL.

La utilidad funciona únicamente con paquetes construidos para ser procesados por el paquete rpm. RPM facilita las actualizaciones de sistema para el usuario final. Es posible instalar, desinstalar y actualizar paquetes RPM por medio de comandos breves. RPM mantiene una base de datos de los paquetes instalados y de sus archivos. Usted puede realizar poderosas consultas y verificaciones en su sistema. Si prefiere una interfaz gráfica, puede utilizar la Herramienta de administración de paquetes para ejecutar muchos comandos RPM. Para mayor información consulte el Capítulo 11, Herramienta de administración de paquetes.

Importante

Antes de instalar un paquete asegúrese de que éste sea compatible con su sistema operativo y arquitectura. Estos datos se pueden determinar en la mayoría de los casos revisando el nombre del paquete.

Durante las actualizaciones, RPM maneja cuidadosamente los archivos de configuración para que usted nunca pierda sus personalizaciones — algo que no lograría hacer con archivos .tar.gz normales.

RPM permite al desarrollador tomar el código fuente del software y empaquetarlo en paquetes binarios y de fuente para los usuarios finales. Este proceso es bastante sencillo y se controla desde un único archivo y parches opcionales creados por usted mismo. Esta clara delineación de fuentes originarias y sus parches junto con las instrucciones de construcción, facilitan el mantenimiento del paquete al ir apareciendo nuevas versiones del software.

Nota

Ya que RPM efectúa cambios a su sistema, usted debe tener privilegios de usuario root para poder instalar, remover o actualizar un paquete RPM.

10.1. Metas de diseño RPM

Podría ser útil conocer las metas de diseño de RPM para poder aprender a usarlo:

Predisposición a la actualización

Al usar RPM es posible actualizar componentes individuales de su sistema sin tener que reinstalarlos completamente. Cuando obtenga una versión nueva de un sistema operativo basado en RPM (como Red Hat Enterprise Linux), no es necesario efectuar una reinstalación en su máquina (como debe hacerse con sistemas operativos basados en otros sistemas de empaquetado). RPM permite actualizaciones inteligentes y completamente automatizadas de su sistema. Los archivos de configuración de los paquetes actualizados se conservan para que usted no pierda sus personalizaciones. No existen archivos de actualización específicos para actualizar un paquete porque se utiliza el mismo archivo RPM para instalar y actualizar el paquete en su sistema.

Consultas poderosas

RPM fue ideado para proporcionar opciones de consulta poderosas. Se pueden efectuar búsquedas por toda su base de datos para encontrar un paquete o sólo algún archivo. También es posible averiguar a cuál paquete pertenece un determinado archivo y de dónde proviene el paquete. Los archivos contenidos en el paquete RPM están en un archivo comprimido, con un encabezado binario personalizado que contiene información útil sobre el paquete y su contenido, permitiéndole consultar paquetes individuales rápida y sencillamente.

Verificación de sistema

Otra característica poderosa de RPM es la posibilidad que ofrece de verificar los paquetes. Si está preocupado de haber borrado un archivo importante de algún paquete, verifique el paquete. Se le notificará si hay cualquier anomalía. En este punto, puede reinstalar el paquete si es necesario. Cualquier archivo de configuración que haya modificado será preservado durante la reinstalación.

Fuentes originarias

Un objetivo crucial ha sido el de permitir el uso de fuentes de software originario, tal y como ha sido distribuido por los autores originales del software. Con RPM tendrá las fuentes originarias junto con cualquier parche que haya sido usado además de las instrucciones de construcción completas. Esta es una ventaja importante por varios motivos. Si por ejemplo sale una versión nueva de un programa, no necesariamente necesita empezar desde cero para que se compile. Puede revisar el parche para ver lo que tal vez necesitaría hacer. Usando esta técnica se ven fácilmente todos los elementos predeterminados y compilados en el programa y todos los cambios que se le han hecho al software para construir adecuadamente.

El objetivo de mantener las fuentes originarias podría parecer importante sólo para los desarrolladores, pero el resultado de este objetivo también brinda un software de más alta calidad para los usuarios finales.

10.2. El uso de RPM

RPM tiene cinco modos de operación básicos (sin contar la construcción de paquetes): instalación, desinstalación, actualización, consulta y verificación. Esta sección contiene una visión de conjunto de cada modo. Para obtener detalles y opciones ejecute el comando rpm --help o man rpm. También puede consultar la Sección 10.5, “Recursos adicionales” para obtener mayor información sobre RPM.

10.2.1. Encontrar paquetes RPM

Antes de utilizar un RPM, debe saber dónde encontrarlos. Una búsqueda en Internet le retornará muchos repositorios de RPM, pero si está buscando paquetes RPM construídos por Red Hat, éstos se encuentran en las siguientes ubicaciones:

10.2.2. Instalación de RPM

Los paquetes RPM normalmente tienen nombres de archivo como foo-1.0-1.i386.rpm. El nombre de archivo incluye el nombre de paquete (foo), la versión (1.0), el lanzamiento (1) y la arquitectura (i386). La instalación de un paquete es tan simple como teclear el siguiente comando en el intérprete de comandos de shell:

rpm -ivh foo-1.0-1.i386.rpm

Alternatively, the following command can also be used:

rpm -Uvh foo-1.0-1.i386.rpm

Si la instalación es exitosa verá lo siguiente:

 Preparing... ########################################### [100%] 1:foo ########################################### [100%]

Como podrá ver, RPM imprime el nombre del paquete y luego imprime una serie de almohadillas (#) que sirven de medidor de progreso mientras se instala el paquete.

La firma del paquete se autentica en el momento de la instalación o de la actualización del paquete. La firma confirma que el paquete ha sido firmado por una entidad autorizada. Si la verificación de la firma falla, verá el siguiente mensaje de error:

error: V3 DSA signature: BAD, key ID 0352860f

Si se trata de una nueva firma, solamente de cabecera, verá el siguiente error:

error: Header V3 DSA signature: BAD, key ID 0352860f

Si no tiene instalada la llave apropiada para verificar la firma, el mensaje contendrá la palabra NOKEY tal como:

warning: V3 DSA signature: NOKEY, key ID 0352860f

Para mayor información sobre la verificación de la firma del paquete consulte la Sección 10.3, “Verificando la firma del paquete”.

Atención

Si está instalando un paquete del kernel, use el comando rpm -ivh. Consulte el Capítulo 40, Actualización Manual del Kernel para obtener mayor información.

10.2.2.1. Paquete ya instalado

Si ya está instalado un paquete de la misma versión y nombre, se mostrará lo siguiente:

 Preparing... ########################################### [100%] package foo-1.0-1 is already installed

Si desea instalar el paquete de todos modos y la versión que está intentando instalar ya está instalada, podrá usar la opción --replacepkgs, la cual le dirá a RPM que ignore el error:

rpm -ivh --replacepkgs foo-1.0-1.i386.rpm

Esta opción es útil si se borraron los archivos instalados del RPM o si desea que se instalen los archivos de configuración originales del RPM.

10.2.2.2. Archivos en conflicto

Si intenta instalar un paquete que contiene un archivo que ya ha sido instalado por otro paquete o una versión más antigua del mismo paquete, verá lo siguiente:

 Preparing... ########################################### [100%] file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20

Para hacer que RPM ignore este error, use la opción --replacefiles:

rpm -ivh --replacefiles foo-1.0-1.i386.rpm

10.2.2.3. Dependencias no resueltas

Los paquetes RPM pueden depender de otros paquetes, lo cual significa que requieren de la instalación de otros paquetes para poder ejecutarse adecuadamente. Si intenta instalar un paquete que tiene una dependencia no resuelta, se mostrará una salida similar a lo siguiente:

 error: Failed dependencies: bar.so.2 is needed by foo-1.0-1 Suggested resolutions: bar-2.0.20-3.i386.rpm

Si está instalando un paquete desde un conjunto de CD-ROMs de Red Hat Enterprise Linux, se le sugerirá resolver la dependencia de este paquete. Encuentre el paquete sugerido en los CD-ROMs de Red Hat Enterprise Linux o desde Red Hat Network y añádalo al comando:

rpm -ivh foo-1.0-1.i386.rpm bar-2.0.20-3.i386.rpm

Si la instalación de ambos paquetes es exitosa, verá una salida similar a lo siguiente:

 Preparing... ########################################### [100%] 1:foo ########################################### [ 50%] 2:bar ########################################### [100%]

Si no se le suguiere resolver la dependencia, puede intentar usar la opción --redhatprovides para determinar el paquete que contenga el archivo requerido. Necesita instalar el paquete rpmdb-redhat para usar esta opción.

rpm -q --redhatprovides bar.so.2

Si el paquete que contiene el archivo bar.so.2 se encuentra en la base de datos instalada del paquete rpmdb-redhat, aparecerá el nombre del paquete:

bar-2.0.20-3.i386.rpm

Si desea de todas maneras forzar la instalación, lo cual no es una buena idea ya que el paquete no funcionará correctamente, use la opción --nodeps.

10.2.3. Desinstalación

Desinstalar un paquete es tan simple como instalarlo. Teclee el siguiente comando en el intérprete de comandos de la shell:

rpm -e foo

Nota

Observe que hemos usado el nombrefoo del paquete, no el nombre del archivofoo-1.0-1.i386.rpm del paquete original. Para desinstalar un paquete, necesitará sustituir foo con el nombre verdadero del paquete original.

Podría encontrarse con un error de dependencia cuando esté desinstalando un paquete si otro paquete instalado depende del que está tratando de eliminar. Por ejemplo:

 error: Failed dependencies: foo is needed by (installed) bar-2.0.20-3.i386.rpm

Para hacer que RPM ignore este error y desinstale el paquete de todos modos (que tampoco es buena idea ya que al hacerlo el paquete que depende de él probablemente dejará de funcionar correctamente), utilice la opción --nodeps.

10.2.4. Actualización

Actualizar un paquete es parecido a instalarlo. Teclee el siguiente comando en un intérprete de comandos de la shell:

rpm -Uvh foo-2.0-1.i386.rpm

Como parte de la actualización de un paquete, RPM desinstala automáticamente cualquier versión antigua del paquete foo. De hecho, tal vez desee usar la opción -U siempre para instalar paquetes, ya que funcionará aunque no existan versiones precedentes del paquete instaladas.

Sugerencia

No utilice la opción -U para instalar paquetes del kernel porque RPM reemplaza el paquete de kernel anterior. Esto no afecta el sistema en ejecución, pero si el nuevo kernel no puede arrancar durante su próximo inicio usted no tendrá otro kernel adicional para arrancar en su lugar.

La opción -i añade el kernel a su menú GRUB de arranque (/etc/grub.conf). De la misma manera, al eliminar el viejo kernel que ya no necesita, también se eliminará la entrada del menú de GRUB para ese kernel.

Ya que RPM lleva a cabo la actualización inteligente de paquetes con archivos de configuración, tal vez vea un mensaje como el siguiente:

saving /etc/foo.conf as /etc/foo.conf.rpmsave

Este mensaje significa que los cambios hechos al archivo de configuración podrían no ser compatibles con el nuevo archivo de configuración en el paquete, así que RPM ha almacenado su archivo original y ha instalado uno nuevo. Debería averiguar cuáles son las diferencias entre los dos archivos de configuración y resolver el problema tan pronto como sea posible, para asegurarse de que su sistema continúe funcionando correctamente.

Si intenta actualizar un paquete con un número de versión anterior (lo que significa que el paquete ya está instalado), verá lo siguiente:

package foo-2.0-1 (which is newer than foo-1.0-1) is already installed

Para hacer que RPM realice la actualización de todos modos, use la opción --oldpackage:

rpm -Uvh --oldpackage foo-1.0-1.i386.rpm

10.2.5. Refrescamiento

Refrescar un paquete es parecido a actualizarlo con la diferencia de que solo se actualizan paquetes ya instalados. Teclee el siguiente comando en un intérprete de comandos de shell:

rpm -Fvh foo-1.2-1.i386.rpm

La opción de refrescamiento RPM compara las versiones de los paquetes especificados en la línea de comandos contra las versiones de los paquetes que ya han sido instalados en su sistema. Cuando la opción de refrescamiento de RPM procesa una versión más reciente de un paquete ya instalado, éste será actualizado a la versión más reciente. Sin embargo, la opción de refrescamiento de RPM no instalará un paquete si no existe un paquete previamente instalado del mismo nombre. Esto no es igual a la opción de actualización de RPM, ya que una actualización instalará los paquetes, no importa si ya está instalada o no una versión más antigua de los paquetes.

La opción de refrescamiento de RPM funciona ya sea con paquetes individuales o con un grupo de paquetes. Si usted acaba de descargar una gran cantidad de paquetes diferentes y sólo desea actualizar los paquetes que ya estaban instalados en su sistema, utilice esta opción. Así no tendrá que borrar ningún paquete no deseado antes de utilizar RPM.

En este caso, puede ejecutar el comando siguiente:

rpm -Fvh *.rpm

RPM actualizará automáticamente sólo aquellos paquetes que ya estén instalados.

10.2.6. Consultas

La base de datos RPM almacena información sobre todos los paquetes RPM instalados en su sistema. La base de datos se almacena en /var/lib/rpm/ y se utiliza para solicitar información sobre los paquetes instalados, sus versiones, cualquier cambio ocurrido a los archivos del paquete desde su instalación, etc.

Para consultar esta base de datos utilice la opción -q. El comando rpm -q nombre-del-paquete muestra el nombre del paquete, la versión y el número de lanzamiento del paquete instalado nombre-del-paquete. Por ejemplo, si utiliza rpm -q foo para consultar el paquete instalado foo, verá:

foo-2.0-1

También puede utilizar las siguientes opciones de selección de paquetes con -q para refinar la consulta:

  • -a — consulta todos los paquetes actualmente instalados.

  • -f <archivo> consultará el paquete que posea <archivo>. Cuando especifique un archivo, deberá especificar la ruta completa del archivo (por ejemplo /bin/ls).

  • -p <archivo-paquete> — consulta el paquete no instalado <archivo-paquete>.

Hay varias maneras de especificar la información que se debe mostrar sobre los paquetes consultados. Las siguientes opciones sirven para seleccionar el tipo de información que usted está buscando. Éstas se llaman Opciones de selección de información.

  • -i muestra información del paquete como el nombre, la descripción, la versión, el tamaño, la fecha de construcción, la fecha de instalación, el distribuidor, y otra información miscelánea.

  • -l muestra la lista de archivos contenidos en el paquete.

  • -s muestra el estado de todos los archivos en el paquete.

  • -d muestra una lista de archivos marcados como documentación (páginas de manual, páginas de información, archivos LÉAME, etc.).

  • -c muestra una lista de archivos marcados como archivos de configuración. Estos son los archivos que usted cambia después de la instalación para adaptar el paquete a su sistema (como sendmail.cf, passwd, inittab, etc.).

En las opciones que muestran listas de archivos, puede añadir -v al comando para que muestre las listas en el mismo formato en que ls -l lo hace.

10.2.7. Verificación

La verificación de un paquete tiene que ver con comparar la información sobre archivos instalados de un paquete con la misma información del paquete original. Entre otras cosas, la verificación compara el tamaño, la suma MD5, los permisos, el tipo, el dueño y el grupo de cada archivo.

El comando rpm -V verifica un paquete. Puede utilizar cualquiera de las Opciones de verificación de paquete de la lista para pedir que se especifiquen los paquetes que desea verificar. Un modo sencillo de verificar es rpm -V foo, que verifica si todos los archivos en el paquete foo se encuentran en el mismo estado en que estaban cuando originalmente fueron instalados. Por ejemplo:

  • Para verificar un paquete que contiene un determinado archivo:

    rpm -Vf /usr/bin/foo
    

    En este ejemplo, /usr/bin/foo es la ruta absoluta del archivo utilizado para realizar la consulta del paquete.

  • Para verificar TODOS los paquetes instalados en el sistema:

    rpm -Va
    
  • Para verificar un paquete instalado contra un archivo de paquete RPM

    rpm -Vp foo-1.0-1.i386.rpm
    

    Este comando puede ser útil si sospecha que sus bases de datos de RPM están dañadas.

Si todo fue verificado correctamente no habrá ningún mensaje. Si se encuentran discrepancias, éstas serán mostradas. El formato de la salida es una cadena de ocho caracteres (una c identifica un archivo de configuración) seguido por el nombre del archivo. Cada uno de los ocho caracteres señala el resultado de una comparación entre un atributo del archivo con el valor de ese atributo escrito en la base de datos de RPM. Un sólo punto (.) significa que ha pasado la prueba. Los siguientes caracteres señalan que ciertas pruebas no han sido pasadas:

  • 5 — MD5 suma de verificación

  • S — tamaño de archivo

  • L — enlace simbólico

  • T — hora de modificación de archivo

  • D — dispositivo

  • U — usuario

  • G — grupo

  • M — modo (incluye permisos y tipos de archivos)

  • ? — archivo que no se puede leer

Si ve alguna salida, determinar si debería quitar o reinstalar el paquete o resolver el problema de otra manera.

10.3. Verificando la firma del paquete

Si desea verificar si algún paquete ha sido dañado o alterado examine sólo la suma md5 tecleando el siguiente comando en un intérprete de comandos de shell (sustituya <archivo-rpm> con el nombre de archivo de su paquete):

rpm -K --nosignature <archivo-rpm>

Aparecerá el mensaje <rpm-file>: md5 OK. Este breve mensaje significa que el archivo no ha sido dañado al momento de la descarga. Si desea un mensaje más detallado, reemplace -K por -Kvv en el comando.

Por otra parte, ¿cuán fiable es el desarrollador que creó el paquete? Si el paquete está firmado con la llaveGnuPG del desarrollador, sabrá que el desarrollador de verdad es quien dice ser.

Se puede firmar un paquete RPM usando la Gnu Privacy Guard (o GnuPG), para asegurarse de que el paquete descargado es de fiar.

GnuPG es una herramienta para comunicación segura; reemplaza completa y gratuitamente la tecnología de encriptación de PGP, un programa electrónico de privacidad. Con GnuPG usted puede autentificar la validez de los documentos y encriptar/desencriptar datos de y hacia otros destinatarios. Además, GnuPG es capaz de descifrar y verificar archivos PGP 5.x.

Durante la instalación, GnuPG se instala por defecto. De este modo podrá usar inmediatamente GnuPG para verificar cualquier paquete que reciba desde Red Hat. En primer lugar necesitará importar la llave pública privada de Red Hat.

10.3.1. Importar claves

Para verificar los paquetes de Red Hat tiene que importar la llave GPG de Red Hat. Para ello, ejecute el siguiente comando en el intérprete de comandos de shell:

rpm --import /usr/share/rhn/RPM-GPG-KEY

Para ver la lista de todas las claves isntaladas para la verificación de RPM, ejecute el comando:

rpm -qa gpg-pubkey*

Para la llave de Red Hat, la salida incluye:

gpg-pubkey-db42a60e-37ea5438

Para mostrar más detalles sobre una clave determinada, use rpm -qi seguido de la salida del anterior comando:

rpm -qi gpg-pubkey-db42a60e-37ea5438

10.3.2. Verificación de la firma de paquetes

Para verificar la firma GnuPG de un archivo RPM después de importar la clave GnuPG de la persona que construyó el RPM, use el siguiente comando (sustituya <archivo-rpm> con el nombre de archivo de su paquete RPM):

rpm -K <rpm-file>

Si todo va bien, verá el siguiente mensaje: md5 gpg OK. Esto significa que el paquete ha sido verificado y que no está dañado.

10.4. Ejemplos comunes y prácticos sobre el uso de RPM

RPM es una herramienta útil ya sea para administrar su sistema que para diagnosticar y solucionar problemas. La mejor manera de comprender todas sus opciones es viendo algunos ejemplos.

  • Tal vez usted haya borrado algunos archivos accidentalmente, pero no está seguro de lo que ha eliminado. Si desea verificar su sistema entero y ver lo que podría hacer falta, podría intentarlo con el siguiente comando:

    rpm -Va
    

    Si faltan algunos archivos o parecen dañados, probablemente debería reinstalar el paquete o desinstalarlo y luego reinstalarlo.

  • En algunas ocasiones podría encontrarse con un archivo que no reconoce. Para saber a qué paquete pertenece introduzca:

    rpm -qf /usr/bin/ggv
    

    La salida es parecida a lo siguiente:

    ggv-2.6.0-2
    
  • Podemos combinar los dos ejemplos de arriba en el siguiente escenario. Digamos que está teniendo problemas con /usr/bin/paste. Le gustaría verificar el paquete al cual pertenece ese programa pero no sabe a cuál paquete pertenece paste. Introduzca el siguiente comando:

    rpm -Vf /usr/bin/paste
    

    y se verificará el paquete correcto.

  • ¿Desea encontrar más información sobre un determinado programa? Puede intentar el siguiente comando para localizar la documentación que acompañaba el paquete al cual pertenece ese programa:

    rpm -qdf /usr/bin/free
    

    El mensaje de salida será similar al presentado a continuación:

    /usr/share/doc/procps-3.2.3/BUGS /usr/share/doc/procps-3.2.3/FAQ /usr/share/doc/procps-3.2.3/NEWS /usr/share/doc/procps-3.2.3/TODO /usr/share/man/man1/free.1.gz /usr/share/man/man1/pgrep.1.gz /usr/share/man/man1/pkill.1.gz /usr/share/man/man1/pmap.1.gz /usr/share/man/man1/ps.1.gz /usr/share/man/man1/skill.1.gz /usr/share/man/man1/slabtop.1.gz /usr/share/man/man1/snice.1.gz /usr/share/man/man1/tload.1.gz /usr/share/man/man1/top.1.gz /usr/share/man/man1/uptime.1.gz /usr/share/man/man1/w.1.gz /usr/share/man/man1/watch.1.gz /usr/share/man/man5/sysctl.conf.5.gz /usr/share/man/man8/sysctl.8.gz /usr/share/man/man8/vmstat.8.gz
    
  • Podría encontrar un RPM nuevo y no saber para qué sirve. Para encontrar información sobre él, use el siguiente comando:

    rpm -qip crontabs-1.10-7.noarch.rpm
    

    El mensaje de salida será similar al presentado a continuación:

     Name : crontabs Relocations: (not relocatable) Version : 1.10 Vendor: Red Hat, Inc. Release : 7 Build Date: Mon 20 Sep 2004 05:58:10 PM EDT Install Date: (not installed) Build Host: tweety.build.redhat.com Group : System Environment/Base Source RPM: crontabs-1.10-7.src.rpm Size : 1004 License: Public Domain Signature : DSA/SHA1, Wed 05 Jan 2005 06:05:25 PM EST, Key ID 219180cddb42a60e Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : Root crontab files used to schedule the execution of programs. Description : The crontabs package contains root crontab files. Crontab is the program used to install, uninstall, or list the tables used to drive the cron daemon. The cron daemon checks the crontab files to see when particular commands are scheduled to be executed. If commands are scheduled, then it executes them.
    
  • Quizás desea ver qué archivos instala el RPM crontabs. Ingrese lo siguiente:

    rpm -qlp crontabs-1.10-5.noarch.rpm
    

    La salida será de la siguiente manera:

     /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/crontab /usr/bin/run-parts
    

Estos son solamente algunos ejemplos. Al usar RPM descubrirá muchos más de sus posibles usos.

10.5. Recursos adicionales

RPM es una utilidad muy compleja con muchas opciones y métodos para efectuar consultas, instalar, actualizar y eliminar paquetes. Consulte los siguientes recursos para saber más sobre RPM.

10.5.1. La documentación instalada

  • rpm --help — este comando proporciona una referencia rápida de los parámetros de RPM.

  • man rpm — las páginas de manual de RPM le proporcionará más detalles sobre los parámetros de RPM que el comando rpm --help.

10.5.2. Sitios web útiles

10.5.3. Libros relacionados

  • Red Hat RPM Guide por Eric Foster-Johnson; Wiley, John & Sons, Incorporated — Este libro es un manual completo de RPM, desde la instalación de paquetes hasta la construcción de RPMs.

Capítulo 11. Herramienta de administración de paquetes

SI prefiere utilizar una interfaz gráfica para ver y administrar los paquetes de su sistema, puede utilizar la Herramienta de administración de paquetes, mejor conocida como pirut. Esta herramienta le permite ejecutar tareas básicas de administración de paquetes a través de una interfaz fácil de usar. Puede remover paquetes instalados o descargar (e instalar) paquetes compatibles con su sistema. También le permite ver qué paquetes han sido instalados en su sistema y cuales están disponibles para ser descargados de Red Hat Network. Además, cuando usted instala o remueve paquetes, la Herramienta de administración de paquetes también resuelve automáticamente cualquier dependencia crítica del mismo modo que el comando rpm.

Nota

Aunque la Herramienta de administración de paquetes puede resolver dependencias de forma automáticamente durante la instalación y remoción de paquetes, no puede forzar la instalación o remoción de paquetes como los comandos rpm -e --nodeps o rpm -U --nodeps lo hacen.

Se requiere el sistema de ventanas X para ejecutar la aplicación Herramienta de administración de paquetes. Para iniciar la aplicación, vaya aAplicaciones (en el Panel) => Añadir/Eliminar aplicaciones o escriba el comando system-config-packages o pirut en el intérprete de comandos.

Herramienta de Administración de Paquetes

Herramienta de Administración de Paquetes

Figura 11.1. Herramienta de Administración de Paquetes

11.1. Listar y analizar paquetes

Puede utilizar la Herramienta de administración de paquetes para buscar y listar todos los paquetes instalados en su sistema y aquellos disponibles para ser descargados. Las pestañas Navegar, Buscar y Listar muestran diferentes opciones para ver, analizar, instalar o remover paquetes.

La pestaña Navegar permite ver paquetes por grupos. En la Figura 11.1, “Herramienta de Administración de Paquetes”, el panel izquierdo muestra los diferentes tipos de grupos de paquetes que usted puede escoger (por ejemplo, Entorno de Escritorio, Aplicaciones, Desarrollo, etc.) Cuando un tipo de grupo de paquetes es seleccionado, el panel de la derecha muestra los diferentes grupos de paquetes de ese tipo.

Para ver los paquetes incluidos en un grupo de paquetes, haga clic en Paquetes opcionales. Los paquetes instalados están seleccionados.

Paquetes Opcionales

Paquetes Opcionales

Figura 11.2. Paquetes Opcionales

La pestaña Listar muestra una lista de los paquetes instalados o disponibles para ser descargados. Los paquetes ya instalados en su sistema están marcados con un visto bueno de color verde ( ).

La opción Todos los paquetes está seleccionada por defecto. Esta opción especifica que todos los paquetes deben ser mostrados. Utilice Paquetes instalados para ver los paquetes que ya han sido instalados en su sistema. La opción Paquetes disponibles muestra los paquetes que pueden ser descargados e instalados.

La pestaña Buscar le permite utilizar palabras claves para buscar paquetes en particular. Esta pestaña también le permite ver una corta descripción de los paquetes. Para ver dicha descripción, seleccione un paquete y haga clic en Detalles del paquete bajo la ventana principal.

11.2. Instalación y Eliminación de paquetes

Para instalar un paquete disponible, haga clic en la casilla de verificación del nombre del paquete. Una vez hecho, un icono de instalación ( ) aparecerá al lado de la casilla de verificación. Este icono indica que el paquete está en la lista de paquetes a descargar e instalar. Usted puede escoger varios paquetes para descargar e instalar. Una vez haya terminado de seleccionar los paquetes a instalar, haga clic en el botón Aplicar.

Instalación de Paquetes

Instalación de Paquetes

Figura 11.3. Instalación de Paquetes

La Herramienta de administración de paquetes notificará cualquier dependencia de paquetes de los paquetes seleccionados. Haga clic en Detalles para ver qué paquetes adicionales son necesarios. Para proceder con las descargas e instalar los paquetes (incluyendo sus dependencias) haga clic en Continuar.

Dependencia de paquetes: instalación

Dependencia de paquetes: instalación

Figura 11.4. Dependencia de paquetes: instalación

Para remover un paquete instalado en su sistema, haga clic en la casilla de verificación al lado del nombre del paquete. Aparecerá un icono de remoción de paquetes ( ) al lado del nombre del paquete. Esto indica que el paquete está en la lista de paquetes a ser removidos. Puede seleccionar varios paquetes al mismo tiempo. Una vez haya terminado la selección, haga clic en el botón Aplicar.

Eliminación de paquetes

Eliminación de paquetes

Figura 11.5. Eliminación de paquetes

Tenga en cuenta que si cualquier paquete depende del paquete que está removiendo, éstos serán también removidos. La Herramienta de administración de paquetes le notificará si hay alguna dependencia. Haga clic en Detalles para ver los paquetes que dependen del paquete que está removiendo. Para remover los paquetes seleccionados (y las dependencias) haga clic en Continuar.

Dependencia de paquetes: remoción

Dependencia de paquetes: remoción

Figura 11.6. Dependencia de paquetes: remoción

Puede combinar la instalación y eliminación de paquetes al seleccionar los grupos de paquetes que serán instalados o eliminados y pulsar Aplicar. La ventana Selección de paquetes muestra el número de paquetes a instalar y remover.

Instalación y remoción simultánea de paquetes

Instalación y remoción simultanea de paquetes

Figura 11.7. Instalación y remoción simultánea de paquetes

Capítulo 12. YUM (Yellowdog Updater Modified)

Yellowdog Update, Modified (YUM) is a package manager that was developed by Duke University to improve the installation of RPMs. yum searches numerous repositories for packages and their dependencies so they may be installed together in an effort to alleviate dependency issues. Red Hat Enterprise Linux 5.2 uses yum to fetch packages and install RPMs.

up2date is now deprecated in favor of yum (Yellowdog Updater Modified). The entire stack of tools which installs and updates software in Red Hat Enterprise Linux 5.2 is now based on yum. This includes everything, from the initial installation via Anaconda to host software management tools like pirut.

yum also allows system administrators to configure a local (i.e. available over a local network) repository to supplement packages provided by Red Hat. This is useful for user groups that use applications and packages that are not officially supported by Red Hat.

Aside from being able to supplement available packages for local users, using a local yum repository also saves bandwidth for the entire network. Further, clients that use local yum repositories do not need to be registered individually to install or update the latest packages from Red Hat Network.

12.1. Setting Up a yum Repository

To set up a repository, follow these steps:

Procedimiento 12.1. Setting Up a yum Repository
  1. Install the createrepo package.

  2. Copy all the packages into one directory (for example, /mnt/local_repo).

  3. Run createrepo on that directory (for example, createrepo /mnt/local_repo). This will create the necessary metadata for your yum repository.

12.2. yum Commands

yum commands are typically run as yum <command> <package name/s>. By default, yum will automatically attempt to check all configured repositories to resolve all package dependencies during an installation/upgrade.

The following is a list of the most commonly-used yum commands. For a complete list of available yum commands, refer to man yum.

yum install <package name/s>

Used to install the latest version of a package or group of packages. If no package matches the specified package name(s), they are assumed to be a shell glob, and any matches are then installed.

yum update <package name/s>

Used to update the specified packages to the latest available version. If no package name/s are specified, then yum will attempt to update all installed packages.

If the --obsoletes option is used (i.e. yum --obsoletes <package name/s>, yum will process obsolete packages. As such, packages that are obsoleted accross updates will be removed and replaced accordingly.

yum check-update

This command allows you to determine whether any updates are available for your installed packages. yum returns a list of all package updates from all repositories if any are available.

yum remove <package name/s>

Used to remove specified packages, along with any other packages dependent on the packages being removed.

yum provides <file name>

Used to determine which packages provide a specific file or feature.

yum search <keyword>

This command is used to find any packages containing the specified keyword in the description, summary, packager and package name fields of RPMs in all repositories.

yum localinstall <absolute path to package name/s>

Used when using yum to install a package located locally in the machine.

12.3. yum Options

yum options are typically stated before specific yum commands; i.e. yum <options> <command> <package name/s>. Most of these options can be set as default using the configuration file.

The following is a list of the most commonly-used yum options. For a complete list of available yum options, refer to man yum.

-y

Answer "yes" to every question in the transaction.

-t

Sets yum to be "tolerant" of errors with regard to packages specified in the transaction. For example, if you run yum update package1 package2 and package2 is already installed, yum will continue to install package1.

--exclude=<package name>

Excludes a specific package by name or glob in a specific transaction.

12.4. Configuring yum

By default, yum is configured through /etc/yum.conf. The following is an example of a typical /etc/yum.conf file:

[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800

[myrepo]
name=RHEL 5 $releasever - $basearch
baseurl=http://local/path/to/yum/repository/
enabled=1

A typical /etc/yum.conf file is made up of two types of sections: a [main] section, and a repository section. There can only be one [main] section, but you can specify multiple repositories in a single /etc/yum.conf.

12.4.1. [main] Options

The [main] section is mandatory, and there must only be one. For a complete list of options you can use in the [main] section, refer to man yum.conf.

The following is a list of the most commonly-used options in the [main] section.

cachedir

This option specifies the directory where yum should store its cache and database files. By default, the cache directory of yum is /var/cache/yum.

keepcache=<1 or 0>

Setting keepcache=1 instructs yum to keep the cache of headers and packages after a successful installation. keepcache=1 is the default.

reposdir=<absolute path to directory of .repo files>

This option allows you to specify a directory where .repo files are located. .repo files contain repository information (similar to the [repository] section of /etc/yum.conf).

yum collects all repository information from .repo files and the [repository] section of the /etc/yum.conf file to create a master list of repositories to use for each transaction. Refer to Sección 12.4.2, “[repository] Options” for more information about options you can use for both the [repository] section and .repo files.

If reposdir is not set, yum uses the default directory /etc/yum.repos.d.

gpgcheck=<1 or 0>

This disables/enables GPG signature checking on packages on all repositories, including local package installation. The default is gpgcheck=0, which disables GPG checking.

If this option is set in the [main] section of the /etc/yum.conf file, it sets the GPG checking rule for all repositories. However, you can also set this on individual repositories instead; i.e., you can enable GPG checking on one repository while disabling it on another.

assumeyes=<1 or 0>

This determines whether or not yum should prompt for confirmation of critical actions. The default if assumeyes=0, which means yum will prompt you for confirmation.

If assumeyes=1 is set, yum behaves in the same way that the command line option -y does.

tolerant=<1 or 0>

When enabled (tolerant=1), yum will be tolerant of errors on the command line with regard to packages. This is similar to the yum command line option -t.

The default value for this is tolerant=0 (not tolerant).

exclude=<package name/s>

This option allows you to exclude packages by keyword during installation/updates. If you are specifying multiple packages, this is a space-delimited list. Shell globs using wildcards (for example, * and ?) are allowed.

retries=<number of retries>

This sets the number of times yum should attempt to retrieve a file before returning an error. Setting this to 0 makes yum retry forever. The default value is 6.

12.4.2. [repository] Options

The [repository] section of the /etc/yum.conf file contains information about a repository yum can use to find packages during package installation, updating and dependency resolution. A repository entry takes the following form:

[repository ID]
name=repository name
baseurl=url, file or ftp://path to repository

You can also specify repository information in a separate .repo files (for example, rhel5.repo). The format of repository information placed in .repo files is identical with the [repository] of /etc/yum.conf.

.repo files are typically placed in /etc/yum.repos.d, unless you specify a different repository path in the [main] section of /etc/yum.conf with reposdir=. .repo files and the /etc/yum.conf file can contain multiple repository entries.

Each repository entry consists of the following mandatory parts:

[repository ID]

The repository ID is a unique, one-word string that serves as a repository identifier.

name=repository name

This is a human-readable string describing the repository.

baseurl=http, file or ftp://path

This is a URL to the directory where the repodatadirectory of a repository is located. If the repository is local to the machine, use baseurl=file://path to local repository. If the repository is located online using HTTP, use baseurl=http://link. If the repository is online and uses FTP, use baseurl=ftp://link.

If a specific online repository requires basic HTTP authentication, you can specify your username and password in the baseurl line by prepending it as username:password@link. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password os "password", then the baseurl link can be specified as baseurl=http://user:password@www.example.com/repo/.

The following is a list of options most commonly used in repository entries. For a complete list of repository entries, refer to man yum.conf.

gpgcheck=<1 or 0>

This disables/enables GPG signature checking a specific repository. The default is gpgcheck=0, which disables GPG checking.

gpgkey=URL

This option allows you to point to a URL of the ASCII-armoured GPG key file for a repository. This option is normally used if yum needs a public key to verify a package and the required key was not imported into the RPM database.

If this option is set, yum will automatically import the key from the specified URL. You will be prompted before the key is installed unless you set assumeyes=1 (in the [main] section of /etc/yum.conf) or -y (in a yum transaction).

exclude=<package name/s>

This option is similar to the exclude option in the [main] section of /etc/yum.conf. However, it only applies to the repository in which it is specified.

includepkgs=<package name/s>

This option is the opposite of exclude. When this option is set on a repository, yum will only be able to see the specified packages in that repository. By default, all packages in a repository are visible to yum.

12.5. Useful yum Variables

The following is a list of variables you can use for both yum commands and yum configuration files (i.e. /etc/yum.conf and .repo files).

$releasever

This is replaced with the package's version, as listed in distroverpkg. This defaults to the version of the redhat-release package.

$arch

This is replaced with your system's architecture, as listed by os.uname() in Python.

$basearch

This is replaced with your base architecture. For example, if $arch=i686 then $basearch=i386.

$YUM0-9

This is replaced with the value of the shell environment variable of the same name. If the shell environment variable does not exist, then the configuration file variable will not be replaced.

Capítulo 13. Red Hat Network

Red Hat Network es una solución de Internet para administrar uno o más sistemas Red Hat Enterprise Linux. Todos los parches de seguridad, correcciones de errores y mejoras en los paquetes (conocidas usualmente como Alertas de Erratas), pueden ser descargadas directamente desde Red Hat usando la aplicación Actualizador de software o a través del sitio web de RHN en http://rhn.redhat.com/.

Su RHN

Su RHN

Figura 13.1. Su RHN

Red Hat Network le ahorra tiempo, ya que usted recibe un correo-e tan pronto como una actualización de paquetes está disponible. No tienen que buscar en la web por los paquetes actualizados o alertas de seguridad. Por defecto, Red Hat Network instala también los paquetes, de esta manera, usted no tienen que saber como usar RPM o preocuparse por resolver las dependencias de los paquetes de software. RHN lo hace por usted.

Las funcionalidades de Red Hat Network incluyen:

  • Alertas de erratas — entérese de cuando están disponibles los parches de seguridad, las correcciones de errores y las mejoras de paquetes para todos los sistemas en su red

    Erratas de importancia

    Erratas de importancia

    Figura 13.2. Erratas de importancia

  • Notificaciones automáticas de correo — reciba una notificación de correo-e cuando una nueva alerta de errata para su sistema es producida.

  • Actualizaciones planificadas de errata — planifique la entrega de actualizaciones de errata.

  • Instalación de paquetes — planifique la instalación de paquetes en uno o más sistemas con el click de un botón.

  • El Actualizador de software — use el Actualizador de software para descargar los últimos paquetes de software para su sistema (con instalación de paquetes automática opcional)

  • Sitio web de Red Hat Network — administre sistemas múltiples, descargue paquetes individuales y planifique acciones tales como las actualización de errata a través de una conexión segura al web desde cualquier computador.

Atención

Debe activar su producto Red Hat Enterprise Linux antes de registrar su sistema con Red Hat Network para asegurarse de que su sistema tiene derecho a los servicios correctos. Para activar su producto, vaya a:

http://www.redhat.com/apps/activate/

Después de activar su producto, regístrelo con Red Hat Network para recibir las actualizaciones de erratas. El proceso de registro reune información sobre el sistema necesarias para realizar las notificaciones de actualización. Por ejemplo, se compila una lista de los paquetes instalados en su sistema para que de esta manera solamente se le notifique sobre las actualizaciones que son relevantes a su sistema.

La primera vez que su sistema se inicia, el Asistente de registro para actualización de software le pedirá que se registre. Si no se registró en ese momento, seleccione el botón del Aplicaciones => Herramientas del sistema => Actualizador de software en su escritorio para iniciar el proceso de registro. Alternativamente, ejecute el comando yum update desde el intérprete de comandos.

Registrarse con RHN

Registrarse con RHN

Figura 13.3. Registrarse con RHN

Después de registrarse, utilice uno de los métodos siguientes para comenzar a recibir las actualizaciones:

  • Seleccione Aplicaciones => Herramientas del sistema => Actualizador de software en su escritorio para iniciar el proceso de registro.

  • Ejecute el comando yum desde el intérprete de comandos.

  • Utilice el sitio web de RHN en https://rhn.redhat.com/.

  • Haga clic en el icono que aparece en el panel para lanzar el Actualizador de software.

Para instrucciones detalladas, consulte la documentación siguiente disponible en:

http://www.redhat.com/docs/manuals/RHNetwork/

Sugerencia

Red Hat Enterprise Linux incluye un icono del panel que muestra señales visibles cuando hay alguna actualización disponible para su sistema Red Hat Enterprise Linux. Este icono no está presente si no hay actualizaciones disponibles..

Parte III. Configuración relacionada a la red

Después de explicar cómo configurar la red, esta parte discute temas relacionados a redes, tales como permitir las conexiones remotas, compartir archivos y directorios sobre la red y la configuración de un servidor Web.

Tabla de contenidos

14. Interfaces de red
14.1. Archivos de configuración de red
14.2. Archivos de configuración de interfaz
14.2.1. Interfaces Ethernet
14.2.2. Interfaces IPsec
14.2.3. Interfaces de unión de canales
14.2.4. Archivos alias y clon
14.2.5. Interfaces de acceso telefónico
14.2.6. Otras interfaces
14.3. Scripts de control de interfaz
14.4. Configuring Static Routes
14.5. Archivos de funciones de red
14.6. Recursos adicionales
14.6.1. Documentación instalada
15. Configuración de la red
15.1. Resumen
15.2. Conexión Ethernet
15.3. Conexión RDSI
15.4. Conexión vía módem
15.5. Conexión xDSL
15.6. Conexión Token Ring
15.7. Conexión de tipo inalámbrica
15.8. Administración de los parámetros DNS
15.9. Administración de hosts
15.10. Funcionamiento con perfiles
15.11. Alias de dispositivo
15.12. Guardar y recuperar la configuración de la red
16. Control de acceso a servicios
16.1. Niveles de ejecución
16.2. TCP Wrappers
16.2.1. xinetd
16.3. Herramienta de configuración de servicios
16.4. ntsysv
16.5. chkconfig
16.6. Recursos adicionales
16.6.1. Documentación instalada
16.6.2. Sitios Web útiles
17. Berkeley Internet Name Domain (BIND)
17.1. Introducción a DNS
17.1.1. Zonas de servidores de nombres
17.1.2. Tipos de servidores de nombres
17.1.3. BIND como un servidor de nombres
17.2. /etc/named.conf
17.2.1. Tipos de declaraciones comúnes
17.2.2. Otros tipos de declaraciones
17.2.3. Etiquetas de comentarios
17.3. Archivos de zona
17.3.1. Directivas de archivos de zona
17.3.2. Registros de recursos de archivos de zona
17.3.3. Ejemplo de archivo de zonas
17.3.4. Archivos de zona de resolución de nombres inversa
17.4. Uso de rndc
17.4.1. Configuración de /etc/named.conf
17.4.2. Configuración de /etc/rndc.conf
17.4.3. Opciones de línea de comandos
17.5. Características avanzadas de BIND
17.5.1. Mejoras al protocolo DNS
17.5.2. Vistas múltiples
17.5.3. Seguridad
17.5.4. IP versión 6
17.6. Errores comunes que debe evitar
17.7. Recursos adicionales
17.7.1. Documentación instalada
17.7.2. Sitios web de utilidad
17.7.3. Libros relacionados
18. OpenSSH
18.1. Características de SSH
18.1.1. ¿Por qué usar SSH?
18.2. Versiones del protocolo SSH
18.3. Secuencia de eventos de una conexión SSH
18.3.1. Capa de transporte
18.3.2. Autenticación
18.3.3. Canales
18.4. Configurar un servidor OpenSSH
18.4.1. Requiriendo SSH para conexiones remotas
18.5. Archivos de configuración de OpenSSH
18.6. Configuración de un cliente OpenSSH
18.6.1. Uso del comando ssh
18.6.2. Usando el comando scp
18.6.3. Uso del comando sftp
18.7. Más que un Shell seguro
18.7.1. Reenvío por X11
18.7.2. Reenvío del puerto
18.7.3. Generar pares de claves
18.8. Recursos adicionales
18.8.1. Documentación instalada
18.8.2. Sitios web útiles
19. Sistema de archivos de red (NFS)
19.1. Funcionamiento
19.1.1. Servicios requeridos
19.2. Configuración de clientes NFS
19.2.1. Montaje del sistemas de archivos NFS con /etc/fstab
19.3. autofs
19.3.1. Nuevas características de la versión 5 de autofs
19.3.2. Configuración de autofs
19.3.3. Tareas comunes autofs
19.4. Opciones de montaje NFS comunes
19.5. Iniciar y detener NFS
19.6. Configuración del servidor NFS
19.6.1. Exportar o compartir sistemas de archivos NFS
19.6.2. Configuración desde la línea de comandos
19.6.3. Formatos del nombre de host
19.7. El archivo de configuración /etc/exports
19.7.1. El comando exportfs
19.8. Protección de NFS
19.8.1. Acceso al sistema
19.8.2. Permisos de archivos
19.9. NFS y portmap
19.9.1. Solución de problemas de NFS y portmap
19.10. Uso de NFSv4 sobre TCP
19.11. Recursos adicionales
19.11.1. Documentación instalada
19.11.2. Sitios Web útiles
19.11.3. Libros sobre el tema
20. Samba
20.1. Introducción a Samba
20.1.1. Características de Samba
20.2. Demonios Samba y Servicios relacionados
20.2.1. Demonios Samba
20.3. Conexión a un recurso compartido Samba
20.3.1. Línea de comandos
20.3.2. Montar el recurso compartido Samba
20.4. Configuración del servidor Samba
20.4.1. Configuración gráfica
20.4.2. Configuración desde la línea de comandos
20.4.3. Contraseñas encriptadas
20.5. Arrancar y detener el Samba
20.6. Tipos de servidores Samba y el archivo smb.conf
20.6.1. Servidor independiente
20.6.2. Servidor miembro de dominio
20.6.3. Domain Controller
20.7. Modos de seguridad Samba
20.7.1. Seguridad a nivel de usuario
20.7.2. Seguridad a nivel de usuarios
20.8. Bases de datos de información de cuentas Samba
20.9. Navegación de red con Samba
20.9.1. Navegación de dominios
20.9.2. WINS (Windows Internetworking Name Server)
20.10. Samba con soporte para la impresión con CUPS
20.10.1. Configuraciones simples de smb.conf
20.11. Programas de distribución Samba
20.12. Recursos adicionales
20.12.1. Documentación instalada
20.12.2. Libros relacionados
20.12.3. Sitios web útiles
21. Protocolo de Configuración Dinámica de Hosts (DHCP)
21.1. Motivos para usar el protocolo DHCP
21.2. Configuración de un servidor DHCP
21.2.1. Archivo de configuración
21.2.2. Base de datos de arrendamiento
21.2.3. Iniciar y detener el servidor
21.2.4. Agente de transmisión DHCP
21.3. Configuración de un cliente DHCP
21.4. Recursos adicionales
21.4.1. Documentación instalada
22. Servidor HTTP Apache
22.1. Servidor HTTP Apache Versión 2.2
22.1.1. Características del Servidor HTTP Apache Versión 2.2
22.2. Migración de los Archivos de Configuración del Servidor HTTP Apache
22.2.1. Migración de los Archivos de Configuración del Servidor HTTP Apache Versión 2.0.
22.2.2. Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0
22.3. Arrancar y detener httpd
22.4. Configuración del Servidor HTTP Apache
22.4.1. Configuración Básica
22.4.2. Configuraciones predeterminadas
22.5. Directrices de configuración en httpd.conf
22.5.1. Sugerencias de configuración generales
22.5.2. Configuración de directrices para SSL
22.5.3. Directrices MPM específicas al pool de servidores
22.6. Añadir módulos
22.7. Hosts virtuales
22.7.1. Configuración de máquinas virtuales
22.8. Configuración del Servidor Seguro Apache HTTP
22.8.1. Vista preliminar de los paquetes relacionados con la seguridad
22.8.2. Vista preliminar de certificados y seguridad
22.8.3. Uso de claves y certificados preexistentes
22.8.4. Tipos de certificados
22.8.5. Generar una clave
22.8.6. Cómo configurar el servidor para utilizar la nueva clave
22.9. Recursos adicionales
22.9.1. Sitios Web de utilidad
23. FTP
23.1. El Protocolo de Transferencia de Archivos
23.1.1. Puertos múltiples, modos múltiples
23.2. Servidores FTP
23.2.1. vsftpd
23.3. Archivos instalados con vsftpd
23.4. Iniciar y detener vsftpd
23.4.1. Iniciar múltiples copias de vsftpd
23.5. Opciones de configuración vsftpd
23.5.1. Opciones de demonios
23.5.2. Opciones de conexión y control de acceso
23.5.3. Opciones de usuario anónimo
23.5.4. Opciones del usuario local
23.5.5. Opciones de directorio
23.5.6. Opciones de transferencia de archivos
23.5.7. Opciones de conexión
23.5.8. Opciones de red
23.6. Recursos adicionales
23.6.1. Documentación instalada
23.6.2. Sitios web de utilidad
24. Correo electrónico
24.1. Protocolos de correo electrónico
24.1.1. Protocolos de transporte de correo
24.1.2. Protocolos de acceso a correo
24.2. Clasificaciones de los programas de correo
24.2.1. Agente de Transporte de Correo
24.2.2. Agente de entrega de correos
24.2.3. Agente de usuario de correo
24.3. Agentes de transporte de correo
24.3.1. Sendmail
24.3.2. Postfix
24.3.3. Fetchmail
24.4. Configuración del Agente de Transporte de Correo (MTA)
24.5. Agente de entrega de correo
24.5.1. Configuración de Procmail
24.5.2. Recetas de Procmail
24.6. Agentes de usuario de correo
24.6.1. Comunicación segura
24.7. Recursos adicionales
24.7.1. Documentación instalada
24.7.2. Sitios web útiles
24.7.3. Libros relacionados
25. Protocolo Ligero de Acceso a Directorios (LDAP)
25.1. Razones por las cuales usar LDAP
25.1.1. Características de OpenLDAP
25.2. Terminología LDAP
25.3. Demonios y utilidades OpenLDAP
25.3.1. NSS, PAM, y LDAP
25.3.2. PHP4, LDAP y el Servidor HTTP Apache
25.3.3. Aplicaciones cliente LDAP
25.4. Archivos de configuración de OpenLDAP
25.5. El directorio /etc/openldap/schema/
25.6. Descripción general de la configuración de OpenLDAP
25.6.1. Modificar /etc/openldap/slapd.conf
25.7. Configurar un sistema para la autenticación mediante OpenLDAP
25.7.1. PAM y LDAP
25.7.2. Migrar la información de autenticación antigua al formato LDAP
25.8. Migración de directorios desde versiones anteriores
25.9. Recursos adicionales
25.9.1. Documentación instalada
25.9.2. Sitios web útiles
25.9.3. Libros relacionados
26. Configuración de la autenticación
26.1. Información del usuario
26.2. Autenticación
26.3. Options
26.4. Versión de línea de comandos

Capítulo 14. Interfaces de red

Bajo Red Hat Enterprise Linux, todas las comunicaciones de red acontecen entre interfaces de software configuradas y dispositivos de red físicos conectados al sistema.

Los archivos de configuración para las interfaces de red y los scripts para activarlas o desactivarlas están ubicados en el directorio /etc/sysconfig/network-scripts. Aún cuando el número y tipo de archivos de interfaces pueden diferir de sistema a sistema, hay tres categorías de archivos que existen en este directorio.

  1. Archivos de configuración de interfaz

  2. Scripts de control de interfaz

  3. Archivos de funciones de red

Los archivos en cada una de estas categorías trabajan juntos para habilitar varios dispositivos de red.

Este capítulo explora la relación entre estos archivos y cómo son utilizados.

14.1. Archivos de configuración de red

Antes de ahondar en los archivos de configuración de interfaz, hagamos una lista de los principales archivos de configuración usados en la configuración de la red. La comprensión del papel que desempeñan estos archivos en la configuración de la red puede ser de ayuda a la hora de personalizar un sistema Red Hat Enterprise Linux.

Los principales archivos de configuración de la red son los siguientes:

/etc/hosts

El principal propóposito de este archivo es resolver los nombres de hosts que no pueden ser resueltos de otra manera. También se puede usar para resolver nombres de hosts en pequeñas redes sin servidor DNS. Sin tener en cuenta el tipo de red en que se encuentre el ordenador, este archivo debe contener un línea que especifica la dirección IP del dispositivo loopback (127.0.0.1) como por ejemplo localhost.localdomain. Para mayor información consulte la página man de hosts.

/etc/resolv.conf

Este archivo especifica las direcciones IP de los servidores DNS y el dominio de búsqueda. A menos que se haya configurado para algo diferente, los scripts de inicialización de la red llenan este archivo. Para mayor información consulte la página man de resolv.conf.

/etc/sysconfig/network-scripts/ifcfg-<nombre-de-interfaz>

Para cada interfaz de red existe un script de configuración de interfaz correspondiente. Cada uno de estos archivos proporciona información específica para una interfaz de red determinada. Consulte la Sección 14.2, “Archivos de configuración de interfaz” para obtener mayor información sobre este tipo de archivo y las directrices que acepta.

Aviso

La Herramienta de administración de red (system-config-network) utiliza el directorio /etc/sysconfig/networking/. Sus contenidos no deberían modificarse manualmente. Se recomienda utilizar solamente un método para la configuración de red debido al riesgo que se corre de borrar la configuración.

14.2. Archivos de configuración de interfaz

Los archivos de configuración de interfaz controlan las interfaces de software para dispositivos de red individuales. Cuando su sistema arranca, utiliza estos archivos para saber qué interfaces debe activar y cómo deben ser configuradas. Estos archivos habitualmente se conocen como ifcfg-<nombre>, donde <nombre> hace referencia al nombre del dispositivo que controla el archivo de configuración.

14.2.1. Interfaces Ethernet

Uno de los archivos de interfaz más comunes es ifcfg-eth0, que controla la primera tarjeta de interfaz de red Ethernet o NIC en el sistema. Un sistema con múltiples NICs tendrá varios archivos ifcfg-eth<X>, (donde <X> es un número único correspondiente a una interfaz específica). Como cada dispositivo tiene su propio archivo de configuración, un administrador podrá controlar la forma como cada interfaz funciona individualmente.

El siguiente es un ejemplo de un archivo ifcfg-eth0 para un sistema que usa una dirección IP fija:

DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no

Los valores requeridos en un archivo de configuración de interfaz pueden cambiar basándose en otros valores. Por ejemplo, el archivo ifcfg-eth0 para una interfaz que use DHCP se verá bastante diferente ya que la información IP es proporcionada por el servidor DHCP:

DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes

Sin embargo, también es posible modificar manualmente los archivos de configuración para una interfaz de red dada.

Abajo hay un listado de los parámetros configurables en un archivo de configuración de interfaz Ethernet.

BONDING_OPTS=<parámetros>

sets the configuration parameters for the bonding device, and is used in /etc/sysconfig/network-scripts/ifcfg-bond<N> (see Sección 14.2.3, “Interfaces de unión de canales”). These parameters are identical to those used for bonding devices in /sys/class/net/<bonding device>/bonding, and the module parameters for the bonding driver as described in bonding Module Directives.

Este método de configuración es utilizado para que varios dispositivos de vinculación puedan tener diferentes configuraciones. Si utiliza BONDING_OPTS en ifcfg-<nombre>, no utilice /etc/modprobe.conf para especificar las opciones del dispositivo de vinculación.

BOOTPROTO=<protocolo>

donde <protocolo> es uno de los siguientes:

  • none — No se debería utilizar ningún protocolo de tiempo de arranque.

  • bootp — Se debería utilizar el protocolo BOOTP.

  • dhcp — Se debería utilizar el protocolo DHCP.

BROADCAST=<dirección>

donde <dirección> es la dirección de difusión. Esta directriz ha sido descontinuada, pues el valor es calculado automáticamente con ifcalc.

DEVICE=<nombre>

donde <nombre> es el nombre del dispositivo físico (a excepción de los dispositivos PPP asignados de forma dinámica en donde éste es el nombre lógico).

DHCP_HOSTNAME

Solamente utilice esta opción si el servidor DHCP requiere que el cliente especifique un nombre de host antes de recibir una dirección IP.

DNS{1,2}=<dirección>

donde <dirección> es la dirección del servidor de nombres que se tiene que colocar en /etc/resolv.conf si la directriz PEERDNS es yes.

ETHTOOL_OPTS=<opciones>

donde <opciones> son cualquiera de las opciones específicas del dispositivo soportadas por ethtool. Por ejemplo, si desea forzar a 100Mb, full duplex:

ETHTOOL_OPTS="autoneg off speed 100 duplex full"

Instead of a custom initscript, use ETHTOOL_OPTS to set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.

Nota

Tenga en cuenta que para cambiar la velocidad o las configuraciones de dúplex se necesita desactivar la negociación automática con la opción autoneg off. Es necesario iniciar esta opción primero, pues las entradas para las opciones dependen del orden.

GATEWAY=<dirección>

donde <dirección> es la dirección IP del enrutador o dipositivo de puerta de enlace (si existe).

HWADDR=<dirección-MAC>

donde <dirección-MAC> es la dirección de hardware del dispositivo Ethernet en la forma de AA:BB:CC:DD:EE:FF. Esta directriz es útil en las máquinas con múltiples NICs para asegurarse de que a las interfaces se les asignen los nombres correctos de dispositivos sin importar el orden de carga configurado para cada módulo NIC. Esta directriz no debería ser usada en conjunto con MACADDR.

IPADDR=<dirección>

donde <dirección> es la dirección IP.

MACADDR=<dirección-MAC>

donde <dirección-MAC> es la dirección de hardware del dispositivo Ethernet en la forma de AA:BB:CC:DD:EE:FF. Esta directriz es utilizada para asignar una dirección MAC a una interfaz, ignorando la asignada a la NIC física. Esta directriz no debería ser usada en conjunto con HWADDR.

MASTER=<interfaz-vínculo>

donde <interfaz-vínculo> es la interfaz de unión de canales a la cual la interfaz Ethernet está vinculada.

Esta directriz es usada en conjunto con la directriz SLAVE.

Consulte la Sección 14.2.3, “Interfaces de unión de canales” para obtener mayor información sobre las interfaces de unión de canales.

NETMASK=<máscara>

donde <máscara> es el valor de la máscara de red.

NETWORK=<dirección>

donde <dirección> es la dirección de red. Esta directriz ya no se usa, el valor es calculado automáticamente con ifcalc.

ONBOOT=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — El dispositivo debería activarse en el momento de arranque.

  • no — Este dispositivo no debería activarse en el momento de arranque.

PEERDNS=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — Modifica /etc/resolv.conf si está activada la directriz DNS. Si está usando DCHP, la opción yes es la predeterminada.

  • no — No modificar /etc/resolv.conf.

SLAVE=<interfaz-vínculo>

donde <interfaz-vínculo> es una de las siguientes:

  • yes — Este dispositivo es controlado por la interfaz de unión de canales especificado en la directriz MASTER.

  • no — Este dispositivo no es controlado por la interfaz de unión de canales especificada en la directriz MASTER.

Esta directriz es usada en conjunto con la directriz MASTER.

Consulte la Sección 14.2.3, “Interfaces de unión de canales” para obtener más detalles sobre las interfaces de unión de canales.

SRCADDR=<dirección>

donde <dirección> es la dirección IP de la fuente específica para los paquetes salientes.

USERCTL=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — Los usuarios que no sean root pueden controlar este dispositivo.

  • no — No se les permite controlar este dispositivo a los usuarios que no sean root.

14.2.2. Interfaces IPsec

El ejemplo siguiente muestra un archivo ifcfg para una conexión de red-a-red IPsec para la LAN A. El nombre único para identificar la conexión en este ejemplo es ipsec1, por lo que el archivo resultante se llama /etc/sysconfig/network-scripts/ifcfg-ipsec1.

TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X

En el ejemplo anterior, X.X.X.X es la dirección IP enrutable públicamente del enrutador IPsec de destino.

A continuación se presenta un listado de los parámetros configurables para una interfaz IPsec:

DST=<dirección>

donde <dirección> es la dirección IP del host o enrutador IPsec destino. Esto se utiliza tanto para configuraciones IPsec host-a-host como para configuraciones red-a-red.

DSTNET=<red>

donde <red> es la dirección de red de la red IPsec destino. Esto solamente se utiliza para configuraciones de red-a-red IPsec.

SRC=<dirección>

donde <dirección> es la dirección IP del enrutador o host fuente IPsec. Esta configuración es opcional y solamente es utilizada para las configuraciones IPsec host-a-host.

SRCNET=<red>

donde <red> es la dirección de red de la red IPsec fuente. Esto solamente se utiliza para las configuraciones IPsec de red-a-red.

TYPE=<tipo-interfaz>

donde <tipo-interfaz> es IPSEC. Ambas aplicaciones son parte del paquete ipsec-tools.

Si se utiliza la encriptación de llaves manual con IPsec, consulte /usr/share/doc/initscripts-<número-versión>/sysconfig.txt (reemplace <número-versión> con la versión del paquete initscripts instalado) para los parámetros de la configuración.

El demonio de manejo de llaves IKEv1 racoon negocia y configura un conjunto de parámetros para IPSec. Puede utilizar llaves previamente compartidas, firmas RSA o GSS-API. Si se utiliza racoon para manejar automáticamente la encriptación de llaves, se requieren las opciones siguientes:

IKE_METHOD=<método-encriptación>

donde <método-encriptación> es, o bien PSK, X509 o GSSAPI. Si se especifica PSK, también se debe configurar el parámetro IKE_PSK. Si se especifica X509, se debe especificar el parámetro IKE_CERTFILE.

IKE_PSK=<llave-compartida>

donde <llave-compartida> es el valor secreto y compartido para el método PSK (llaves pre-compartidas).

IKE_CERTFILE=<archivo-cert>

donde <archivo-cert> es un archivo de certificado X.509 válido para el host.

IKE_PEER_CERTFILE=<archivo-cert>

donde <archivo-cert> es un certificado X.509 válido para el host remoto.

IKE_DNSSEC=<respuesta>

donde <respuesta> es yes. El demonio racoon recupera el certificado X.509 del host remoto a través de DNS. Si se especifica IKE_PEER_CERTFILE, no incluya este parámetro.

Para más información sobre los algoritmos de encriptación disponibles para IPsec, consulte la página man de setkey. Para más información sobre racoon, consulte las páginas man de racoon y de racoon.conf.

14.2.3. Interfaces de unión de canales

Red Hat Enterprise Linux permite a los administradores vincular múltiples interfaces juntas en un canal único usando el módulo del kernel bonding y una interfaz de red especial llamada la interfaz de unión de canales. La unión de canales habilita a dos o más interfaces de red a actuar como una sola, incrementando simultáneamente el ancho de banda y proporcionando redundancia.

Para crear una interfaz de unión de canales, cree un archivo en el directorio /etc/sysconfig/network-scripts/ llamado ifcfg-bond<N>, reemplazando <N> con el número para la interfaz, tal como 0.

Los contenidos del archivo pueden ser idénticos al tipo de interfaz que se esté vinculando, tal como una interfaz Ethernet. La única diferencia es que la directriz DEVICE= debe ser bond<N>, reemplazando <N> con el número para la interfaz.

A continuación se muestra un ejemplo de un archivo de configuración de unión de canales:

DEVICE=bond0 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no

Después de crear la interfaz de unión de canales, las interfaces de red a ser unidas se deben configurar añadiendo las directrices MASTER= y SLAVE= a sus archivos de configuración. Los archivos de configuración para cada interfaz de unión de canales pueden ser casi idénticos.

Por ejemplo, si se tiene un canal uniendo dos interfaces Ethernet, ambas eth0 y eth1 pueden verse como en el ejemplo siguiente:

DEVICE=eth<N> BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no

En este ejemplo, reemplace <N> con el valor numérico para la interfaz.

14.2.4. Archivos alias y clon

Dos tipos menos usados de archivos de configuración de interfaz son los archivos alias y clon.

Los archivos de configuración Alias, que se utilizan para enlazar direcciones múltiples a una sola interfaz, siguen este esquema de nombres ifcfg-<nombre-if>:<valor-alias>.

Por ejemplo, un archivo ifcfg-eth0:0 podría estar configurado para especificar DEVICE=eth0:0 y una dirección IP estática de 10.0.0.2, que sirva como un alias de una interfaz Ethernet que ya haya sido configurada para recibir la información IP a través de DHCP en ifcfg-eth0. Bajo esta configuración, el dispositivo eth0 está ligado a una dirección IP dinámica, pero la misma tarjeta de red física puede recibir peticiones a través de la dirección fija 10.0.0.2.

Atención

Los alias de interfaces no soportan DHCP.

Un archivo de configuración de interfaz clon debería seguir la siguiente convención de nombres: ifcfg-<nombre-if>-<nombre-clone>. Mientras que un archivo alias permite múltiples direcciones para una interfaz existente, un archivo clon se usa para especificar opciones adicionales para una interfaz. Por ejemplo, una interfaz Ethernet DHCP estándar llamada eth0, se verá de una forma similar a:

DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp

Puesto que el valor predeterminado para la directriz USERCTL es no si no está especificado, los usuarios no pueden activar y desactivar esta interfaz. Para que los usuarios gocen de esta habilidad, cree un clon copiando ifcfg-eth0 a ifcfg-eth0-user y añada la línea siguiente a ifcfg-eth0-user:

USERCTL=yes

De esta forma un usuario puede activar la interfaz eth0 mediante el comando /sbin/ifup eth0-user, porque las opciones de configuración desde ifcfg-eth0 y ifcfg-eth0-user se usan conjuntamente. Aunque este ejemplo es muy sencillo, este método puede ser utilizado con una variedad de opciones e interfaces.

14.2.5. Interfaces de acceso telefónico

Si se conecta a una red, como Internet, a través de la conexión de acceso telefónico, necesitará un archivo de configuración para la interfaz.

Los archivos de interfaz PPP son nombrados utilizando el siguiente formato:

ifcfg-ppp<X>

En este ejemplo, reemplace <X> con el valor numérico para la interfaz.

El archivo de configuración de la interfaz PPP es creado automáticamente cuando se usa wvdial, la Herramienta de administración de red o Kppp para crear una cuenta de marcado telefónico. También es posible crear y modificar este archivo manualmente.

A continuación se presenta un archivo ifcfg-ppp0 típico:

DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600

El Protocolo SLIP (siglas en inglés de Serial Line Internet Protocol) es otra interfaz de acceso telefónico menos usada. Los archivos SLIP tienen nombres de archivos de configuración de interfaz tales como ifcfg-sl0.

Otras opciones que se pueden utilizar en estos archivos incluyen:

DEFROUTE=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — Establece esta interfaz como la ruta por defecto.

  • no — No establece la interfaz como la ruta por defecto.

DEMAND=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — Esta interfaz permitirá que pppd inicie una conexión cuando alguien está intentando utilizarla.

  • no — Se debe establecer una conexión de forma manual para esta interfaz.

IDLETIMEOUT=<valor>

donde <valor> es el número de segundos de inactividad antes de que la interfaz se desconecte a sí misma.

INITSTRING=<cadena>

donde <cadena> es la cadena de inicialización que pasa al dispositivo del módem. Esta opción se usa principalmente en conjunto con las interfaces SLIP.

LINESPEED=<valor>

donde <valor> es la tasa de baudios del dispositivo. Los posibles valores estándar incluyen 57600, 38400, 19200 y 9600.

MODEMPORT=<dispositivo>

donde <dispositivo> es el nombre del dispositivo serial que se usa para establecer la conexión para la interfaz.

MTU=<valor>

donde <valor> es la unidad máxima de transferencia (MTU) configurada para la interfaz. La MTU hace referencia al mayor número de bytes de datos que puede abarcar un bloque, sin contar la información de encabezamiento. En algunas situaciones, la configuración de esta opción a un valor de 576 dará un resultado de pocos paquetes caídos y mejorará un poco el rendimiento para una conexión.

NAME=<nombre>

donde <nombre> es la referencia al título que se le da a un grupo de configuraciones de conexiones de acceso telefónico.

PAPNAME=<nombre>

donde <nombre> es el nombre de usuario dado durante el intercambio del Protocolo de autenticación de contraseña (PAP) que ocurre para permitir conectarse a un sistema remoto.

PERSIST=<respuesta>

donde <respuesta> es una de las siguientes:

  • yes — Esta interfaz debería mantenerse siempre activa, incluso si se desactiva tras una desconexión del módem.

  • no — Esta interfaz no debería mantenerse siempre activa.

REMIP=<dirección>

donde <dirección> es la dirección IP del sistema remoto. Generalmente no se especifica.

WVDIALSECT=<nombre>

donde <nombre> asocia esta interfaz con una configuración de marcado en /etc/wvdial.conf. Este archivo contiene el número de teléfono a marcar y otra información importante para la interfaz.

14.2.6. Otras interfaces

Los siguientes son otros archivos de configuración de interfaces comunes:

ifcfg-lo

A menudo se usa una interfaz loopback para realizar pruebas y con una variedad de aplicaciones que requieren una dirección IP que apunte al mismo sistema. Todos los datos que se mandan al dispositivo loopback vuelven inmediatamente a la capa de red del host.

Aviso

El script de la interfaz loopback /etc/sysconfig/network-scripts/ifcfg-lo nunca debe ser editado manualmente. Esto puede causar que el sistema deje de funcionar correctamente.

ifcfg-irlan0

Una interfaz de infrarrojo permite que se transmita información a través de un enlace infrarrojo entre dispositivos, tal como un portátil y una impresora. Esto funciona de forma similar a un dispositivo Ethernet excepto que se da comúnmente en una conexión punto a punto.

ifcfg-plip0

La conexión Protocolo de interfaz de línea paralela (PLIP) funciona casi de la misma manera que un dispositivo Ethernet, solamente que usa un puerto paralelo.

ifcfg-tr0

Las topologías Token Ring no son tan frecuentes en las Redes de área local (LANs), como lo eran antes, ya que Ethernet las ha opacado.

14.3. Scripts de control de interfaz

Los scripts de control de interfaz controlan la activación y desactivación de las interfaces del sistema. Existen dos scripts de control de la interfaz primaria que llaman a los scripts de control ubicados en el directorio /etc/sysconfig/network-scripts: /sbin/ifdown y /sbin/ifup.

Los scripts de interfaz ifdown y ifup son enlaces simbólicos a los scripts en el directorio /sbin. Cuando se solicita cualquiera de estos scripts se debe especificar el valor de la interfaz, como por ejemplo:

ifup eth0

Atención

Los scripts de interfaz ifup y ifdown son los únicos scripts que el usuario debe utilizar para subir y bajar las interfaces de red.

Los siguientes scripts son descritos como referencia únicamente.

Dos archivos utilizados para llevar a cabo una variedad de tareas de inicialización de la red durante el proceso de activación de una interfaz de red son /etc/rc.d/init.d/functions y /etc/sysconfig/network-scripts/network-functions. Consulte la Sección 14.5, “Archivos de funciones de red” para obtener mayor información.

Tras haber verificado que se ha especificado una interfaz y que al usuario que ha ejecutado la petición se le permite controlar la interfaz, el script correcto activa o desactiva la interfaz. Los siguientes scripts de control de interfaz son bastante comunes y se encuentran en el directorio /etc/sysconfig/network-scripts/:

ifup-aliases

Configura los alias IP desde los archivos de configuración de la interfaz cuando se asocia más de una dirección IP con una interfaz.

ifup-ippp y ifdown-ippp

Activa y desactiva una interfaz ISDN.

ifup-ipsec y ifdown-ipsec

Activa y desactiva una interfaz IPsec.

ifup-ipv6 y ifdown-ipv6

Se usa para activar y desactivar una interfaz IPv6.

ifup-ipx

Activa y desactiva una interfaz IPX.

ifup-plip

Activa y desactiva una interfaz PLIP.

ifup-plusb

Activa y desactiva una interfaz USB para conexiones de red.

ifup-post y ifdown-post

Contiene comandos que son ejecutados después de que una interfaz ha sido activada o desactivada.

ifup-ppp y ifdown-ppp

Activa o desactiva una interfaz PPP.

ifup-routes

Añade rutas estáticas para un dispositivo como si se activase su interfaz.

ifdown-sit y ifup-sit

Contiene llamadas de funciones relacionadas con la activación y desactivación de un túnel IPv6 dentro de una conexión IPv4.

ifup-sl y ifdown-sl

Activa o desactiva una interfaz SLIP.

ifup-wireless

Activa una interfaz inalámbrica.

Aviso

Tenga en cuenta que si elimina o modifica cualquier script en el directorio /etc/sysconfig/network-scripts/ puede provocar que las conexiones de interfaz funcionen de forma extraña o incluso fallen. Solo los usuarios avanzados deberían modificar los scripts relacionados con una interfaz de red.

La forma más fácil de manipular todos los scripts de red simultáneamente es con el comando /sbin/service en el servicio de red (/etc/rc.d/init.d/network), como se ilustra en el comando siguiente:

/sbin/service network <acción>

En este ejemplo <acción> puede ser start, stop o restart.

Para ver una lista de los dispositivos configurados y las interfaces de red actualmente activas, utilice el comando:

/sbin/service network status

14.4. Configuring Static Routes

Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route command to display the IP routing table.

Static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.

IP Command Arguments Format

Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:

default X.X.X.X dev interface

X.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway.

Define a static route. Each line is parsed as an individual route:

X.X.X.X/X via X.X.X.X dev interface

X.X.X.X/X is the network number and netmask for the static route. X.X.X.X and interface are the IP address and interface for the default gateway respectively. The X.X.X.X address does not have to be the default gateway IP address. In most cases, X.X.X.X will be an IP address in a different subnet, and interface will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.

The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:

default 192.168.0.1 dev eth0
10.10.10.0/24 via 192.168.0.1 dev eth0
172.16.1.0/24 via 192.168.0.1 dev eth0

Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:

10.10.10.0/24 via 10.10.10.1 dev eth1

Duplicate Default Gateways

If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.

Network/Netmask Directives Format

You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:

ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X
  • ADDRESS0=X.X.X.X is the network number for the static route.

  • NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.

  • GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.X

The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:

ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.0.1
ADDRESS1=172.16.1.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.0.1

Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.

Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:

ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=10.10.10.1

DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.

14.5. Archivos de funciones de red

Red Hat Enterprise Linux utiliza varios archivos que contienen funciones importantes que se usan para activar o desactivar interfaces. En vez de forzar cada archivo de control de interfaz para que contenga estas funciones, éstas están agrupadas convenientemente en algunos archivos que se pueden llamar cuando sea necesario.

El archivo /etc/sysconfig/network-scripts/network-functions contiene las funciones IPv4 más comunes que son útiles para muchos scripts de control de interfaz. Estas funciones incluyen: contactar con programas en ejecución que han solicitado información sobre cambios en el estado de una interfaz, configurar los nombres del host, encontrar dispositivos de puerta de enlace, ver si un dispositivo en particular está o no activado y añadir una ruta por defecto.

Debido a que las funciones solicitadas por las interfaces IPv6 son diferentes de las interfaces IPv4, existe específicamente un archivo /etc/sysconfig/network-scripts/network-functions-ipv6 para guardar esta información. Las funciones en este archivo configuran y borran las rutas IPv6 estáticas, crean y borran túneles, añaden y eliminan direcciones IPv6 para una interfaz y comprueban la existencia de una dirección IPv6 en una interfaz.

14.6. Recursos adicionales

Los siguientes son recursos que explican más detalladamente las interfaces de red.

14.6.1. Documentación instalada

/usr/share/doc/initscripts-<versión>/sysconfig.txt

Un manual que estudia las opciones disponibles para los archivos de configuración de red, incluidas las opciones IPv6 que no son cubiertas en este capítulo.

/usr/share/doc/iproute-<versión>/ip-cref.ps

Este archivo contiene mucha información sobre el comando ip, que se usa, entre otras cosas, para manipular las tablas de enrutamiento. Use la aplicación ggv o kghostview para ver este archivo.

Capítulo 15. Configuración de la red

Para que los ordenadores se puedan comunicar entre ellos es necesaria una conexión de red. Esto es posible gracias a que los sistemas operativos reconocen dispositivos de red (como Ethernet, módem RDSI o token ring) y a que estas interfaces de red están configuradas para conectarse a la red.

La Herramienta de administración de red sirve para configurar los siguientes tipos de dispositivos de red:

  • Ethernet

  • RDSI

  • módem

  • xDSL

  • token ring

  • CIPE

  • dispositivos inalámbricos

También se puede usar para configurar conexiones IPsec, administrar configuraciones de DNS y manejar el archivo /etc/hosts para almacenar nombres de host adicionales y combinaciones de direcciones IP.

Para usar la Herramienta de administración de red, debe tener privilegios de usuario root. Para arrancar la aplicación, vaya a Applications (the main menu on the panel) => Configuración del sistema => Red, o escriba el comando system-config-network en el intérprete de comandos (por ejemplo, en un XTerm o en un terminal GNOME terminal). Si escribe el comando mientras ejecuta X, la versión gráfica es desplegada, de lo contrario se inicia la versión basada en texto.

Para usar la versión de línea de comandos, ejecute el comando system-config-network-cmd --help como usuario root para ver todas las opciones disponibles.

Herramienta de administración de red

Ventana principal

Figura 15.1. Herramienta de administración de red

Sugerencia

Consulte la lista de compatibilidad de hardware de Red Hat (http://hardware.redhat.com/hcl/) para ver si Red Hat Enterprise Linux soporta su dispositivo de hardware.

15.1. Resumen

Para configurar una conexión de red con la Herramienta de administración de red siga los pasos siguientes:

  1. Añada dispositivos de red asociados al hardware anterior.

  2. Añada el dispositivo de hardware a la lista del hardware si aún no existe.

  3. Configure el nombre del host y los parámetros DNS.

  4. Configure cualquier hosts que no pueda ser encontrado a través de DNS.

Este capítulo discute cada uno de estos pasos para cada tipo de conexión de red.

15.2. Conexión Ethernet

Para establecer una conexión Ethernet necesita una interfaz de red (NIC), un cable de red (usualmente un cable CAT5) y una red a la cual conectarse. Diferentes redes se configuran para velocidades diferentes; asegúrese de que su tarjeta NIC es compatible con la red a la cual se quiere conectar.

Siga los siguientes pasos:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Añadir en la barra de herramientas.

  3. Seleccione Conexión Ethernet en la lista Tipo de dispositivo y haga click en Adelante.

  4. Si ya ha añadido el dispositivo de red a la lista de hardware, selecciónelo de la lista Dispositivo. De lo contrario, añada otros dispositivos de hardware seleccionándolo en Otros dispositivos Ethernet.

    Nota

    El programa de instalación normalmente detecta los dispositivos Ethernet y le pregunta si desea configurarlos. Si ya ha configurado algún dispositivo Ethernet durante la instalación, éstos aparecerán en la lista de hardware en la pestaña Hardware.

  5. Si ha seleccionado Otros dispositivos de red, aparecerá la pantalla Seleccionar adaptador de Ethernet. Seleccione el fabricante y el modelo del dispositivo Ethernet. Luego seleccione el nombre del dispositivo. Si se trata del primer dispositivo Ethernet del sistema, seleccione eth0 como nombre del dispositivo, si es el segundo eth1 y así sucesivamente. La Herramienta de administración de red también le permite configurar los recursos para NIC. Haga clic en Adelante para continuar.

  6. En la pantalla Configuración de parámetros de red como se muestra en la Figura 15.2, “Parámetros de Ethernet”, elija entre DHCP y la dirección estática IP. Si el dispositivo recibe una dirección IP diferente cada vez que se arranca la red, no especifique el nombre del host. Haga click en Adelante para continuar.

  7. Haga click en Aplicar en la página Crear dispositivo Ethernet.

Parámetros de Ethernet

Parámetros de Ethernet

Figura 15.2. Parámetros de Ethernet

Después de haber configurado el dispositivo Ethernet, éste aparece en la lista de los dispositivos como se muestra en la Figura 15.3, “Dispositivo Ethernet”.

Dispositivo Ethernet

Dispositivo Ethernet

Figura 15.3. Dispositivo Ethernet

Asegúrese de seleccionar Archivo => Guardar para guardar los cambios.

Después de añadir el dispositivo Ethernet, puede modificar su configuración seleccionando el dispositivo de la lista de dispositivos y haciendo click en Modificar. Por ejemplo, cuando el dispositivo se añade, se configura para que arranque por defecto en el momento de arranque. Para modificar la configuración de este parámetro, seleccione el dispositivo y cambie el valor Activar el dispositivo cuando se inicia el ordenador y guarde sus cambios.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

Si asocia más de un dispositivo con una tarjeta Ethernet, los dispositivos subsecuentes serán aliases de dispositivos. Un alias de dispositivo le permite configurar múltiples dispositivos virtuales a un dispositivo físico dándole así más de una dirección IP. Por ejemplo, puede configurar un dispositivo eth1 y un dispositivo eth1:1. Para obtener mayor información consulte la Sección 15.11, “Alias de dispositivo”.

15.3. Conexión RDSI

Una conexión RDSI es una conexión a Internet con un módem a través de una línea de teléfono especial instalada por la compañía de teléfonos. Las conexiones RDSI son muy famosas en Europa.

Para establecer una conexión RDSI, siga los siguientes pasos:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Añadir en la barra de herramientas.

  3. Seleccione la Conexión RDSI en la lista de los Seleccionar el tipo de dispositivos y haga click en Adelante.

  4. Seleccione el adaptador RDSI del menú desplegable. Después configure los recursos y el protocolo del canal D para el adaptador. Haga click en Adelante para continuar.

    Parámetros RDSI

    Parámetros RDSI

    Figura 15.4. Parámetros RDSI

  5. Si su proveedor ISP (siglas en inglés de Internet Service Provider) está en la lista de las cuentas preconfiguradas, selecciónela. De lo contrario, introduzca la información necesaria sobre la cuenta ISP. Si no sabe los valores, contacte a su ISP. Haga click en Adelante.

  6. En la ventana Configuraciones IP, seleccione Modo de encapsulación y si se debe obtener una dirección IP o si se debe configurar una estáticamente. Haga clic en Adelante al finalizar.

  7. En la pantalla Crear conexión telefónica haga clic en Aplicar.

Después de configurar el dispositivo RDSI, éste aparece en la lista de los dispositivos como un dispositivo de tipo RDSI como se muestra en la Figura 15.5, “Dispositivo RDSI”.

Asegúrese de seleccionar Archivo => Guardar para guardar los cambios.

Después de añadir el dispositivo RDSI, puede modificar su configuración seleccionando el dispositivo de la lista de dispositivos y haciendo clic en Modificar. Por ejemplo, cuando el dispositivo se añade, se configura para que no inicie en el tiempo de arranque predeterminado. Modifique la configuración cambiando este parámetro. Se puede cambiar también la compresión, las opciones PPP, el nombre de conexión, la contraseña, etc.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

Dispositivo RDSI

Dispositivo RDSI

Figura 15.5. Dispositivo RDSI

15.4. Conexión vía módem

Un módem se puede usar para configurar una conexión a Internet con una línea telefónica activa. Se necesita una cuenta ISP, también llamada cuenta de conexión.

Para llevar a cabo una conexión via módem, siga los siguientes pasos:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Añadir en la barra de herramientas.

  3. Seleccione Conexión del módem en Tipo de dispositivo y haga click en Adelante.

  4. Si ya tiene un módem configurado y aparece en la lista de hardware (en la pestaña Hardware), la Herramienta de administración de red supone que desea usarla para establecer una conexión via módem. Si no hay módems ya configurados, tratará de detectarlos en el sistema. Esta búsqueda puede tardar un rato. Si no encuentra un módem, se mostrará un mensaje para advertirle de que las configuraciones mostradas no son valores encontrados en la prueba.

  5. Después de verificar, aparecerá la Figura 15.6, “Propiedades del módem”.

    Propiedades del módem

    Parámetros del módem

    Figura 15.6. Propiedades del módem

  6. Configure el dispositivo módem, velocidad de baudios, el control del flujo y el volumen del módem. Si no conoce estos valores, acepte los valores si el módem fue probado exitósamente. Si no recibe el tono cuando marca el número, quite el ok de la casilla. Haga click en el botón Adelante.

  7. Si su ISP aparece en la lista de las cuentas predeterminadas, selecciónela; sino, introduzca la información de la cuenta ISP. Si no conoce los valores, contacte con su ISP. Haga click en Adelante.

  8. En la página Configuración IP, seleccione si desea obtener una dirección IP automáticamente o si la desea configurar de forma estática. Haga clic en Adelante cuando termine.

  9. En la pantalla Crear conexión telefónica haga clic en Aplicar.

Después de haber configurado el módem, éste aparece en la lista de los dispositivos con el tipo Modem como se muestra en la Figura 15.7, “Dispositivo del módem”.

Dispositivo del módem

Dispositivo del módem

Figura 15.7. Dispositivo del módem

Asegúrese de seleccionar Archivo => Guardar para guardar los cambios.

Después de haber añadido el dispositivo del módem, puede modificar la configuración seleccionándolo de la lista de dispositivos y haciendo click en Modificar. Por ejemplo, cuando se añade un dispositivo, se configura para que no arranque en el tiempo de arranque predeterminado. Modifique la configuración para cambiar este parámetro. También se puede cambiar la compresión, las opciones PPP, el nombre de login, la contraseña, etc.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

15.5. Conexión xDSL

DSL viene de las siglas de Digital Subscriber Lines. Hay diferentes tipos de DSL tales como ADSL, IDSL y SDSL. La Herramienta de administración de red usa el término xDSL para incluir todos los tipos de conexiones DSL.

Algunos proveedores DSL requieren que el sistema esté configurado para obtener una dirección IP a través de DHCP con una tarjeta Ethernet. Algunos proveedores DSL requieren que configure una conexión PPPoE (Point-to-Point Protocol over Ethernet) con una tarjeta Ethernet. Pregúntele a su proveedor DSL cúal método usar.

Si tiene que usar DHCP, consulte la Sección 15.2, “Conexión Ethernet” para configurar el dispositivo Ethernet.

Si usa el PPPoE, siga los pasos siguientes:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Nuevo.

  3. Seleccione conexión xDSL en la lista Tipo de dispositivo y haga clic en Adelante como se muestra en la Figura 15.8, “Seleccione el tipo de dispositivo”..

    Seleccione el tipo de dispositivo

    Seleccione el tipo de dispositivo

    Figura 15.8. Seleccione el tipo de dispositivo

  4. Si su tarjeta Ethernet está en la lista de hardware, seleccione el Dispositivo Ethernet desde el menú desplegable desde la página mostrada en la Figura 15.9, “Parámetros xDSL”. De lo contrario, aparecerá la ventana Seleccionar adaptador Ethernet.

    Nota

    El programa de instalación normalmente detecta los dispositivos Ethernet y le pregunta si desea configurarlos. Si ya ha configurado algún dispositivo Ethernet durante la instalación, éstos aparecerán en la lista de hardware en la pestaña Hardware.

    Parámetros xDSL

    Parámetros xDSL

    Figura 15.9. Parámetros xDSL

  5. Introduzca el Nombre del proveedor, Nombre de conexión y Contraseña. Si tiene una cuenta T-Online, seleccione Normal desde el menú desplegable Tipo de cuenta.

    Si está configurando una cuenta T-Online, seleccione T-Online desde el menú desplegable Tipo de cuenta e introduzca los valores en los campos Nombre de login y Contraseña. Puede realizar configuraciones más avanzadas a su cuenta T-Online una vez la conexión DSL haya sido configurada completamente (consulte Configurando una cuenta T-Online).

  6. Haga clic en Adelante para ir al menú Crear conexión DSL. Revise su configuración y haga clic en Aplicar para finalizar.

  7. Después de haber configurado la conexión DSL, esta aparece en la lista de los dispositivos como se muestra en la Figura 15.10, “Dispositivo xDSL”.

    Dispositivo xDSL

    Dispositivo xDSL

    Figura 15.10. Dispositivo xDSL

  8. Después de añadir la conexión xDSL, puede modificar la configuración seleccionándolo de la lista de dispositivos y haciendo click en Modificar.

    Configuración xDSL

    Configuración xDSL

    Figura 15.11. Configuración xDSL

    Por ejemplo, cuando el dispositivo sea añadido, éste es configurado para que no sea iniciado durante el periodo de arranque. Edite la configuración para modificar estos parámetros. Haga clic en OK cuando finalice.

  9. Una vez satisfecho con los parámetros de conexión xDSL, seleccione Archivo => Guardar para guardar los cambios.

Configurando una cuenta T-Online

Si está configurando una cuenta T-Online, siga estos pasos adicionales:

  1. Seleccione el dispositivo desde la lista de dispositivos y haga clic en Editar.

  2. Seleccione la pestaña Proveedor desde el menú configuración xDSL como se muestra en la Figura 15.12, “Configuración xDSL - pestaña para el proveedor”.

    Configuración xDSL - pestaña para el proveedor

    Configuración xDSL - pestaña para el proveedor

    Figura 15.12. Configuración xDSL - pestaña para el proveedor

  3. Haga clic en el botón Establecer cuenta T-Online. Esto abrirá la ventana Configurar cuenta para su cuenta T-Online como se muestra en Figura 15.13, “Configurar cuenta”.

    Configurar cuenta

    Configurar cuenta

    Figura 15.13. Configurar cuenta

  4. Introduzca los valores para Identificados del adaptador, Número T-Online asociado, Numero/sufijo del usuario actual y Contraseña personal. Haga clic en Ok cuando finalice para cerrar la ventana Configurar cuenta.

  5. En la ventana Configuración xDSL, haga clic en OK. Asegúrese de seleccionar Archivo => Guardar desde Herramienta de administración de red para guardar los cambios.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

15.6. Conexión Token Ring

Una red token ring es una red en la que los ordenadores están conectados como si formasen un círculo. Un token o paquete especial de red, viaja a través del anillo y permite que los ordenadores intercambien información.

Sugerencia

Para más información sobre el uso de token ring bajo Linux, consulte el sitio web de Linux Token Ring Project en http://www.linuxtr.net/.

Para llevar a cabo una conexión token ring, siga los siguientes pasos:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Añadir en la barra de herramientas.

  3. Seleccione Conexión Token Ring desde la lista Tipo de dispositivo y haga click en Adelante.

  4. Si ya tiene una tarjeta token ring configurada en la lista del hardware, selecciónela de la lista Tarjeta token ring. Sino, seleccione Otro dispositivo Token ring para añadirlo a la lista del hardware.

  5. Si seleccionó Otra tarjeta Tokenring, aparecerá la ventana Seleccionar adaptador Token Ring como se muestra en la Figura 15.14, “Parámetros Token Ring”. Seleccione el nombre del fabricante y el modelo del adaptador. Seleccione el nombre del dispositivo. Si es el primer token ring del sistema llámelo tr0; si es el segundo token ring, seleccione tr1 (y así sucesivamente). La Herramienta de administración de red también permite que el usuario pueda configurar los recursos para el adaptador. Haga clic en Adelante para continuar.

    Parámetros Token Ring

    Parámetros Token Ring

    Figura 15.14. Parámetros Token Ring

  6. En la pantalla Configurar parámetros de la red, escoja entre DHCP y la dirección IP. Debe especificar un nombre del host para el dispositivo. Si el dispositivo recibe una dirección IP cada vez que se arranca la red, no especifique este nombre. Haga click en Adelante para continuar.

  7. Haga click en Aplicar en la página Crear dispositivo Token ring.

Después de configurar el dispositivo token ring, éste aparece en la lista de los dispositivos como se muestra en la Figura 15.15, “Dispositivo Token Ring”.

Dispositivo Token Ring

Dispositivo Token Ring

Figura 15.15. Dispositivo Token Ring

Asegúrese de seleccionar Archivo => Guardar para guardar los cambios.

Después de añadir el dispositivo, puede modificar la configuración seleccionándolo de la lista de dispositivos y haciendo click en Modificar. Por ejemplo, puede configurar el tiempo de arranque del dispositivo.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

15.7. Conexión de tipo inalámbrica

Los dispositivos Ethernet inalámbricos cada vez son más famosos. La configuración es parecida a la configuración de los dispositivos Ethernet salvo que permite configurar el SSID y la clave del dispositivo inalámbrico.

Para establecer una conexión Ethernet inalámbrica, siga los pasos siguientes:

  1. Haga click en Dispositivos.

  2. Haga click en el botón Añadir en la barra de herramientas.

  3. Seleccione Conexión inalámbrica desde la lista Tipo de dispositivo y haga clic en Adelante.

  4. Si ya ha agregado una tarjeta de red inalámbrica a la lista de hardware, selecciónela de la lista Tarjeta inalámbrica. De lo contrario, seleccione Otra tarjeta inalámbrica para añadir el dispositivo de hardware.

    Nota

    El programa de instalación normalmente detecta los dispositivos inalámbricos Ethernet soportados y le pregunta si desea configurarlos. Si ya ha configurado algún dispositivo inalámbrico durante la instalación, aparecerán en la lista de hardware en la pestaña Hardware.

  5. Si ha seleccionado Otro tarjeta inalámbrica, aparece la ventana Seleccionar el adaptador Ethernet. Seleccione el nombre del fabricante y el modelo del adaptador y del dispositivo. Si es el primer dispositivo del sistema llámelo eth0; si es la segunda tarjeta Ethernet para el sistema, seleccione eth1 y así sucesivamente. La Herramienta de administración de red también permite al usuario configurar los recursos para el dispositivo de red inalámbrico. Haga click en Adelante para continuar.

  6. En la página Configurar conexión inalámbrica como se muestra en la Figura 15.16, “Parámetros de la conexión inalámbrica”, configure las propiedades para el dispositivo inalámbrico.

    Parámetros de la conexión inalámbrica

    Parámetros de la conexión inalámbrica

    Figura 15.16. Parámetros de la conexión inalámbrica

  7. En la pantalla Configurar parámetros de la red, escoja entre DHCP y la dirección IP. Debe especificar un nombre del host para el dispositivo. Si el dispositivo recibe una dirección IP cada vez que se arranca la red, no especifique este nombre. Haga click en Adelante para continuar.

  8. Haga click en Aplicar en la pantalla Crear dispositivo inalámbrico.

Después de configurar el dispositivo inalámbrico, aparecerá en la lista de dispositivos como se muestra en la Figura 15.17, “Dispositivo inalámbrico”.

Dispositivo inalámbrico

Dispositivo inalámbrico

Figura 15.17. Dispositivo inalámbrico

Asegúrese de seleccionar Archivo => Guardar para guardar los cambios.

Después de añadir el dispositivo inalámbrico, puede modificar la configuración seleccionándolo de la lista de dispositivos y haciendo click en Modificar. Por ejemplo, puede configurar el dispositivo para que se active durante el tiempo de arranque.

Cuando se añade un dispositivo, este no se activa inmediatamente, como se puede ver en su estado Inactivo. Para activar el dispositivo, selecciónelo desde la lista de dispositivos y luego presione el botón Activar. Si el sistema está configurado para activar el dispositivo cuando la máquina arranca (por defecto), este paso no tiene que volverse a ejecutar.

15.8. Administración de los parámetros DNS

La pestaña DNS le permite configurar el nombre host del sistema, el dominio, los servidores de nombres y el dominio de búsqueda. Los servidores de nombres se usan para buscar otros hosts en la red.

Si los nombres de servidores de DNS son obtenidos desde DHCP o PPPoE (o recuperados desde el ISP), no añada servidores DNS primarios, secundarios o terciarios.

Si el nombre del host es recuperado dinámicamente desde DHCP o PPPoE (o desde el ISP), no lo cambie.

Configuración DNS

Configuración DNS

Figura 15.18. Configuración DNS

Nota

La sección de los servidores de nombres no configura el sistema para que sea un servidor de nombres. En su lugar, configura los servidores de nombres para que se usen cuando se resuelven direcciones IP a host y viceversa.

Aviso

Si el nombre de host ha cambiado y system-config-network es iniciado en el host local, otra aplicación X11 podría no poder ser iniciada. Para ello, usted tendría que iniciar una nueva sesión de escritorio.

15.9. Administración de hosts

La pestaña Hosts le permite agregar, modificar o eliminar hosts del archivo /etc/hosts. Este archivo contiene las direcciones IP y sus nombres de hosts correspondientes.

Cuando el sistema intente resolver un nombre de host a una dirección IP, o de determinar el nombre de host para una dirección IP, hará referencia al archivo /etc/hosts antes de usar los servidores de nombres (si usa la configuración por defecto de Red Hat Enterprise Linux). Si aparece la dirección IP en el archivo /etc/hosts, no se utilizarán los servidores de nombres. Si la red contiene ordenadores cuyas direcciones IP no aparecen en DNS, se recomienda añadirlas al archivo /etc/hosts.

Para añadir una entrada al archivo /etc/hosts, vaya a la pestaña Hosts, haga click en el botón Añadir y proporcione la información que se le solicita y luego haga click en OK. Seleccione Archivo => Guardar o presione Ctrl-S para guardar los cambios al archivo /etc/hosts. La red o los servicios de la red no necesitan ser reiniciados ya que la versión actual del archivo es referenciada cada vez que se resuelve una dirección.

Aviso

No elimine la entrada localhost. Aún si el sistema no tiene una conexión de red o tiene una conexión de red ejecutándose constantemente, algunos programas necesitan conectarse al sistema a través de la interfaz de loopback de la máquina.

Configuración de los hosts

Configuración de los hosts

Figura 15.19. Configuración de los hosts

Sugerencia

Para cambiar el orden de búsqueda, modifique el archivo /etc/host.conf. La línea order hosts, bind especifica que /etc/hosts toma precedencia sobre los servidores de nombres. Si se cambia la línea a order bind, hosts se configura el sistema a que resuelva los nombres de host y direcciones IP usando los servidores de nombres primero. Si las direcciones IP no se pueden resolver a través de los servidores de nombres, el sistema entonces busca por la dirección IP en el archivo /etc/hosts.

15.10. Funcionamiento con perfiles

Muchos dispositivos lógicos de red pueden ser creados para cada dispositivo de hardware físico. Por ejemplo, si tiene una tarjeta Ethernet en su sistema (eth0), puede crear dispositivos lógicos de red con apodos diferentes y opciones de configuración diferentes, todos ellos asociados específicamente a eth0.

Los dispositivos lógicos de red son diferentes de los alias de dispositivos. Los dispositivos lógicos de red asociados con el mismo dispositivo físico deben existir en perfiles diferentes y no pueden ser activados simultáneamente. Los alias de dispositivo están asociados con el mismo dispositivo de hardware físico, pero los alias asociados al mismo hardware físico pueden ser activados al mismo tiempo. Consulte la Sección 15.11, “Alias de dispositivo” para obtener más detalles sobre la creación de alias.

Los Perfiles se pueden usar para crear grupos de configuración múltiple para las diferentes redes. Un grupo de configuraciones puede incluir dispositivos lógicos así como hosts y configuraciones DNS. Tras haber configurado los perfiles, puede usar la Herramienta de administración de red para cambiar de uno a otro.

Existe por defecto un perfil llamado Common. Para crear un nuevo perfil, pulse el botón Perfil => Nuevo desde el menú e introduzca un nombre único para el perfil.

Ahora esta modificando el nuevo perfil como se indica por la barra de estado en la parte inferior de la pantalla.

Haga click en un dispositivo ya existente en la lista y haga click en el botón Copiar para copiar un dispositivo existente a un dispositivo de red lógico. Si usa el botón Nuevo, se creará un alias de red, lo cual es incorrecto. Para cambiar las propiedades del dispositivo lógico, selecciónelo desde la lista y haga click en Modificar. Por ejemplo, el apodo se puede cambiar a un nombre más descriptivo, tal como eth0_office, para que sea reconocido más fácilmente.

En la lista de dispositivos existe una columna de casillas de verificación etiquetada como Perfil. Para cada perfil puede seleccionar o deseleccionar los dispositivos. Tan sólo los dispositivos seleccionados están incluidos en el perfil seleccionado. Por ejemplo, si creó un dispositivo lógico llamado eth0_office en un perfil de nombre Office y quiere activar el dispositivo lógico si se selecciona el perfil, quite la marca del dispositivo eth0 y seleccione eth0_office.

Por ejemplo, la Figura 15.20, “Perfil Office” le muestra un perfil llamado Office con el dispositivo lógico eth0_office. Está configurado para activar la primera tarjeta Ethernet usando DHCP.

Perfil Office

Creación de un perfil Office

Figura 15.20. Perfil Office

Observe que el perfil Home como se muestra en la Figura 15.21, “Home Profile” activa el dispositivo lógico eth0_home, el cual está asociado con eth0.

Home Profile

Crear un perfil de directorio personal

Figura 15.21. Home Profile

También puede configurar eth0 para que se active en el perfil Office solamente y activar un dispositivo ppp (modem) en el perfil Home solamente. Otro ejemplo es tener el perfil Common activado eth0 y un perfil Away para activar un dispositivo ppp para ser usado mientras se esté de viaje.

Para activar un perfil al momento del arranque, modifique el archivo de configuración del gestor de arranque para incluir la opción netprofile=<nombre-perfil>. Por ejemplo, si el sistema utiliza GRUB como gestor de arranque y /boot/grub/grub.conf contiene:

title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-5.EL.img

Modifíquelo a lo siguiente (donde <nombre-perfil> es el nombre del perfil a ser activado durante el arranque):

title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 \ netprofile=<nombre-perfil> \ rhgb quiet initrd /initrd-2.6.9-5.EL.img

Para cambiar perfiles después de iniciado el sistema, vaya al Applications (the main menu on the panel) => Herramientas de sistema => Control del dispositivo de red (o escriba el comando system-control-network) para seleccionar un perfil y activarlo. La sección de activar perfiles sólo aparece en la interfaz Control del dispositivo de red si existen más interfaces además de Común.

Alternativamente, puede ejecutar el comando siguiente para activar un perfil (reemplace <nombre-perfil> con el nombre del perfil):

system-config-network-cmd --profile <nombre-perfil> --activate

15.11. Alias de dispositivo

Los Alias de dispositivo son dispositivos virtuales asociados con el mismo hardware físico, pero pueden ser activados al mismo tiempo para tener diferentes direcciones IP. Están generalmente representados como el nombre del dispositivo seguido de dos puntos y un número (por ejemplo eth0:1). Son útiles si desea tener más de una dirección IP para un sistema que tan sólo tiene una tarjeta de red.

Después de configurar el dispositivo Ethernet — tal como eth0— para usar una dirección estática IP (DHCP no funciona con aliases), vaya a la pestaña Dispositivos y haga click en Nuevo. Seleccione la tarjeta Ethernet a configurar con un alias, configura la dirección IP estática para el alias y haga click en Aplicar para crearlo. Puesto que ya existe un dispositivo para la tarjeta Ethernet, la que se acaba de crear es el alias tal como eth0:1.

Aviso

Si está configurando un dispositivo Ethernet para tener un alias, ni el dispositivo ni el alias pueden ser configurados para usar DHCP. Debe configurar las direcciones IP manualmente.

Figura 15.22, “Ejemplo de alias del dispositivo de red” muestra un ejemplo de un alias para el dispositivo eth0. Observe el dispositivo eth0:1 — el primer alias para eth0. El segundo alias para eth0 tendrá el nombre de dispositivo eth0:2 y así sucesivamente. Para modificar los parámetros para el alias del dispositivo, tal como la activación de éste durante el arranque y el número de alias, selecciónelo de la lista y haga click en el botón Modificar.

Ejemplo de alias del dispositivo de red

Ejemplo de alias de red

Figura 15.22. Ejemplo de alias del dispositivo de red

Seleccione el alias y pulse el botón Activar para activar el alias. Si ha configurado perfiles múltiples, seleccione qué perfiles incluir.

Para verificar que el alias ha sido activado, utilice el comando /sbin/ifconfig. La salida debería mostrar el dispositivo y el alias de dispositivo con direcciones IP diferentes:

eth0 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.5 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:161930 errors:1 dropped:0 overruns:0 frame:0 TX packets:244570 errors:0 dropped:0 overruns:0 carrier:0 collisions:475 txqueuelen:100 RX bytes:55075551 (52.5 Mb) TX bytes:178108895 (169.8 Mb) Interrupt:10 Base address:0x9000 eth0:1 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.42 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:10 Base address:0x9000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5998 errors:0 dropped:0 overruns:0 frame:0 TX packets:5998 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1627579 (1.5 Mb) TX bytes:1627579 (1.5 Mb)

15.12. Guardar y recuperar la configuración de la red

La versión de línea de comandos de la Herramienta de administración de red puede ser utilizada para guardar la configuración de la red del sistema a un archivo. Este archivo se puede utilizar porteriormente para restaurar la configuración de la red a un sistema Red Hat Enterprise Linux.

Esta funcionalidad se puede usar como parte de un script de respaldo automático, para guardar la configuración antes de actualizar o reinstalar, o para copiar la configuración a un sistema Red Hat Enterprise Linux diferente.

Para guardar o exportar la configuración del sistema a un archivo /tmp/network-config, ejecute el comando siguiente como root:

system-config-network-cmd -e > /tmp/network-config

Para restaurar o importar la configuración de la red desde un archivo creado desde el comando anterior, ejecute el comando siguiente como root:

system-config-network-cmd -i -c -f /tmp/network-config

La opción -i significa importar datos, la opción -c significa limpiar la configuración existente antes de importar y la opción -f especifica que el archivo a importar es como el dado después de la opción.

Capítulo 16. Control de acceso a servicios

La seguridad del sistema es un tema muy importante, y una de las aproximaciones para esta tarea es la cuidadosa administración del acceso a los servicios del sistema. Su sistema podría tener que proporcionar acceso a algunos servicios en particular (por ejemplo httpd se está ejecutando un servidor de Web). Sin embargo, si usted no tiene que proporcionar un servicio, debería minimizar su exposición a posibles ataques.

Hay diferentes métodos de administrar el acceso a los servicios del sistema. Debe decidir el método que le gustaría usar en función del servicio, la configuración del sistema y el nivel de conocimientos que tenga de Linux.

La forma más fácil de negar el acceso a un servicio es desactivandolo. Tanto los servicios administrados por xinetd como los servicios en /etc/rc.d/init.d (también conocidos como servicios SysV) pueden ser activados o desactivados utilizando tres diferentes aplicaciones:

Herramienta de configuración de servicios

Ésta es una aplicación gráfica que muestra una descripción de cada servicio, muestra si los servicios se han iniciado en el momento del arranque (para los niveles de ejecución 3, 4 y 5) y permite que los servicios sean arrancados, detenidos o reiniciados.

ntsysv

Esta es una aplicación de la línea de comandos que permite configurar los servicios que deben ser iniciados durante el arranque del sistema para cada nivel de ejecución. Los servicios que no son controlados por xinetd no pueden ser iniciados, detenidos o reiniciados utilizando este programa.

chkconfig

Esta es una utilidad de la línea de comandos que le permite activar o desactivar servicios en los diferentes niveles de ejecución. Los servicios que no son controlados por xinetd no pueden ser iniciados, detenidos o reiniciados utilizando esta utilidad.

Pronto descubrirá que estas herramientas son más fáciles de usar que las alternativas — modificación manual de los numerosos vínculos simbólicos ubicados en los directorios bajo /etc/rc.d o la modificación de los ficheros de configuración xinetd en /etc/xinetd.d.

Otra forma de administrar el acceso a los servicios del sistema es mediante el uso de iptables para configurar un cortafuegos de IP. Si es un usuario nuevo de Linux, tenga en cuenta que iptables puede que no sea la mejor solución para usted. La configuración de iptables puede ser complicada y es mejor que la realicen administradores de sistemas Linux experimentados.

Alternatively, if you are looking for a utility to set general access rules for your home machine, and/or if you are new to Linux, try the Herramienta de configuración del nivel de seguridad (system-config-securitylevel), which allows you to select the security level for your system, similar to the Firewall Configuration screen in the installation program.

16.1. Niveles de ejecución

Antes de configurar el acceso a servicios, deberá entender qué son los niveles de ejecución en Linux. Un nivel de ejecución es un estado o un modo que los servicios incluídos en el directorio /etc/rc.d/rc<x>.d definen, donde <x> es el número del nivel de ejecución.

Existen los siguientes niveles de ejecución:

  • 0 — Parada

  • 1 — Modo de un usuario

  • 2 — No se utiliza (definido por el usuario)

  • 3 — Modo completo de multiusuarios

  • 4 — No se utiliza (definido por el usuario)

  • 5 — Modo completo de multiusuarios (con una pantalla de conexión basada en X)

  • 6 — Rearranque

Si usa una pantalla de texto para el ingreso al sistema, estará operando a nivel de ejecución 3. Si usa una pantalla gráfica para ingresar al sistema, estará operando a nivel de ejecución 5.

El nivel de ejecución por defecto se puede cambiar si se modifica el fichero /etc/inittab, que contiene una línea junto a la parte superior del fichero con el siguiente aspecto:

id:5:initdefault:

Cambie el número en esta línea con el nivel de ejecución deseado. El cambio no tiene efecto hasta que reinicie el sistema.

16.2. TCP Wrappers

Muchos administradores de sistemas UNIX están acostumbrados a usar TCP wrappers para administrar el acceso a determinados servicios de red. Cualquier servicio de red que se administre con xinetd (así como también cualquier programa con soporte incorporado para libwrap) puede usar TCP-wrappers para administrar el acceso. xinetd puede usar los ficheros /etc/hosts.allow y /etc/hosts.deny para configurar el acceso a los servicios del sistema. hosts.allow contiene una lista de reglas que le permiten a los clientes acceder los servicios de red controlados por xinetd y hosts.deny, a su vez, contiene reglas para denegar el acceso. El archivo hosts.allow toma precedencia sobre el archivo hosts.deny. Los permisos que conceden o deniegan el acceso se pueden basar en una dirección IP individual (o nombres de hosts) o en un modelo de clientes. Vea la página man hosts_access en la sección 5 (man 5 hosts_access) para obetener más detalles.

16.2.1. xinetd

Para controlar el acceso a los servicios de Internet, use xinetd. Éste es un sustituto seguro del comando inetd. El demonio xinetd conserva los recursos del sistema, proporciona control y registro de acceso, y sirve para arrancar servidores de uso especial. xinetd puede ser usado para proveer acceso a host particulares, denegar el acceso a determinados hosts, proporcionar acceso a un servicio en horas concretas, limitar el número de conexiones de entrada y/o la carga que se crea con las conexiones, etc.

xinetd se ejecuta de forma permanente y escucha en todos los puertos para los servicios que administra. Cuando recibe una petición de conexión de uno de los servicios que administra, xinetd arranca el servidor apropiado a dicho servicio.

El archivo de configuración para xinetd es /etc/xinetd.conf, pero el archivo sólo contiene unos pocos valores por defecto y una instrucción para incluir el directorio /etc/xinetd.d. Para activar o desactivar un servicio xinetd, modifique el archivo de configuración en el directorio /etc/xinetd.d. Si el atributo disable está definido como yes, el servicio es desactivado. Si el atributo disable está definido a no, el servicio es activado. Puede editar cualquiera de los archivos de configuración xinetd o cambiar el estado usando la Herramienta de configuración de servicios, ntsysv o chkconfig. Para obtener una lista de los servicios de red controlados por xinetd, revise los contenidos del directorio /etc/xinetd.d con el comando ls /etc/xinetd.d.

16.3. Herramienta de configuración de servicios

La Herramienta de configuración de servicios es una aplicación gráfica desarrollada por Red Hat para configurar los servicios SysV en /etc/rc.d/init.d que se inician en el momento del arranque (para los niveles de ejecución 3, 4 y 5) y cuáles servicios xinetd están activados. También le permite arrancar, detener y rearrancar servicios SysV así como rearrancar xinetd.

Para usar la Herramienta de configuración de servicios, debe tener privilegios de usuario root. Para arrancar la aplicación, vaya al Applications (the main menu on the panel) => Configuración del sistema => Configuración de servidores => Servicios o escriba el comando system-config-services en el intérprete de comandos (por ejemplo, en un XTerm o en un terminal GNOME terminal).

Herramienta de configuración de servicios

Configuración de los servicios de red

Figura 16.1. Herramienta de configuración de servicios

La Herramienta de configuración de servicios muestra el nivel de ejecución así como también el nivel de ejecución en el cual está modificando actualmente. Para modificar otro nivel de ejecución, seleccione Editar nivel de ejecución desde el menú desplegable y seleccione los niveles 3, 4 o 5. Consulte la Sección 16.1, “Niveles de ejecución” para obtener una descripción de los niveles de ejecución.

La Herramienta de configuración de servicios muestra los servicios de /etc/rc.d/init.d y los servicios controlados por xinetd. Haga click en un servicio para mostrar una breve descripción del servicio y también para ver el estado del mismo. Si el servicio no es xinetd, la ventana de estado muestra si el servicio se está ejecutando o no. Si el servicio es controlado por xinetd, la ventana de estado mostrará la frase servicio xinetd.

Para arrancar, detener o rearrancar un servicio inmediatamente, seleccione el servicio y haga click en el botón adecuado (o elija la acción correspondiente en el menú desplegable Acciones). Si el servicio es xinetd, los botones de acción estarán desactivados porque no pueden ser arrancados o detenidos individualmente.

Si activa o desactiva un servicio xinetd marcando o desmarcando la casilla de verificación al lado del nombre del servicio, debe seleccionar Archivo => Guardar cambios desde el menú desplegable para reiniciar xinetd e inmediatamente activar/desactivar el servicio xinetd que usted cambió. xinetd se configura para recordar la configuración. Puede activar/desactivar más de un servicio xinetd a la vez y guardar los cambios cuando haya terminado.

Por ejemplo, imagine que verifica rsync para activarlo a nivel de ejecución 3 y luego guarda los cambios. El servicio rsync se activará de inmediato. La próxima vez que arranque xinetd, rsync estará todavía activado.

Nota

Cuando guarde los cambios de los servicios xinetd, xinetd es reiniciado y los cambios toman efecto de inmediato. Cuando guarda cambios a otros servicios, el nivel de ejecución es reconfigurado, pero los cambios no serán efectivos de inmediato.

Para activar un servicio que no es controlado por xinetd para que se inicie en el momento de arranque del sistema para el nivel de ejecución seleccionado actualmente, marque la casilla de verificación al lado del nombre del servicio en la lista. Después de configurar el nivel de ejecución, aplique los cambios seleccionando Archivo => Guardar cambios desde el menú desplegable. La configuración del nivel de ejecución es modificada, pero el nivel de ejecución no es reiniciado; por tanto los cambios no toman efecto de inmediato.

Por ejemplo, asuma que está configurando un nivel de ejecución 3. Si cambia el valor para el servicio httpd de marcado a desmarcado y luego selecciona Guardar cambios, el nivel de ejecución 3 cambia y entonces httpd no es iniciado al momento de arranque. Sin embargo, el nivel de ejecución 3 no es reinicializado, por tanto httpd todavía estará ejecutándose. Llegados a este punto, seleccione una de las siguientes opciones:

  1. Detener el servicio httpd — Detenga el servicio seleccionándolo de la lista y haciendo click en el botón Parar el servicio. Aparecerá un mensaje para indicar que se ha detenido correctamente el servicio.

  2. Reinicializar el nivel de ejecución — Reinicializar el nivel de ejecución escribiendo en el intérprete de comandos de shell el comando telinit x (donde x es el número de nivel de ejecución). Esta opción es recomendada si cambia el valor Comenzar al arrancar de más de un servicio y quiere activar los cambios inmediatamente.

  3. No hacer nada — No tiene que detener el servicio httpd. Puede esperar a que se rearranque el sistema para que el servicio se detenga. La próxima vez que se arranque el sistema, se inicializará el nivel de ejecución sin que se ejecute el servicio httpd.

Para añadir un servicio a un nivel de ejecución, seleccione el nivel de ejecución desde el menú desplegable Modificar nivel de ejecución y seleccione Acciones => Añadir servicio. Para borrar un servicio de un nivel de ejecución, seleccione el nivel de ejecución desde el menú desplegable Modificar nivel de ejecución, seleccione el servicio a eliminar de la lista a la izquierda y seleccione Acciones => Eliminar servicio.

16.4. ntsysv

La utilidad ntsysv provee una interfaz sencilla para activar y desactivar servicios. Puede usar ntsysv para activar o desactivar un servicio xinetd. También puede usar ntsysv para configurar los niveles de ejecución. Por defecto, únicamente el nivel de ejecución actual es configurado. Para configurar un nivel de ejecución diferente, especifique uno o más niveles con la opción --level. Por ejemplo, el comando ntsysv --level 345 configura los niveles de ejecución 3, 4, y 5.

La interfaz de ntsysv funciona como el programa de instalación en modo texto. Utilice las flechas del teclado para navegar a través de la lista. La barra espaciadora es utilizada para seleccionar/deseleccionar los servicios y también para presionarlos botones Ok y Cancelar. Para moverse a través de los servicios y los botones Ok y Cancelar utilice la tecla Tab. Un asterisco (*) significa que el servicio está activado. Al presionar la tecla F1 muestra una descripción de los servicios seleccionados.

La utilidad ntsysv

La utilidad ntsysv

Figura 16.2. La utilidad ntsysv

Aviso

Los servicios manejados por xinetd son afectados de inmediato por ntsysv. Para todos los demás servicios, los cambios no tienen efecto de inmediato. Usted debe detener o arrancar el servicio individual con el comando service <demonio> stop. En el ejemplo anterior, sustituya <demonio> con el nombre del servicio que desee detener, por ejemplo httpd. Reemplace stop por start o restart para arrancar o reiniciar el servicio.

16.5. chkconfig

El comando chkconfig puede ser usado para activar y desactivar servicios. Si usa el comando chkconfig --list, verá una lista de los servicios del sistema y si están iniciados (on) o detenidos (off) en los niveles de ejecución 0-6. Al final de la lista, verá una sección para los servicios manejados por xinetd.

Si usa chkconfig --list para realizar una consulta a un servicio manejado por xinetd, verá si el servicio xinetd está activado (on) o desactivado (off). Por ejemplo, el comando chkconfig --list rsync muestra:

rsync on

Como se muestra, rsync está activado como un servicio xinetd. Si xinetd está ejecutándose, rsync estará activo.

Si usa chkconfig --list para consultar un servicio /etc/rc.d, verá las configuraciones del servicio para cada nivel de ejecución. Por ejemplo, el comando chkconfig --list httpd muestra:

httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

chkconfig también puede ser usado para configurar un servicio para que comience (o no) en un nivel de ejecución específico. Por ejemplo, desactive nscd en los niveles de ejecución 3, 4, y 5, usando el comando siguiente:

chkconfig --level 345 nscd off

Aviso

Los servicios gestionados por xinetd son afectados por chkconfig. Por ejemplo, si se está ejecutando xinetd, rsync está deshabilitado y se ejecuta el comando chkconfig rsync on y se activa de inmediato rsync sin tener que reiniciar xinetd de forma manual. El resto de los cambios no se producen inmediatamente tras haber usado chkconfig manualmente. Deberá parar y reiniciar el servicio individual con el comando service <demonio> stop. En el ejemplo anterior, reemplace <demonio> con el nombre del servicio que desea parar; por ejemplo, httpd. Reemplace stop con start o con restart para iniciar o reiniciar el servicio.

16.6. Recursos adicionales

Para más información, refiérase a los recursos siguientes.

16.6.1. Documentación instalada

  • Las páginas del manual para ntsysv, chkconfig, xinetd y xinetd.conf.

  • man 5 hosts_access — Página del manual para el formato de ficheros de control de acceso al host ( en la sección 5 de las páginas de manual).

16.6.2. Sitios Web útiles

  • http://www.xinetd.org — Página Web sobre xinetd. Contiene una lista detallada de funciones y archivos de configuración de ejemplo.

Capítulo 17. Berkeley Internet Name Domain (BIND)

En la mayoría de las redes modernas, incluyendo la Internet, los usuarios localizan otras máquinas por su nombre. Esto libera a los usuarios de la pesada tarea de recordar la dirección numérica de los recursos de red. La forma más efectiva de configurar una red para permitir tales conexiones basadas en nombres es configurando un servidor de nombres o DNS (siglas en inglés de Domain Name Service), el cual resuelve los nombres de hosts en la red a direcciones numéricas y viceversa.

Este capítulo revisa el servidor de nombres incluido en Red Hat Enterprise Linux, el servidor DNS Berkeley Internet Name Domain (BIND), con énfasis en la estructura de sus archivos de configuración y en cómo deberían ser administrados tanto local como remótamente.

Nota

BIND es también conocido como el servicio named en Red Hat Enterprise Linux. Puede administrarlo a través de la Herramienta de configuración de servicios (system-config-service).

17.1. Introducción a DNS

DNS asocia nombres de hosts con sus respectivas direcciones IP. Así, los usuarios pueden utilizar el nombre de host cuando desean conectarse a otras máquinas en la red sin tener que recordar las direcciones IP.

El uso de nombres de un dominio completamente cualificado (FQDN) y DNS brinda varias ventajas a los administradores de sistemas, ofreciéndoles flexibilidad a la hora de cambiar las direcciones IP para máquinas individuales sin afectar las peticiones a nombres en las máquinas. Por otro lado, los administradores pueden intercambiar las máquinas que manejan consultas basadas en nombre.

DNS es normalmente implementado usando servidores centralizados que autorizan algunos dominios y remiten a otros servidores DNS para otros dominios.

Cuando un host cliente solicita información desde un servidor de nombres, usualmente se conecta al puerto 53. El servidor de nombres intenta luego resolver el FQDN basado en su librería de resolución, la cual puede contener información de autorización sobre el host solicitado o datos en caché de una consulta anterior. Si el nombre del servidor no tiene la respuesta en su librería de resolución, consultará a otros servidores de nombres, llamados servidores de nombres de root, para determinar cuáles servidores de nombres son fidedignos para el FQDN en cuestión. Luego, con esa información, consulta los servidores de nombres autoritarios para determinar la dirección IP del host solicitado. Si se está realizando una búsqueda inversa, se usa el mismo procedimiento, excepto que la consulta es realizada con una dirección IP desconocida en vez de un nombre.

17.1.1. Zonas de servidores de nombres

En Internet, el FQDN de un host se puede dividir en diversas secciones. Estas secciones son organizadas en orden jerárquico (como un árbol), con un tronco, ramas principales, ramas secundarias, etc. Por ejemplo, considere el siguiente FQDN:

bob.sales.example.com

Para leer cómo un FQDN es resuelto para encontrar la dirección IP que se relaciona a un sistema particular, lea el nombre de derecha a izquierda, con cada nivel de la jerarquía dividido por puntos (.). En nuestro ejemplo, com define el dominio de nivel superior para este FQDN. El nombre example es un subdominio bajo com, mientras que sales es un subdominio bajo example. El nombre a la izquierda, bob, identifica el nombre de una máquina específica.

Aparte del nombre del dominio, cada sección se llama zona, la cual define un espacio de nombre particular. Un espacio de nombre, controla los nombres de los subdominios de la izquierda. Aunque en el ejemplo solamente hay dos subdominios, un FQDN tiene que contener al menos un subdominio, pero puede incluir muchos más dependiendo de la organización del espacio de nombres elegido.

Las zonas son definidas en servidores de nombres autorizados a través del uso de archivos de zona (los cuales describen el espacio de nombres de esa zona), los servidores de correo a ser utilizados por un dominio particular o sub-dominio y más. Los archivos de zona son almancenados en servidores de nombres primarios (también llamados servidores de nombres maestros), los cuales son autorizados y en donde los cambios se hacen a los archivos, y los servidores de nombres secundarios (también llamados servidores de nombres esclavos), que reciben sus archivos de zona desde los servidores de nombres primarios. Cualquier servidor de nombres puede ser un servidor primario y secundario para zonas diferentes al mismo tiempo, y también pueden ser considerados autoritarios para múltiples zonas. Todo depende de cómo se configure el servidor de nombres.

17.1.2. Tipos de servidores de nombres

Existen cuatro tipos de configuración de servidores de nombres primarios:

maestro

Almacena los registros de las zonas originales y de autoridad para un cierto espacio de nombres. Asimismo responde a consultas sobre el espacio de nombres de otros servidores de nombres.

esclavo

Responde a las peticiones que provienen de otros servidores de nombres y que se refieren a los espacios de nombres sobre los que tiene autoridad. Sin embargo, los servidores esclavos obtienen la información de sus espacios de nombres desde los servidores maestros.

de sólo caché

Ofrece servicios de resolución de nombres a direcciones IP pero no tiene ninguna autoridad sobre ninguna zona. Las respuestas en general se introducen en un caché por un período de tiempo fijo, el cual es especificado por el registro de zona recuperado.

reenvío

Reenvía las peticiones a una lista específica de servidores de nombres para la resolución de nombres. Si ninguno de los servidores de nombres especificados puede resolver los nombres, la resolución falla.

Un servidor de nombres puede ser uno o más de estos tipos. Por ejemplo, un servidor de nombres puede ser un maestro para algunas zonas, un esclavo para otras y sólo ofrecer el reenvío de resoluciones para otras.

17.1.3. BIND como un servidor de nombres

BIND realiza la resolución de nombres a través del demonio /usr/sbin/named. BIND también incluye una utilidad de administración llamada /usr/sbin/rndc. Se puede encontrar más información sobre rndc en Sección 17.4, “Uso de rndc.

BIND almacena sus archivos de configuración en los siguientes lugares:

/etc/named.conf

El archivo de configuración para el demonio named.

directorio /var/named/

El directorio de trabajo named el cual almacena zonas, estadísticas y archivos de caché.

Nota

Si tiene instalado el paquete bind-chroot, el servicio BIND será ejecutado en el entorno /var/named/chroot. Todos los archivos serán desplazados allí. Así, named.conf será ubicado en /var/named/chroot/etc/named.conf.

Consejo

Si ha instalado el paquete caching-nameserver, el archivo de configuración predeterminado es /etc/named.caching-nameserver.conf. Para sobreescribir esta configuración, usted puede crear su propio archivo de configuración en /etc/named.conf. Una vez reiniciado, BIND usará el archivo personalizado /etc/named.conf en vez del archivo de configuración predeterminado.

Las próximas secciones revisan los archivos de configuración de BIND en más detalle.

17.2. /etc/named.conf

El archivo named.conf es una colección de declaraciones que utilizan opciones anidadas rodeadas por corchetes, { }. Los administradores deben tener mucho cuidado cuando estén modificando named.conf para evitar errores sintácticos, puesto que hasta el error más pequeño puede impedir que el servicio named arranque.

Un archivo típico de named.conf está organizado de forma similar al siguiente ejemplo:

<statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-N>; }; <statement-2> ["<statement-2-name>"] [<statement-2-class>] { <option-1>; <option-2>; <option-N>; }; <statement-N> ["<statement-N-name>"] [<statement-N-class>] { <option-1>; <option-2>; <option-N>; };

17.2.1. Tipos de declaraciones comúnes

Los siguientes tipos de declaraciones son usadas a menudo en /etc/named.conf:

17.2.1.1. Declaración acl

La sentencia acl (o sentencia de control de acceso) define grupos de hosts a los que se les puede permitir o negar el acceso al servidor de nombres.

Una declaración acl tiene la siguiente forma:

acl <acl-name> { <match-element>; [<match-element>; ...] };

En esta declaración, sustituya <acl-name> con el nombre de la lista de control de acceso y reemplace <match-element> con una lista de direcciones IP separada por puntos y comas. La mayoría de las veces, una dirección IP individual o notación de red IP (tal como 10.0.1.0/24) es usada para identificar las direcciones IP dentro de la declaración acl.

Las siguientes listas de control de acceso ya están definidas como palabras claves para simplificar la configuración:

  • any — Coincide con todas las direcciones IP.

  • localhost — Coincide con cualquier dirección IP usada por el sistema local.

  • localnets — Coincide con cualquier dirección IP en cualquier red en la que el sistema local esté conectado.

  • none — No concuerda con ninguna dirección IP.

Cuando lo utilice con otras pautas (tales como las declaraciones options), las declaraciones acl pueden ser muy útiles para asegurar el uso correcto de su servidor de nombres BIND.

El ejemplo siguiente define dos listas de control de acceso y utiliza una declaración options para definir cómo son tratadas en el servidor de nombres:

acl black-hats {     
        10.0.2.0/24;     192.168.0.0/24;  };  
        acl red-hats {     10.0.1.0/24;  };  
options {     
        blackhole { black-hats; };     
        allow-query { red-hats; };     
        allow-recursion { red-hats; };  
}

Este ejemplo contiene dos listas de control de acceso, black-hats y red-hats. A los hosts en la lista black-hats se les niega el acceso al servidor de nombres, mientras que a los hosts en la lista red-hats se les dá acceso normal.

17.2.1.2. Declaración include

La declaración include permite incluir archivos en un named.conf. De esta forma los datos de configuración confidenciales (tales como llaves) se pueden colocar en un archivo separado con permisos restringidos.

Una declaración include tiene la forma siguiente:

include "<file-name>"

En esta declaración, <file-name> es reemplazado con la ruta absoluta de un archivo.

17.2.1.3. Declaración options

La declaración options define opciones de configuración de servidor globales y configura otras declaraciones por defecto. Puede ser usado para especificar la ubicación del directorio de trabajo named, los tipos de consulta permitidos y más.

La declaración options tiene la forma siguiente:

options { <option>; [<option>; ...] }; 

En esta declaración, las directivas <option> son reemplazadas con una opción válida.

Las siguientes son opciones usadas a menudo:

allow-query

Especifica cuáles hosts tienen permitido consultar este servidor de nombres. Por defecto, todos los hosts tienen derecho a realizar consultas. Una lista de control de acceso, o una colección de direcciones IP o redes se puede usar aquí para sólo permitir a hosts particulares hacer consultas al servidor de nombres.

allow-recursion

Parecida a la opción allow-query, salvo que se aplica a las peticiones recursivas. Por defecto, todos los hosts están autorizados a presentar peticiones recursivas en un servidor de nombres.

blackhole

Especifica cuáles hosts no tienen permitido consultar al servidor de nombres.

directory

Especifica el directorio de trabajo named si es diferente del valor predeterminado /var/named.

forwarders

Especifica una lista de direcciones IP válidas para los servidores de nombres donde las peticiones deben ser reenviadas para ser resueltas.

forward

Especifica el comportamiento de reenvío de una directiva forwarders.

Se aceptan las siguientes opciones:

  • first — Indica que los servidores de nombres especificados en la directiva forwarders sean consultados antes de que named intente resolver el nombre por sí mismo.

  • only — Especifica que named no intente la resolución de nombres por sí mismo cuando las consultas a los servidores de nombres especificados en la directriz forwarders fallen.

listen-on

Especifica la interfaz de red en la cual named escucha por solicitudes. Por defecto, todas las interfaces son usadas.

Al usar esta directiva en un servidor DNS que también actúa como un gateway, BIND puede ser configurado para sólo contestar solicitudes que se originan desde algunas de las redes.

El siguiente es un ejemplo de la directiva listen-on:

options { listen-on { 10.0.1.1; }; };

En este ejemplo, las peticiones que llegan desde la interfaz de red sirviendo a la red privada (10.0.1.1) son las únicas que se aceptan.

notify

Controla si named notifica a los servidores esclavos cuando una zona es actualizada. Acepta las opciones siguientes:

  • yes — Notifica a los servidores esclavos.

  • no — No notifica a los servidores esclavos.

  • explicit — Solamente notifica a los servidores esclavos especificados en una lista de also-notify dentro de la declaración de una zona.

pid-file

Especifica la ubicación del archivo del proceso ID creado por named.

root-delegation-only

Activa la implementación de las propiedades de delegación en dominios de nivel superior (TLDs) y zonas raíz con una lista opcional de exclusión. La delegación es el proceso de separar una zona sencilla en múltiples zonas. Para poder crear una zona delegada, se utilizan elementos conocidos como registros NS. Los registros de servidor de nombres (registros de delegación) declaran los servidores de nombres autorizados para una zona particular.

El siguiente ejemplo de root-delegation-only especifica una lista excluyente de los TDLs desde los que se esperan respuestas no delegadas:

options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id"; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; };
statistics-file

Permite especificar la localización alternativa de los archivos de estadísticas. Por defecto, las estadísticas de named son guardadas al archivo /var/named/named.stats.

Existen numerosas opciones disponibles, muchas de ellas dependen unas de otras para poder funcionar correctamente. Consulte el Manual de referencia para el administrador de BIND 9 en la Sección 17.7.1, “Documentación instalada” y la página man para bind.conf para más detalles.

17.2.1.4. Declaración zone

Una declaración zone define las características de una zona, tal como la ubicación de su archivo de configuración y opciones específicas de la zona. Esta declaración puede ser usada para ignorar las declaraciones globales options.

Una declaración zone tiene la forma siguiente:

zone <zone-name><zone-class> { <zone-options>; [<zone-options>; ...] };

En esta declaración, <zone-name> es el nombre de la zona, <zone-class> es la clase opcional de la zona, y <zone-options> es una lista de opciones que caracterizan la zona.

El atributo <zone-name> para la declaración de zona es particularmente importante, pues es el valor por defecto asignado para la directriz $ORIGIN usada dentro del archivo de zona correspondiente localizado en el directorio /var/named/. El demonio named anexa el nombre de la zona a cualquier nombre de dominio que no esté completamente cualificado listado en el archivo de zona.

Nota

Si ha instalado el paquete caching-nameserver, el archivo de configuración predeterminado estará en /etc/named.rfc1912.zones.

Por ejemplo, si una declaración zone define el espacio de nombres para example.com, utilice example.com como el <zone-name> para que sea colocado al final de los nombres de hosts dentro del archivo de zona example.com.

Para obtener mayor información sobre los archivos de zona, consulte Sección 17.3, “Archivos de zona”.

Las opciones más comunes para la declaración zone incluyen lo siguiente:

allow-query

Especifica los clientes que se autorizan para pedir información sobre una zona. Por defecto, todas las peticiones de información son autorizadas.

allow-transfer

Especifica los servidores esclavos que están autorizados para pedir una transferencia de información de la zona. Por defecto, todas las peticiones se autorizan.

allow-update

Especifica los hosts que están autorizados para actualizar dinámicamente la información en sus zonas. Por defecto, no se autoriza la actualización dinámica de la información.

Tenga cuidado cuando autorice a los hosts para actualizar la información de su zona. No habilite esta opción si no tiene confianza en el host que vaya a usar. Es mejor que el administrador actualice manualmente los registros de zona y que vuelva a cargar el servicio named.

file

Especifica el nombre del archivo en el directorio de trabajo named que contiene los datos de configuración de zona.

masters

Especifica las direcciones IP desde las cuales solicitar información autorizada. Solamente se usa si la zona está definida como typeslave.

notify

Controla si named notifica a los servidores esclavos cuando una zona es actualizada. Esta directiva sólo acepta las opciones siguientes:

  • yes — Notifica a los servidores esclavos.

  • no — No notifica a los servidores esclavos.

  • explicit — Solamente notifica a los servidores esclavos especificados en una lista de also-notify dentro de la declaración de una zona.

type

Define el tipo de zona.

Abajo se muestra una lista de las opciones válidas:

  • delegation-only — Refuerza el estado de delegación de las zonas de infraestructura tales como COM, NET u ORG. Cualquier respuesta recibida sin una delegación explícita o implícita es tratada como NXDOMAIN. Esta opción solamente es aplicable en TLDs o en archivos raíz de zona en implementaciones recursivas o de caché.

  • forward — Dice al servidor de nombres que lleve a cabo todas las peticiones de información de la zona en cuestión hacia otros servidores de nombres.

  • hint — Tipo especial de zona que se usa para orientar hacia los servidores de nombres root que sirven para resolver peticiones de una zona que no se conoce. No se requiere mayor configuración que la establecida por defecto en una zona hint.

  • master — Designa el servidor de nombres actual como el servidor autoritativo para esa zona. Una zona se puede configurar como tipo master si los archivos de configuración de la zona residen en el sistema.

  • slave — Designa el servidor de nombres como un servidor esclavo para esa zona. También especifica la dirección IP del servidor de nombres maestro para la zona.

zone-statistics

Configura named para mantener estadísticas concerniente a esta zona, escribiéndola a su ubicación por defecto (/var/named/named.stats) o al archivo listado en la opción statistics-file en la declaración server. Consulte la Sección 17.2.2, “Otros tipos de declaraciones” para más información sobre la declaración server.

17.2.1.5. Ejemplo de declaraciones de zone

La mayoría de los cambios al archivo /etc/named.conf de un servidor de nombres maestro o esclavo envuelven agregar, modificar o borrar declaraciones zone. Mientras que estas declaraciones zone pueden contener muchas opciones, la mayoría de los servidores de nombres requieren sólo un pequeño subconjunto para funcionar efectivamente. Las siguientes declaraciones zone son ejemplos muy básicos que ilustran la relación de servidores de nombres maestro-esclavo.

A continuación se muestra un ejemplo de una declaración de zone para un servidor de nombres primario hospedando example.com (192.168.0.1):

zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };

En la declaración, la zona es identificada como example.com, el tipo es configurado a master y el servicio named se instruye para leer el archivo /var/named/example.com.zone. También le dice a named que no permita a ningún otro host que realice actualizaciones.

Una declaración zone de servidor esclavo para example.com se ve un poco diferente comparado con el ejemplo anterior. Para un servidor esclavo, el tipo se coloca a slave y en lugar de la línea allow-update está una directiva diciéndole a named la dirección IP del servidor maestro.

A continuación se muestra un ejemplo de una declaración zone para un servidor esclavo para la zona example.com:

zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };

Esta declaración zone configura named en el servidor esclavo para que busque el servidor maestro en la dirección IP 192.168.0.1 para obtener información sobre la zona example.com. La información que el servidor esclavo recibe desde el servidor maestro es guardada en el archivo /var/named/example.com.zone.

17.2.2. Otros tipos de declaraciones

La lista siguiente muestra tipos de declaraciones usadas con menos frecuencia disponibles dentro de named.conf:

controls

Configura varios requerimientos de seguridad necesarios para usar el comando rndc para administrar el servicio named.

Consulte la Sección 17.4.1, “Configuración de /etc/named.conf para obtener mayor información sobre la estructura de la declaración controls y de las opciones que están disponibles.

key "<key-name>"

Define una llave particular por nombre. Las claves son usadas para autenticar varias acciones, tales como actualizaciones seguras o el uso del comando rndc. Se usan dos opciones con key:

  • algorithm <algorithm-name> — El tipo de algoritma usado, tal como dsa o hmac-md5.

  • secret "<key-value>" — La clave encriptada.

Consulte la Sección 17.4.2, “Configuración de /etc/rndc.conf para instrucciones sobre cómo escribir una declaración key.

logging

Permite el uso de múltiples tipos de registro, llamados channels. Usando la opción channel dentro de la declaración logging, se puede construir un tipo de registro personalizado — con su propio nombre de archivo (file), tamaño límite (size), versión (version), y nivel de importancia (severity). Una vez el canal personalizado ha sido definido, se usa una opción category para clasificar el canal y comenzar las conexiones cuando se reinicie named.

Por defecto, named registra mensajes estándar al demonio syslog, que les sitúa en /var/log/messages. Esto se debe a que varios canales estándares se encuentran incorporados a BIND junto con varios niveles de severidad, tales como default_syslog (el cual maneja la información de mensajes de registros) y default_debug (que maneja mensajes de depuración). Una categoría por defecto, llamada default, usa los canales incorporados para hacer conexiones normales sin ninguna configuración especial.

La personalización del proceso de conexión es un proceso con muchos detalles que está más allá del objetivo de este capítulo. Para información sobre la creación de registros personalizados BIND, consulte el Manual de referencia del administrador de BIND 9 mencionado en la Sección 17.7.1, “Documentación instalada”.

server

Define opciones particulares que afectan como named debería actuar con respecto a servidores de nombres remotos, especialmente en lo que respecta a las notificaciones y transferencias de zonas.

La opción transfer-format controla si un registro de recursos es enviado con cada mensaje (one-answer) o si registros de múltiples recursos son enviados con cada mensaje (many-answers). Mientras que many-answers es más eficiente, sólo los nuevos servidores de nombres BIND lo entienden.

trusted-keys

Contiene llaves públicas utilizadas por DNS seguro, DNSSEC. Para mayor información sobre la seguridad de BIND, consulte la Sección 17.5.3, “Seguridad”.

view "<view-name>"

Crea vistas especiales dependiendo de la en la cual está el host que contacta el servidor de nombres. Esto permite a determinados hosts recibir una respuesta que se refiere a una zona particular mientras que otros hosts reciben información completamente diferente. Alternativamente, algunas zonas pueden estar disponibles para ciertos hosts de confianza únicamente mientras que otros hosts menos autorizados sólo pueden hacer peticiones a otras zonas.

Se pueden usar múltiples visualizaciones, siempre y cuando sus nombres sean únicos. La opción match-clients especifica las direcciones IP que aplican a una vista particular. Cualquier declaración de options puede también ser usada dentro de una vista, ignorando las opciones globales ya configuradas por named. La mayoría de las declaraciones view contienen múltiples declaraciones zone que aplican a la lista match-clients. El orden en que las declaraciones view son listadas es importante, pues la primera declaración view que coincida con una dirección IP de cliente particular es usada.

Consulte la Sección 17.5.2, “Vistas múltiples” para obtener mayor información sobre la declaración view.

17.2.3. Etiquetas de comentarios

La siguiente es una lista de las etiquetas de comentarios válidas usadas dentro de named.conf:

  • // — Cuando se coloca al comienzo de una línea, esa línea es ignorada por named.

  • # — Cuando se coloca al comienzo de una línea, esa línea es ignorada por named.

  • /* y */ — Cuando el texto se coloca entre estas etiquetas, se ignora el bloque de texto por named.

17.3. Archivos de zona

Los Archivos de zona contienen información sobre un espacio de nombres particular. Éstos son almacenados en el directorio de trabajo named, por defecto /var/named/. Cada archivo de zona es nombrado de acuerdo a la opción file en la declaración zone, usualmente en una forma que relaciona al dominio en cuestión e identifica el archivo como un archivo que contiene datos de zona, tal como example.com.zone.

Nota

Si ha instalado el paquete bind-chroot, el servicio BIND será ejecutado en el entorno /var/named/chroot. Todos los archivos de configuración serán desplazados allí. Así, usted podrá encontrar los archivos de zona en /var/named/chroot/var/named.

Cada archivo de zona contiene directivas y registros de recursos. Las directivas le dicen al servidor de nombres que realice tareas o aplique configuraciones especiales a la zona. Los registros de recursos definen los parámetros de la zona y asignan identidades a hosts individuales. Las directivas son opcionales, pero los registros de recursos se requieren para proporcionar servicios de nombres a la zona.

Todas las directivas y registros de recursos deberían ir en sus propias líneas individuales.

Los comentarios se pueden colocar después de los punto y comas (;) en archivos de zona.

17.3.1. Directivas de archivos de zona

Las directivas comienzan con el símbolo de dollar ($) seguido del nombre de la directiva. Usualmente aparecen en la parte superior del archivo de zona.

Las siguientes son directivas usadas a menudo:

$INCLUDE

Configura a named para que incluya otro archivo de zona en el archivo de zona donde se usa la directiva. Así se pueden almacenar configuraciones de zona suplementarias aparte del archivo de zona principal.

$ORIGIN

Anexa el nombre del dominio a registros no cualificados, tales como aquellos con el nombre de host solamente.

Por ejemplo, un archivo de zona puede contener la línea siguiente:

$ORIGIN example.com.

Cualquier nombre utilizado en registros de recursos que no terminen en un punto (.) tendrán example.com anexado.

Nota

El uso de la directiva $ORIGIN no es necesario si la zona es especificada en /etc/named.conf porque la zona es usada como el valor de la directiva $ORIGIN por defecto.

$TTL

Ajusta el valor Time to Live (TTL) predeterminado para la zona. Este es el tiempo, en segundos, que un registro de recurso de zona es válido. Cada recurso puede contener su propio valor TTL, el cual ignora esta directiva.

Cuando se decide aumentar este valor, permite a los servidores de nombres remotos hacer caché a la información de zona para un período más largo de tiempo, reduciendo el número de consultas para la zona y alargando la cantidad de tiempo requerido para proliferar cambios de registros de recursos.

17.3.2. Registros de recursos de archivos de zona

El componente principal de un archivo de zona es su registro de recursos.

Hay muchos tipos de registros de recursos de archivos de zona. A continuación le mostramos los tipos de registros más frecuentes:

A

Registro de dirección que especifica una dirección IP que se debe asignar a un nombre, como en el siguiente ejemplo:

<host> IN A <IP-address>

Si el valor <host> es omitido, el registro A apunta a una dirección IP por defecto para la parte superior del espacio de nombres. Este sistema es el objetivo para todas las peticiones no FQDN.

Considere el siguiente ejemplo de registro A para el archivo de zona example.com:

server1 IN A 10.0.1.3 IN A 10.0.1.5

Las peticiones para example.com apuntan a 10.0.1.3 o 10.0.1.5.

CNAME

Se refiere al Registro del nombre canónico, el cual enlaza un nombre con otro. Esta clase de registros es también conocido como un alias record.

El próximo ejemplo indica a named que cualquier petición enviada a <alias-name> apuntará al host, <real-name>. Los registros CNAME son usados normalmente para apuntar a servicios que usan un esquema de nombres común, tal como www para servidores Web.

<alias-name> IN CNAME <real-name>

En el ejemplo siguiente, un registro A vincula un nombre de host a una dirección IP, mientras que un registro CNAME apunta al nombre host www comúnmente utilizado para éste.

server1 IN A 10.0.1.5 www IN CNAME server1
MX

Registro de Mail eXchange, el cual indica dónde debería ir el correo enviado a un espacio de nombres particular controlado por esta zona.

 IN MX <preference-value><email-server-name>

En este ejemplo, <preference-value> permite una clasificación numérica de los servidores de correo para un espacio de nombres, dando preferencia a algunos sistemas de correo sobre otros. El registro de recursos MX con el valor más bajo <preference-value> es preferido sobre los otros. Sin embargo, múltiples servidores de correo pueden tener el mismo valor para distribuir el tráfico de forma pareja entre ellos.

El <email-server-name> puede ser un nombre de servidor o FQDN.

 IN MX 10 mail.example.com. IN MX 20 mail2.example.com.

En este ejemplo, el primer servidor de correo mail.example.com es preferido al servidor de correo mail2.example.com cuando se recibe correo destinado para el dominio example.com.

NS

Se refiere al Registro NameServer, el cual anuncia los nombres de servidores con autoridad para una zona particular.

El siguiente ejemplo es un ejemplo de un registro NS:

 IN NS <nameserver-name>

Aquí, el <nameserver-name> debería ser un FQDN.

Luego, dos nombres de servidores son listados como servidores con autoridad para el dominio. No es importante si estos nombres de servidores son esclavos o maestros; ambos son todavía considerados como servidores con autoridad.

 IN NS dns1.example.com. IN NS dns2.example.com.
PTR

Registro PoinTeR (puntero), diseñado para apuntar a otra parte del espacio de nombres.

Los registros PTR son usados principalmente para la resolución inversa de nombres, pues ellos apuntan direcciones IP de vuelta a un nombre particular. Consulte la Sección 17.3.4, “Archivos de zona de resolución de nombres inversa” para más ejemplos de registros PTR en uso.

SOA

Registro de recursos Start Of Authority, que declara información importante de autoridad relacionada con espacios de nombres al servidor de nombres.

Está situado detrás de las directivas, un registro SOA es el primer registro en un archivo de zona.

El ejemplo siguiente muestra la estructura básica de un registro de recursos SOA:

@ IN SOA <primary-name-server><hostmaster-email> ( <serial-number><time-to-refresh><time-to-retry><time-to-expire><minimum-TTL> )

El símbolo @ coloca la directiva $ORIGIN (o el nombre de la zona, si la directiva $ORIGIN no está configurada) como el espacio de nombres que esta siendo definido por este registro de recursos SOA. El nombre del host del servidor de nombres que tiene autoridad para este dominio es la directiva <primary-name-server> y el correo electrónico de la persona a contactar sobre este espacio de nombres es la directiva <hostmaster-email>.

La directiva <serial-number> es un valor numérico que es incrementado cada vez que se cambia el archivo de zona para así indicar a named que debería recargar esta zona. La directiva <time-to-refresh> es el valor numérico que los servidores esclavos utilizan para determinar cuánto tiempo debe esperar antes de preguntar al servidor de nombres maestro si se han realizado cambios a la zona. El valor <serial-number> es usado por los servidores esclavos para determinar si esta usando datos de la zona desactualizados y si debería refrescarlos.

La directiva <time-to-retry> es un valor numérico usado por los servidores esclavos para determinar el intervalo de tiempo que tiene que esperar antes de emitir una petición de actualización de datos en caso de que el servidor de nombres maestro no responda. Si el servidor maestro no ha respondido a una petición de actualización de datos antes de que se acabe el intervalo de tiempo <time-to-expire>, los servidores esclavos paran de responder como una autoridad por peticiones relacionadas a ese espacio de nombres.

La directiva <minimum-TTL> es la cantidad de tiempo que otros servidores de nombres guardan en caché la información de zona.

Cuando se configura BIND, todos los tiempos son siempre referenciados en segundos. Sin embargo, es posible usar abreviaciones cuando se especifiquen unidades de tiempo además de segundos, tales como minutos (M), horas (H), días (D) y semanas (W). La Tabla 17.1, “Segundos comparados a otras unidades de tiempo” le muestra la cantidad de tiempo en segundos y el tiempo equivalente en otro formato.

Segundos Otras unidades de tiempo
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D
Tabla 17.1. Segundos comparados a otras unidades de tiempo

El ejemplo siguiente ilustra la forma que un registro de recursos SOA puede tomar cuando es configurado con valores reales.

@ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day

17.3.3. Ejemplo de archivo de zonas

Vistos individualmente, las directivas y registros de recursos pueden ser difíciles de comprender. Sin embargo, cuando se colocan juntos en un mismo archivo, se vuelven más fáciles de entender.

El ejemplo siguiente muestra un archivo de zona muy básico.

$ORIGIN example.com. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. dns1 IN A 10.0.1.1 dns2 IN A 10.0.1.2 server1 IN A 10.0.1.5 server2 IN A 10.0.1.6 ftp IN A 10.0.1.3 IN A 10.0.1.4 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server1

En este ejemplo, las directivas estándar y los valores SOA son usados. Los servidores de nombres con autoridad se configuran como dns1.example.com y dns2.example.com, que tiene registros A que los relacionan con 10.0.1.1 y 10.0.1.2, respectivamente.

Los servidores de correo configurados con los registros MX apuntan a server1 y server2 a través de registros CNAME. Puesto que los nombres server1 y server2 no terminan en un punto (.), el dominio $ORIGIN es colocado después de ellos, expandiéndolos a server1.example.com y a server2.example.com. A través de registros de recursos relacionados A, se puede determinar sus direcciones IP.

Los servicios FTP y Web, disponibles en los nombres estándar ftp.example.com y www.example.com, son apuntados a los servidores apropiados usando registros CNAME.

Este archivo de zona se colocará en funcionamiento con una declaración zone en el archivo named.conf el cual se ve similar a lo siguiente:

zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };

17.3.4. Archivos de zona de resolución de nombres inversa

Se usa un archivo de zona de resolución inversa de nombres para traducir una dirección IP en un espacio de nombres particular en un FQDN. Se vé muy similar a un archivo de zona estándar, excepto que se usan registros de recursos PTR para enlazar las direcciones IP a un nombre de dominio completamente cualificado.

El ejemplo siguiente muestra la estructura básica de un registro de recursos PTR:

<last-IP-digit> IN PTR <FQDN-of-system>

El valor <last-IP-digit> se refiere al último número en una dirección IP que apunta al FQDN de un sistema particular.

En el ejemplo siguiente, las direcciones IP de la 10.0.1.1 a la 10.0.1.6 apuntan a los FQDNs correspondientes. Pueden ser ubicadas en /var/named/example.com.rr.zone.

$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.

Este archivo de zona se colocará en funcionamiento con una declaración zone en el archivo named.conf el cual se ve similar a lo siguiente:

zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };

Hay muy poca diferencia entre este ejemplo y una declaración de zone estándar, excepto por el nombre de la zona. Observe que una zona de resolución de nombres inversa requiere que los primeros tres bloques de la dirección IP estén invertidos seguido por .in-addr.arpa. Esto permite asociar con la zona a un bloque único de números IP usados en el archivo de zona de resolución de nombres inversa.

17.4. Uso de rndc

BIND incluye una utilidad llamada rndc que permite la administración a través de la línea de comandos del demonio named desde el host local o desde un host remoto.

Para prevenir el acceso no autorizado al demonio named, BIND utiliza un método de autenticación de llave secreta compartida para otorgar privilegios a hosts. Esto significa que una llave idéntica debe estar presente en los archivos de configuración /etc/named.conf y en el /etc/rndc.conf de rndc.

Nota

Si ha instalado el paquete bind-chroot, el servicio BIND será ejecutado en el entorno /var/named/chroot. Todos los archivos de configuración serán desplazados allí. Así, el archivo rndc.conf estará ubicado en /var/named/chroot/etc/rndc.conf.

Tenga en cuenta que la utilidad rndc no se ejecuta en un entorno chroot, por lo cual /etc/rndc.conf es un enlace simbólico a /var/named/chroot/etc/rndc.conf.

17.4.1. Configuración de /etc/named.conf

Para que rndc se pueda conectar a un servicio named, debe haber una declaración controls en el archivo de configuración del servidor BIND /etc/named.conf.

La declaración controls mostrada abajo en el ejemplo siguiente, permite a rndc conectarse desde un host local.

controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>; }; };

Esta declaración le dice a named que escuche en el puerto por defecto TCP 953 de la dirección loopback y que permita comandos rndc provenientes del host local, si se proporciona la llave correcta. El valor <key-name> especifica un nombre en la declaración key dentro del archivo /etc/named.conf. El ejemplo siguiente ilustra la declaración key.

key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };

En este caso, el <key-value> utiliza el algoritmo HMAC-MD5. Utilice el comando siguiente para generar llaves usando el algoritmo HMAC-MD5:

dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>

Es aconsejable crear una llave con al menos 256-bit de longitud. La llave que debería ser colocada en el área <key-value> se puede encontrar en el archivo <key-file-name> generado por este comando.

Advertencia

Debido a que /etc/named.conf es universalmente accesible, es aconsejable colocar la declaración key en un archivo separado que sólo sea accesible por root y luego utilizar una declaración include para referenciarlo. Por ejemplo:

include "/etc/rndc.key";

17.4.2. Configuración de /etc/rndc.conf

La declaración key es la más importante en /etc/rndc.conf.

key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; };

<key-name> y <key-value> deberían ser exáctamente los mismos que sus configuraciones en /etc/named.conf.

Para hacer coincidir las claves especificadas en el archivo de configuración del servidor objetivo /etc/named.conf, agregue las líneas siguientes a /etc/rndc.conf.

options { default-server localhost; default-key "<key-name>"; };

Este directriz configura un valor de llave global por defecto. Sin embargo, el archivo de configuración rndc también puede usar llaves diferentes para servidores diferentes, como en el ejemplo siguiente:

server localhost { key "<key-name>"; };

Importante

Asegúrese de que sólo el usuario root pueda leer y escribir al archivo /etc/rndc.conf.

Para más información sobre el archivo /etc/rndc.conf, vea la página man de rndc.conf.

17.4.3. Opciones de línea de comandos

Un comando rndc tiene la forma siguiente:

rndc <options><command><command-options>

Cuando esté ejecutando rndc en una máquina local configurada de la forma correcta, los comandos siguientes están disponibles:

  • halt — Detiene inmediatamente el servicio named.

  • querylog — Registra todas las peticiones hechas a este servidor de nombres.

  • refresh — Refresca la base de datos del servidor de nombres.

  • reload — Recarga los archivos de zona pero mantiene todas las respuestas precedentes situadas en caché. Esto le permite realizar cambios en los archivos de zona sin perder todas las resoluciones de nombres almacenadas.

    Si los cambios sólo afectaron una zona específica, vuelva a cargar esa zona añadiendo el nombre de la zona después del comando reload.

  • stats — Descarga las estadísticas actuales de named al archivo /var/named/named.stats.

  • stop — Detiene al servidor salvando todas las actualizaciones dinámicas y los datos de las Transferencias de zona incremental (IXFR) antes de salir.

Ocasionalmente, puede ser necesario ignorar las configuraciones por defecto en el archivo /etc/rndc.conf. Están disponibles las siguientes opciones:

  • -c <configuration-file> — Especifica la ubicación alterna de un archivo de configuración.

  • -p <port-number> — Especifica la utilización de un número de puerto diferente del predeterminado 953 para la conexión del comando rndc.

  • -s <server> — Especifica un servidor diferente al default-server listado en /etc/rndc.conf.

  • -y <key-name> — Le permite especificar una llave distinta de la opción default-key en el archivo /etc/rndc.conf.

Se puede encontrar información adicional sobre estas opciones en la página del manual de rndc.

17.5. Características avanzadas de BIND

La mayoría de las implementaciones BIND solamente utilizan named para proporcionar servicios de resolución de nombres o para actuar como una autoridad para un dominio particular o sub-dominio. Sin embargo, la versión 9 de BIND tiene un número de características avanzadas que permiten un servicio DNS más seguro y avanzado.

Atención

Algunas de estas propiedades avanzadas, tales como DNSSEC, TSIG e IXFR (las cuales se definen en la sección siguiente), solamente se deberían usar en los entornos de red que tengan servidores de nombres que soporten estas propiedades. Si su entorno de red incluye servidores de nombres no-BIND o versiones anteriores de BIND, verifique que cada característica avanzada sea soportada antes de intentar utilizarla.

Todas las propiedades citadas aquí se describen en detalle en el Manual de referencia para el administrador de BIND 9 referenciado en la Sección 17.7.1, “Documentación instalada”.

17.5.1. Mejoras al protocolo DNS

BIND soporta Transferencias de zona incremental (Incremental Zone Transfers, IXFR), donde un servidor de nombres esclavo sólo descargará las porciones actualizadas de una zona modificada en un servidor de nombres maestro. El proceso de transferencia estándar requiere que la zona completa sea transferida a cada servidor de nombres esclavo hasta por el cambio más pequeño. Para dominios muy populares con archivos de zona muy largos y muchos servidores de nombres esclavos, IXFR hace que la notificación y los procesos de actualización sean menos exigentes en recursos.

Observe que IXFR solamente está disponible cuando utiliza la actualización dinámica para realizar los cambios en los registros de zona maestra. Si cambia los archivos de zona manualmente, se utilizará AXFR (Automatic Zone Transfer). Encontrará más información sobre la actualización dinámica en el Manual de referencia para el administrador de BIND 9. Consulte la Sección 17.7.1, “Documentación instalada” para más información.

17.5.2. Vistas múltiples

A través del uso de la declaración view en named.conf, BIND puede presentar información diferente dependiendo de la red desde la cual se esté realizando la petición.

Esta característica es básicamente utilizada para negar entradas DNS confidenciales a clientes fuera de la red local, mientras se permiten consultas desde clientes dentro de la red local.

La declaración view usa la opción match-clients para coincidir direcciones IP o redes completas y darles opciones especiales y datos de zona.

17.5.3. Seguridad

BIND soporta un número de métodos diferentes para proteger la actualización y zonas de transferencia, en los servidores de nombres maestro y esclavo:

DNSSEC

Abreviación de DNS SECurity, esta propiedad permite firmar criptográficamente las zonas con una clave de zona.

De esta manera puede verificar que la información de una zona provenga de un servidor de nombres que la ha firmado con una llave privada, siempre y cuando el recipiente tenga esa llave pública del servidor de nombres.

La versión 9 de BIND también soporta el método SIG(0) de llave pública/privada de autenticación de mensajes.

TSIG

Abreviación para Transaction SIGnatures, esta característica permite una transferencia desde el maestro al esclavo solamente después de verificar que una llave secreta compartida existe tanto en el servidor maestro como en el esclavo.

Esta característica fortalece el método estándar basado en direcciones IP de transferencia de autorización. Un intruso no solamente necesitará acceso a la dirección IP para transferir la zona, sino también necesitará conocer la clave secreta.

BIND versión 9 también soporta TKEY, el cual es otro método de autorización de zonas de transferencia basado en clave secreta compartida.

17.5.4. IP versión 6

BIND versión 9 puede proporcionar servicios de nombres en ambientes IP versión 6 (IPv6) a través del uso de registros de zona A6.

Si el entorno de red incluye hosts IPv4 e IPv6, use el demonio ligero de resolución lwresd en todos los clientes de la red. Este demonio es muy eficiente, funciona solamente en caché y además entiende los nuevos registros A6 y DNAME usados bajo IPv6. Consulte la página de manual para lwresd para más información.

17.6. Errores comunes que debe evitar

Es normal que los principiantes cometan errores modificando los archivos de configuración de BIND. Asegúrese de evitar los siguientes errores:

  • Incremente el número de serie cuando esté modificando un archivo de zona.

    Si no se incrementa el número de serie, el servidor de nombres maestro tendrá la información nueva correcta, pero los servidores esclavos nunca serán notificados del cambio ni intentarán actualizar sus datos de esa zona.

  • Preste atención a la utilización correcta de las llaves y de los puntos y comas en el archivo /etc/named.conf.

    La omisión de un punto y coma o de una llave en una sección causará que named se niegue a arrancar.

  • Recuerde colocar puntos (.) en los archivos de zona después de todos los FQDNs y omítalos en los nombres de máquinas.

    Un punto al final de un nombre de dominio denota un nombre de dominio completamente cualificado. Si el punto es omitido, entonces named añade el nombre de la zona o el valor $ORIGIN para completarlo.

  • Si un cortafuegos está bloqueando las conexiones con el programa named a otros servidores de nombres, modifique su archivo de configuración.

    Por defecto, la versión 9 de BIND usa los puertos aleatorios por encima de 1024 para consultar otros servidores de nombres. Algunos cortafuegos, sin embargo, esperan que todos los servidores de nombres se comuniquen usando solamente el puerto 53. Puede forzar named a que use el puerto 53 añadiendo la línea siguiente a la declaración options de /etc/named.conf:

    query-source address * port 53;
    

17.7. Recursos adicionales

Las siguientes fuentes de información le proporcionarán recursos adicionales relacionados a BIND.

17.7.1. Documentación instalada

BIND contiene una larga variedad de documentación que cubre diferentes tópicos, cada uno de ellos ubicado en su propio directorio. Por cada elemento, reemplace <version-number> con la versión de bind instalada en el sistema:

/usr/share/doc/bind-<version-number>/

Este directorio enumera las características más recientes.

/usr/share/doc/bind-<version-number>/arm/

Este directorio contiene una versión en HTML y SGML del Manual de referencia para el administrador de BIND 9, el cual detalla los requerimientos de recursos de BIND, cómo configurar diferentes tipos de servidores de nombres, balancear cargas y otros temas avanzados. Para la mayoría de los usuarios nuevos de BIND, este es el mejor lugar para comenzar.

/usr/share/doc/bind-<version-number>/draft/

Este directorio contiene documentos técnicos ordenados concernientes al servicio DNS y que proponen métodos para abordarlo.

/usr/share/doc/bind-<version-number>/misc/

Este directorio contiene documentos diseñados para referenciar problemas avanzados. Los usuarios de la versión 8 de BIND deberían consultar el documento migration para cambios específicos que se deben hacer cuando se esté moviendo a BIND 9. El archivo options lista todas las opciones implementadas en BIND 9 que son usadas en el archivo /etc/named.conf.

/usr/share/doc/bind-<version-number>/rfc/

Este directorio proporciona cada documento RFC relacionado con BIND.

Hay un gran número de páginas man para las diferentes aplicaciones y archivos de configuración referentes a BIND. La siguiente es una lista de algunas de las páginas importantes.

Aplicaciones administrativas
  • La página man rndc — Explica las diferentes opciones disponibles cuando se utilice el comando rndc para controlar un servidor de nombres BIND.

Aplicaciones de servidor
  • La página man named — Explora argumentos varios que se pueden usar para controlar el demonio de servidor de nombres BIND.

  • man lwresd — Describe las opciones disponibles y el propósito para el demonio lightweight resolver.

Archivos de configuración
  • La página man named.conf — Una lista completa de las opciones disponibles dentro del archivo de configuración named.

  • La página man rndc.conf — Una lista completa de opciones disponibles dentro del archivo de configuración rndc.

17.7.2. Sitios web de utilidad

17.7.3. Libros relacionados

  • DNS y BIND por Paul Albitz y Cricket Liu; O'Reilly & Associates — Una referencia popular que explica opciones de configuración comunes y esotéricas de BIND, así como también proporciona estrategias para asegurar su servidor DNS.

  • The Concise Guide to DNS and BIND por Nicolai Langfeldt; Que — Hace referencia a la conexión entre servicios de red múltiples y BIND, haciendo énfasis en los tópicos técnicos orientados a tareas.

Capítulo 18. OpenSSH

SSH™ (o Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host remotamente. A diferencia de otros protocolos de comunicación remota tales como FTP o Telnet, SSH encripta la sesión de conexión, haciendo imposible que alguien pueda obtener contraseñas no encriptadas.

SSH está diseñado para reemplazar aplicaciones de terminal anteriores y menos seguras que eran utilizadas para registrarse remotamente, tales como telnet o rsh. Un programa relacionado, el scp, reemplaza otros programas diseñados para copiar archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, evite usarlas en lo posible. El uso de métodos seguros para registrarse remotamente a otros sistemas reduce los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto.

18.1. Características de SSH

El protocolo SSH proporciona los siguientes tipos de protección:

  • Después de la conexión inicial, el cliente puede verificar que se está conectando al mismo servidor al que se conectó anteriormente.

  • El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits.

  • Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremadamente difícil de descifrar y leer.

  • El cliente tiene la posibilidad de reenviar aplicaciones X11 [5] desde el servidor. Esta técnica, llamada reenvío por X11, proporciona un medio seguro para usar aplicaciones gráficas sobre una red.

Ya que el protocolo SSH encripta todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para asegurar los protocolos inseguros, como por ejemplo POP, mediante el uso de una técnica llamada reenvío por puerto. Utilizando este método se incrementa la seguridad del sistema en general y la seguridad de los datos.

El servidor y cliente OpenSSH pueden también ser configurados para crear un túnel similar a una red privada virtual para el tráfico entre el cliente y el servidor.

Red Hat Enterprise Linux contiene el paquete general de OpenSSH (openssh) así como también los paquetes del servidor OpenSSH (openssh-server) y del cliente (openssh-clients). Tenga en cuenta que los paquetes OpenSSH requieren el paquete OpenSSL (openssl). OpenSSL instala varias bibliotecas criptográficas importantes, permitiendo que OpenSSH pueda proporcionar comunicaciones encriptadas.

18.1.1. ¿Por qué usar SSH?

Los usuarios malignos tienen a su disposición una variedad de herramientas que les permiten interceptar y redirigir el tráfico de la red para ganar acceso al sistema. En términos generales, estas amenazas se pueden catalogar del siguiente modo:

  • Intercepción de la comunicación entre dos sistemas — En este escenario, el atacante puede estar en algún lugar de la red entre entidades en comunicación que hace una copia de la información que pasa entre ellas. El atacante puede interceptar y conservar la información o puede modificar la información y luego enviarla al recipiente al cual estaba destinada.

    Este ataque se puede realizar a través del uso de un paquete sniffer —una utilidad de red muy común.

  • Personificación de un determinado host — Con esta estrategia, el sistema de un atacante se configura para fingir ser el recipiente a quien está destinado un mensaje. Si funciona la estrategia, el sistema del usuario no se da cuenta del engaño y continúa la comunicación con el host incorrecto.

    Este ataque puede realizarse con técnicas como el envenenamiento del DNS [6] o spoofing de IP (engaño de direcciones IP) [7]

Ambas técnicas interceptan información potencialmente confidencial y si esta intercepción se realiza con propósitos hostiles, el resultado puede ser catastrófico.

Si se utiliza SSH para inicios de sesión de shell remota y para copiar archivos, se pueden disminuir notablemente estas amenazas a la seguridad. Esto es porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicación entre los sistemas cliente y servidor es encriptada. No servirá de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicación ya que cada paquete está cifrado por medio de una llave conocida sólo por el sistema local y el remoto.

18.2. Versiones del protocolo SSH

El protocolo SSH permite a cualquier programa cliente y servidor construido según las especificaciones del protocolo comunicarse de forma segura y de forma intercambiable.

En la actualidad existen dos variedades de SSH (versión 1 y versión 2). La suite OpenSSH bajo Red Hat Enterprise Linux utiliza por defecto la versión 2 de SSH, la cual tiene un algoritmo de intercambio de llaves mejorado que no es vulnerable al hueco de seguridad en la versión 1. Sin embargo, la suite OpenSSH también soporta las conexiones de la versión 1.

Importante

Se recomienda que sólo se utilicen servidores y clientes compatibles con la versión 2 de SSH siempre que sea posible.

18.3. Secuencia de eventos de una conexión SSH

La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre dos host.

  1. Se lleva a cabo un "apretón de manos" encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto.

  2. La capa de transporte de la conexión entre el cliente y la máquina remota es encriptada mediante un código simétrico.

  3. El cliente se autentica ante el servidor.

  4. El cliente remoto interactúa con la máquina remota a través de la conexión encriptada.

18.3.1. Capa de transporte

El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts durante la autenticación y la subsecuente comunicación. La capa de transporte lleva a cabo esta tarea manejando la encriptación y decodificación de datos y proporcionando protección de integridad de los paquetes de datos mientras son enviados y recibidos. La capa de transporte proporciona compresión de datos, lo que acelera la transmisión de la información.

Al contactar un cliente a un servidor por medio del protocolo SSH se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Durante el intercambio se producen los siguientes pasos:

  • Intercambio de claves

  • Se determina el algoritmo de encriptación de la clave pública

  • Se determina el algoritmo de la encriptación simétrica

  • Se determina el algoritmo autenticación de mensajes

  • Se determina el algoritmo del hash

El servidor se identifica ante el cliente con una llave de host única durante el intercambio de llaves. Obviamente, si este cliente nunca se había comunicado antes con este determinado servidor, la llave del servidor le resultará desconocida al cliente y no lo conectará. OpenSSH evita este problema permitiendo que el cliente acepte la llave del host del servidor después de que el usuario es notificado y verifica la aceptación de la nueva llave del host. Para las conexiones posteriores, la llave del host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza de que el cliente se está comunicando con el servidor deseado. Si en el futuro, la llave del host ya no coincide, el usuario debe eliminar la versión guardada antes de que una conexión pueda ocurrir.

Precaución

Un atacante podría enmascararse como servidor SSH durante el contacto inicial ya que el sistema local no conoce la diferencia entre el servidor en cuestión y el servidor falso configurado por un agresor. Para evitar que esto ocurra, debería verificar la integridad del nuevo servidor SSH contactando con el administrador del servidor antes de conectarse por primera vez o en el evento de que no coincidan las claves.

SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto, los dos sistemas empiezan inmediatamente a calcular claves y algoritmos nuevos para proteger la autenticación y los datos que se enviarán a través de la conexión en el futuro.

Después de que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave (la cantidad exacta depende de la implementación de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un periodo de tiempo limitado.

18.3.2. Autenticación

Cuando la capa de transporte haya construido un túnel seguro para transmitir información entre los dos sistemas, el servidor le dirá al cliente de los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña. El cliente entonces intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados.

Los servidores y clientes SSH se pueden configurar para permitir varios tipos de autenticación, lo cual le concede a cada lado la cantidad óptima de control. El servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad; el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición.

18.3.3. Canales

Luego de una autenticación exitosa sobre la capa de transporte SSH, se abren múltiples canales a través de la técnica llamada multiplexing[8]. Cada uno de estos canales manejan la conexión para diferentes sesiones de terminal y para sesiones de reenvío X11.

Ambos clientes y servidores pueden crear un canal nuevo. Luego se le asigna un número diferente a cada canal en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esta información es almacenada por el servidor y usada para dirigir la comunicación a ese canal. Esto es hecho para que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH primaria.

Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos.

El cliente y el servidor negocian las características de cada canal automáticamente, dependiendo del tipo de servicio que el cliente solicita y la forma en que el usuario está conectado a la red. Esto otorga una gran flexibilidad en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar la infraestructura básica del protocolo.

18.4. Configurar un servidor OpenSSH

Para poner en funcionamiento un servidor OpenSSH, primero debe asegurarse de que su sistema tiene los paquetes RPM instalados. Se requiere el paquete openssh-server que depende a su vez del paquete openssh.

El demonio OpenSSH usa el archivo de configuración /etc/ssh/sshd_config. El archivo de configuración por defecto debería ser suficiente para la mayoría de los propósitos. Si quiere configurar su propio demonio de otra manera que no sea la proporcionada por defecto en el sshd_config, lea la página del manual de sshd para una lista de palabras reservadas que pueden ser definidas en su archivo de configuración.

Si reinstala un sistema, el sistema reinstalado crea un nuevo conjunto de llaves de identificación. Cualquier cliente que se haya conectado al sistema con alguna de las herramientas OpenSSH, verán el siguiente mensaje antes de la reinstalación:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Si desea mantener las claves del host generadas para el sistema, haga una copia de seguridad de los archivos /etc/ssh/ssh_host*key* y restáurelos después de reinstalar. Este proceso retiene la identidad del sistema y cuando los clientes traten de conectarse al sistema después de la instalación, estos no recibirán el mensaje de aviso.

18.4.1. Requiriendo SSH para conexiones remotas

Para que SSH sea realmente eficaz, el uso de protocolos de conexión inseguros, como por ejemplo FTP y Telnet, deberían ser prohibidos. De lo contrario, una contraseña de usuario puede estar protegida usando SSH para una sesión, para luego ser capturada cuando establece una conexión Telnet.

Algunos servicios a deshabilitar incluyen:

  • telnet

  • rsh

  • rlogin

  • vsftpd

Para desactivar métodos de conexión inseguros al sistema, use el programa de línea de comandos chkconfig, el programa basado en ncurses ntsysv, o la Herramienta de configuración de servicios (system-config-services). Todas estas herramientas requieren prioridades de root.

18.5. Archivos de configuración de OpenSSH

OpenSSH tiene dos conjuntos diferentes de archivos de configuración: uno para clientes (ssh, scp y sftp) y otro para el demonio del servidor (sshd).

La información de configuración SSH para todo el sistema está almacenada en el directorio /etc/ssh/:

  • moduli — Contiene grupos Diffie-Hellman usados para el intercambio de la clave Diffie-Hellman que es imprescindible para la construcción de una capa de transporte seguro. Cuando se intercambian las claves al inicio de una sesión SSH, se crea un valor secreto y compartido que no puede ser determinado por ninguna de las partes individualmente. Este valor se usa para proporcionar la autenticación del host.

  • ssh_config — El archivo de configuración del sistema cliente SSH por defecto. Este archivo se sobreescribe si hay alguno ya presente en el directorio principal del usuario (~/.ssh/config).

  • sshd_config — El archivo de configuración para el demonio sshd

  • ssh_host_dsa_key — La clave privada DSA usada por el demonio sshd.

  • ssh_host_dsa_key.pub — La clave pública DSA usada por el demonio sshd.

  • ssh_host_key — La clave privada RSA usada por el demonio sshd para la versión 1 del protocolo SSH.

  • ssh_host_key.pub — La clave pública RSA usada por el demonio sshd para la versión 1 del protocolo SSH.

  • ssh_host_rsa_key — La clave privada RSA usada por el demonio sshd para la versión 2 del protocolo SSH.

  • ssh_host_rsa_key.pub — La clave pública RSA usada por el demonio sshd para la versión 2 del protocolo SSH.

La información para la configuración SSH específica para el usuario está almacenada en el directorio ~/.ssh/ del usuario:

  • authorized_keys — Este archivo contiene una lista de claves públicas autorizadas. Cuando un cliente se conecta al servidor, el servidor autentica al cliente chequeando su clave pública firmada almacenada dentro de este archivo.

  • id_dsa — Contiene la clave privada DSA del usuario.

  • id_dsa.pub — la clave pública DSA del usuario.

  • id_rsa — La clave RSA privada usada por ssh para la versión 2 del protocolo SSH.

  • id_rsa.pub — La clave pública RSA usada por ssh para la versión 2 del protocolo SSH.

  • identity — La clave privada RSA usada por ssh para la versión 1 del protocolo SSH.

  • identity.pub — La clave pública RSA usada por ssh para la versión 1 del protocolo SSH.

  • known_hosts — Este archivo contiene las claves de host DSA de los servidores SSH a los cuales el usuario ha accedido. Este archivo es muy importante para asegurar que el cliente SSH está conectado al servidor SSH correcto.

    Importante

    Si se ha cambiado una llave de host del servidor SSH, el cliente notificará al usuario que la conexión no puede proceder hasta que la llave del host del servidor sea borrada del archivo known_hosts usando un editor de texto. Antes de hacer esto, sin embargo, contacte al administrador del sistema del servidor SSH para verificar que no se ha comprometido al servidor.

Consulte las páginas man para ssh_config y sshd_config para obtener información acerca de las directivas disponibles en los archivos de configuración SSH.

18.6. Configuración de un cliente OpenSSH

Para conectarse a un servidor OpenSSH desde una máquina cliente, debe tener los paquetes openssh-clients y openssh instalados en la máquina cliente.

18.6.1. Uso del comando ssh

El comando ssh es un reemplazo seguro para los comandos rlogin, rsh y telnet. Le permite inicar sesiones y ejecutar comandos en máquinas remotas.

Inicie una sesión en una máquina remota con ssh que es muy parecido a utilizar el comando telnet. Para iniciar una sesión remota a una máquina llamada penguin.example.net, escriba el comando siguiente en el intérprete de comandos de la shell:

ssh penguin.example.net

La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente:

The authenticity of host 'penguin.example.net' can't be established.
DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?

Escriba yes para continuar. Esto añadirá el servidor en su lista de host conocidos (~/.ssh/known_hosts/) como se muestra en el siguiente mensaje:

Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts.

Luego, verá un intérprete de comandos preguntándole por su contraseña. Después de ingresar su contraseña, se encontrará en el intérprete de comandos de la máquina remota. Si no especifica un nombre de usuario, el nombre de usuario con el que se ha validado en la máquina local se utilizará en la máquina remota. Si quiere especificar un nombre de usuario use el comando siguiente:

ssh nombre-usuario@penguin.example.net

También puede usar la sintaxis ssh -l nombre-usuario penguin.example.net.

El comando ssh se puede utilizar para ejecutar un comando en una máquina remota sin acceder al intérprete de comandos. La sintaxis es ssh nombre-hostcommand. Por ejemplo, si quiere ejecutar el comando ls /usr/share/doc en la máquina remota penguin.example.net, escriba el comando siguiente en la línea de comandos de la shell:

ssh penguin.example.net ls /usr/share/doc

Una vez que introduzca la contraseña correcta, verá el contenido del directorio /usr/share/doc, y regresará a la shell de su equipo local.

18.6.2. Usando el comando scp

El comando scp puede ser usado para transferir archivos entre máquinas sobre una conexión encriptada y segura. Es parecido al comando rcp.

La sintaxis general para transferir el archivo local a un sistema remoto es como sigue a continuación:

scp <archivo-local>nombre-usuario@tohostname:<archivo-remoto>

<archivo-local> especifica la fuente incluyendo la ruta al archivo, tal como /var/log/maillog. <archivo-remoto> especifica el destino, el cual puede ser un nuevo archivo tal como /tmp/hostname-maillog. Para el sistema remoto, si no tiene un barra oblícua (/) en frente, la ruta será relativa al directorio principal de nombre-usuario, usualmente /home/username/.

Para transferir un archivo local shadowman al directorio principal de su cuenta en penguin.example.net, escriba en la línea de comandos (reemplace nombre-usuario con su nombre de usuario):

scp shadowman nombre_usuario@penguin.example.net:shadowman

Esto transferirá el archivo local shadowman a /home/nombre_usuario/shadowman en penguin.example.net. También puede dejar por fuera la parte final de shadowman en el comando scp.

La sintaxis general para transferir un archivo remoto al sistema local es como sigue:

scp nombre_usuario@tohostname:<archivoremoto><nuevoarchivolocal>

<archivoremoto> especifica la fuente incluyendo la ruta y <nuevoarchivolocal> especifica el destino con su ruta.

Se pueden especificar múltiples archivos como las fuentes. Por ejemplo, para transferir el contenido del directorio downloads/ a un directorio existente llamado uploads/ en la máquina remota penguin.example.net, teclee lo siguiente desde el intérprete de comandos:

scp downloads/* nombre_usuario@penguin.example.net:uploads/

18.6.3. Uso del comando sftp

La utilidad sftp puede ser usada para abrir una sesión segura interactiva de FTP. Es similar a ftp excepto que ésta utiliza una conexión encriptada segura. La sintaxis general es sftp nombre-usuario@hostname.com. Una vez autentificado, podrá utilizar un conjunto de comandos similar al conjunto utilizado por el comando FTP. Consulte las páginas del manual de sftp para obtener un listado de todos estos comandos. Para consultar el manual ejecute el comando man sftp en el intérprete de comandos. La utilidad sftp sólo está disponible en las versiones 2.5.0p1 de OpenSSH y superiores.

18.7. Más que un Shell seguro

Una interfaz de línea de comandos segura es sólo el inicio de las muchas maneras de usar SSH. Dada una cantidad apropiada de ancho de banda, las sesiones X11 se pueden dirigir por un canal SSH. O usando reenvío TCP/IP, se pueden asignar conexiones de puerto entre sistemas que previamente eran inseguras a canales SSH específicos.

18.7.1. Reenvío por X11

Abrir una sesión X11 a través de una conexión SSH es tan fácil como conectarse a un servidor SSH utilizando la opción -Y y ejecutar un programa X en una máquina local.

ssh -Y <usuario>@example.com

Cuando un programa X se ejecuta desde un intérprete de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro; los datos del programa X se envían a través de ese canal a la máquina cliente de forma transparente.

El reenvío por X11 puede ser muy útil. Por ejemplo, se puede usar el reenvío por X11 para crear una sesión segura e interactiva de la Herramienta de configuración de la impresora. Para hacer esto, conéctese al servidor usando ssh y escriba:

system-config-printer &

Después de proporcionar la contraseña de root para el servidor, la Herramienta de configuración de la impresora aparecerá y le permitirá al usuario remoto configurar de una forma segura la impresora en el sistema remoto.

18.7.2. Reenvío del puerto

Con SSH puede asegurar los protocolos TCP/IP a través del reenvío de puertos. Cuando use esta técnica, el servidor SSH se convierte en un conducto encriptado para el cliente SSH.

El reenvío de puertos funciona mediante el mapeado de un puerto local en el cliente a un puerto remoto en el servidor. SSH le permite mapear cualquier puerto desde el servidor a cualquier puerto en el cliente; los números de puerto no necesitan coincidir para que esto funcione.

Para crear un canal de reenvío de puerto TCP/IP que escucha conexiones del localhost, utilice el siguiente comando:

ssh -L local-port:remote-hostname:remote-portusername@hostname

Nota

La configuración del reenvío de puertos para escuchar puertos bajo 1024 requiere acceso de root.

Para verificar correo-e en un servidor llamado mail.example.com usando POP3 a través de una conexión encriptada, use el comando siguiente:

ssh -L 1100:mail.example.com:110 mail.example.com

Una vez que el canal de reenvío de puerto está entre la máquina cliente y el servidor de correo, puede direccionar su cliente de correo POP3 para usar el puerto 1100 en su host local para comprobar el nuevo correo. Cualquier petición enviada al puerto 1100 en el sistema cliente será dirigida seguramente al servidor mail.example.com.

Si mail.example.com no está ejecutando un servidor SSH, pero otra máquina en la misma red si, SSH todavía puede ser usado para asegurar parte de la conexión. Sin embargo, un comando ligeramente diferente es necesario:

ssh -L 1100:mail.example.com:110 other.example.com

En este ejemplo, se está reenviando las peticiones POP3 desde el puerto 1100 en la máquina cliente a través de una conexión SSH en el puerto 22 al servidor SSH, other.example.com. Luego, other.example.com se conecta al puerto 110 en mail.example.com para verificar correo nuevo. Observe que usando esta técnica, sólo la conexión entre el sistema cliente y el servidor SSH other.example.com es segura.

El reenvío del puerto se puede usar para obtener información segura a través de los cortafuegos de red. Si el cortafuegos está configurado para permitir el tráfico SSH a través del puerto estándar (22) pero bloquea el acceso a través de otros puertos, es posible todavía una conexión entre dos hosts usando los puertos bloqueados al redireccionar la comunicación sobre una conexión SSH establecida.

Nota

Si se utiliza el reenvío de puerto para reenviar conexiones de este modo, cualquier usuario en el sistema cliente puede conectarse a ese servicio. Si el cliente está en riesgo o está comprometido, un agresor puede también acceder a los servicios reenviados.

Los administradores de sistemas pueden desactivar la funcionalidad de reenvío de puerto en el servidor si especifican No en la línea AllowTcpForwarding en /etc/ssh/sshd_config. El servicio sshd debe ser reiniciado después de esta modificación.

18.7.3. Generar pares de claves

Si no quiere introducir su contraseña cada vez que se conecte a una máquina remota con ssh, scp o sftp, puede generar un par de claves de autorización.

Las claves deben ser generadas para cada usuario. Para generar las claves de un usuario debe seguir los siguientes pasos como el usuario que quiere conectarse a máquinas remotas. Si completa los siguentes pasos como root, sólo root será capaz de utilizar estas claves.

Arrancar con la versión 3.0 de OpenSSH, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2, y /etc/ssh_known_hosts2 se ha quedado obsoletas. Los protocolos 1 y 2 de SSH comparten los archivos ~/.ssh/authorized_keys, ~/.ssh/known_hosts y /etc/ssh/ssh_known_hosts.

Red Hat Enterprise Linux 5.2 uses SSH Protocol 2 and RSA keys by default.

Sugerencia

Si reinstala y quiere guardar los pares de llaves generados, haga una copia de respaldo del directorio .ssh en su directorio principal (home). Después de la reinstalación, copie este directorio de vuelta a su directorio principal. Este proceso puede realizarse para todos los usuarios de su sistema, incluyendo root.

18.7.3.1. Generar un par de claves RSA para la versión 2

Siga los siguientes pasos para generar un par de claves RSA para la versión 2 del protocolo SSH. Esto es lo predeterminado para iniciar con OpenSSH 2.9.

  1. Para generar un par de claves RSA para trabajar con la versión 2 del protocolo, teclee el siguiente comando desde el intérprete de comandos de la shell:

    ssh-keygen -t rsa
    

    Acepte la localización por defecto del archivo ~/.ssh/id_rsa. Introduzca una contraseña diferente de la contraseña de su cuenta y confírmela introduciéndola nuevamente.

    La clave pública se escribe a ~/.ssh/id_rsa.pub. La clave privada está escrita a ~/.ssh/id_rsa. No distribuya la clave privada a nadie.

  2. Cambie los permisos de su directorio .ssh usando el comando siguiente:

    chmod 755 ~/.ssh
    
  3. Copie los contenidos de ~/.ssh/id_rsa.pub al archivo ~/.ssh/authorized_keys en la máquina en la que se quiere conectar. Si el archivo ~/.ssh/authorized_keys existe, puede añadir los contenidos del archivo ~/.ssh/id_rsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina.

  4. Cambie los permisos del archivo authorized_keys usando el comando siguiente:

    chmod 644 ~/.ssh/authorized_keys
    
  5. Si está ejecutando GNOME o está ejecutando un escritorio gráfico con las bibliotecas GTK2+, vaya a la Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”. Si no está ejecutando el sistema de ventanas X, vaya a la Sección 18.7.3.5, “Configuración de ssh-agent.

18.7.3.2. Generación de un par de claves DSA para la versión 2

Use los siguientes pasos para generar un par de claves DSA para la versión 2 del protocolo SSH.

  1. Para generar un par de claves DSA para trabajar con la versión 2 del protocolo, escriba el siguiente comando en el intérprete de comandos de la shell:

    ssh-keygen -t dsa
    

    Acepte la localización por defecto del archivo ~/.ssh/id_dsa. Introduzca una frase secreta diferente a la contraseña de su cuenta y confirme ésta introduciéndola de nuevo.

    Sugerencia

    Una frase secreta es una cadena de caracteres o palabras utilizadas para autentificar a un usuario. Las frases secretas se diferencian de las contraseñas en que se pueden utilizar espacios o tabuladores en la primera. Las frases secretas son generalmente más largas que las contraseñas porque ellas son habitualmente frases. Algunas veces estos dos términos se usan indistintamente.

    La clave pública es escrita a ~/.ssh/id_dsa.pub. La clave privada es escrita a ~/.ssh/id_dsa. Es de suma importancia que no de la clave privada a nadie.

  2. Cambie los permisos de su directorio .ssh usando el comando siguiente:

    chmod 755 ~/.ssh
    
  3. Copie los contenidos de ~/.ssh/id_dsa.pub a ~/.ssh/authorized_keys en la máquina a la cual quiere conectarse. Si el archivo ~/.ssh/authorized_keys existe, añada los contenidos del archivo ~/.ssh/id_dsa.pub al archivo ~/.ssh/authorized_keys en la otra máquina.

  4. Cambie los permisos del archivo authorized_keys usando el comando siguiente:

    chmod 644 ~/.ssh/authorized_keys
    
  5. Si está ejecutando GNOME o un entorno gráfico con las bibliotecas GTK2+ instaladas, vaya a la Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”. Si no está ejecutando el sistema de ventanas X, vaya a la Sección 18.7.3.5, “Configuración de ssh-agent.

18.7.3.3. Generación de un par de claves RSA para la versión 1.3 y 1.5

Siga los siguientes pasos para generar un par de claves RSA la cual es usada por la versión 1 del protocolo SSH. Si sólo se está conectando entre sistemas que usan DSA, no necesita una par de claves de versión RSA 1.3 o RSA versión 1.5.

  1. Para generar un par de claves RSA (para la versión de protocolos 1.3 y 1.5), escriba el comando siguiente en la línea de comandos de la shell:

    ssh-keygen -t rsa1
    

    Acepte la localización por defecto del archivo (~/.ssh/identity). Introduzca una contraseña diferente a la contraseña de su cuenta y confirme ésta introduciéndola de nuevo.

    La clave pública está escrita en ~/.ssh/identity.pub. La clave privada está escrita a ~/.ssh/identity. No entregue su clave a nadie.

  2. Cambie los permisos de su directorio .ssh y su clave con los comandos chmod 755 ~/.ssh y chmod 644 ~/.ssh/identity.pub.

  3. Copie los contenidos de ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en la máquina a la cual se desea conectar. Si el archivo ~/.ssh/authorized_keys no existe, puede copiar el archivo ~/.ssh/identity.pub al archivo ~/.ssh/authorized_keys en el equipo remoto.

  4. Si está ejecutando GNOME, vaya a la Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”. Si no está corriendo GNOME, salte a la Sección 18.7.3.5, “Configuración de ssh-agent.

18.7.3.4. Configurando ssh-agent con una interfaz gráfica

La utilidad ssh-agent puede ser usada para guardar su contraseña, de manera que no tendrá que ingresarla cada vez que inicie una conexión ssh o scp. Si está usando GNOME, la utilidad openssh-askpass puede ser usada para pedirle la contraseña cuando inicie una conexión con GNOME y guardarla hasta que salga de GNOME. No tendrá que ingresar su contraseña para ninguna conexión ssh o scp realizada durante una sesión GNOME. Si no está usando GNOME consulte la Sección 18.7.3.5, “Configuración de ssh-agent.

Para guardar su contraseña durante una sesión GNOME, siga los pasos siguientes:

  1. Verifique que el paquete openssh-askpass-gnome esté instalado usando el comando rpm -q openssh-askpass. Si no está instalado, hágalo desde su conjunto de CDs de Red Hat Enterprise Linux, desde un sitio espejo FTP de Red Hat o usando Red Hat Network.

  2. Seleccione Botón del menú principal (en el Panel) => Extras => Preferencias => Sesión, y haga clic en la pestaña de Programas de inicio. Pulse en Añadir e introduzca /usr/bin/ssh-add en el cuadro de texto Comando de inicio. Establezca un número de prioridad más alto que cualquiera de los comandos existentes para asegurarse de que se ejecute de último. Un buen número de prioridad para ssh-add es 70 o superior. Mientras más alto el número, más baja la prioridad. Si tiene otros programas listados, este debería tener la prioridad más baja. Haga clic en Cerrar para salir del programa.

  3. Cierre la sesión y luego vuelva a GNOME; en otras palabras, reinicie X. Después de arrancar GNOME, aparecerá una ventana de diálogo pidiéndole su frase secreta. Introduzca ésta. Si tiene pares de claves DSA y RSA, ambas configuradas, lo estará ejecutando para ambas. A partir de este momento, no debería introducir ninguna contraseña para ssh, scp o sftp.

18.7.3.5. Configuración de ssh-agent

ssh-agent se puede utilizar para almacenar su contraseña para que así no tenga que ingresarlas cada vez que realice una conexión ssh o scp. Si no está ejecutando el sistema de ventanas X, siga los pasos siguientes desde el intérprete de comandos de la shell. Si está ejecutando GNOME pero no quiere configurarlo para que le solicite la contraseña cuando se conecte (vea la Sección 18.7.3.4, “Configurando ssh-agent con una interfaz gráfica”), este procedimiento trabajará en una ventana de terminal como por ejemplo XTerm. Si está ejecutando X pero no GNOME, este procedimiento funcionará en una ventana de terminal. Sin embargo, su contraseña sólo será recordada en ese terminal; no es una configuración global.

  1. Desde el intérprete de comandos de la shell, teclee el siguiente comando:

    exec /usr/bin/ssh-agent $SHELL
    
  2. Luego escriba el comando:

    ssh-add
    

    e ingrese su contraseña. Si tiene más de un par de claves configuradas, se le pedirá información para ambas.

  3. Su contraseña será olvidada cuando termine la sesión. Debe ejecutar estos dos comandos cada vez que abra una consola virtual o abra una ventana de terminal.

18.8. Recursos adicionales

Los proyectos OpenSSH y OpenSSL están en constante desarrollo. La información más actualizada está disponible desde sus sitios web. Las páginas de manuales para las herramientas OpenSSH y OpenSSL también son una buena fuente de información detallada.

18.8.1. Documentación instalada

  • Páginas man de ssh, scp, sftp, sshd, y ssh-keygen — estas páginas incluyen información sobre cómo usar estos comandos así como también los parámetros que se puede usar con ellos.

18.8.2. Sitios web útiles

  • http://www.openssh.com — La página de FAQ de OpenSSH, informe de errores (bugs), listas de correo, objetivos del proyecto y una explicación más técnica de las características de seguridad.

  • http://www.openssl.org — La página FAQ de OpenSSL, con listas de correo y una descripción del objetivo del proyecto.

  • http://www.freessh.org — Software de cliente SSH para otras plataformas.



[5] X11 se refiere al sistema de visión por ventanas X11R7, tradicionalmente llamado Sistema de ventanas X o simplemente X. Red Hat Enterprise Linux incluye X11R7, un sistema de ventanas X de código abierto.

[6] El envenenamiento del DNS ocurre cuando un intruso entra en el servidor de DNS, apuntando sistemas hacia hosts intencionalmente duplicados.

[7] IP spoofing ocurre cuando un intruso manda paquetes de red que parecen provenir de hosts de confianza de la red.

[8] Una conexión multiplexada consiste de muchas señales que se envian sobre un medio común, compartido. Con SSH, canales diferentes son enviados sobre una conexión común segura.

Capítulo 19. Sistema de archivos de red (NFS)

Un Sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos sobre la red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto permite a los administradores de sistemas consolidar los recursos en servidores centralizados en la red.

Este capítulo aborda los conceptos fundamentales de NFS e información relacionada.

19.1. Funcionamiento

Hay tres versiones de NFS actualmente en uso. La versión 2 de NFS (NFSv2), es la más antigua y está ampliamente soportada por muchos sistemas operativos. La versión 3 de NFS (NFSv3) tiene más características, incluyendo el manejo de archivos de 64 bits, escrituras Safe Async y un mejor manejo de errores. NFS versión 4 (NFSv4) trabaja con cortafuegos y en Internet, soporta ACLs y utiliza operaciones con descripción del estado. Red Hat Enterprise Linux soporta clientes tanto NFSv2, NFSv3 como NFSv4 y cuando monta un sistema de archivos a través de NFS, Red Hat Enterprise Linux usa NFSv3 por defecto, si el servidor lo soporta.

Todas las versiones de NFS pueden utilizar el Protocolo de control de transmisiones (TCP) ejecutándose sobre una red IP. En el caso de NFSv4, éste lo requiere. NFSv2 y NFSv3 pueden utilizar el Protocolo de datagrama de usuarios (UDP) sobre una red IP para proporcionar conexiones de red sin supervisión (stateless) entre el cliente y el servidor.

Cuando se utiliza NFSv2 o NFSv3 con UDP, bajo condiciones normales la conexión UDP sin estado minimiza más el tráfico de la red que TCP, lo cual se traduce en un mejor desempeño en redes limpias y sin congestión. El servidor NFS envía al cliente un manejador del archivo después de que se autoriza al cliente a acceder el volumen compartido. Este manejador de archivo es un objeto opaco almacenado en el lado del servidor y se pasa junto con las peticiones RPC del cliente. El servidor NFS puede ser reiniciado sin afectar a los clientes y las cookies permanecen intactas. Sin embargo, debido a que UDP no tiene estado, si el servidor se cae de forma inesperada, los clientes UDP continúan saturando la red con peticiones para el servidor. Por esta razón, TCP es el protocolo preferido cuando se conecte a un servidor NFS.

NFSv4 no interactúa con el portmapper rpc.mountd, rpc.lockd y rpc.statd debido a que el protocolo v4 incorpora soporte al protocolo. NFSv4 escucha en el muy conocido puerto TCP (2049), el cual elimina la necesidad de una interacción portmapper. Los protocolos de montaje y de bloqueo han sido incorporados en el protocolo V4, el cual elimina la necesidad de interactuar con rpc.mountd and rpc.lockd.

Nota

TCP es el protocolo predeterminado para NFS en Red Hat Enterprise Linux. UDP puede ser utilizado por compatibilidad si es necesario; sin embargo, su uso no se recomienda.

Todo demonio RPC/NFS tiene una opción de línea de comando '-p' que puede configurar el puerto haciendo que la configuración del cortafuegos sea mucho más fácil.

Después de que se le permite acceso al cliente gracias a un TCP wrapper, el servidor NFS recurre a su archivo de configuración, /etc/exports, para determinar si el cliente tiene suficientes privilegios para acceder a los sistemas de archivos exportados. Una vez se otorga el acceso, todas las operaciones de archivos y de directorios están disponibles para el usuario.

Importante

Para que NFS funcione con una instalación de Red Hat Enterprise Linux con un cortafuegos habilitado, se debe configurar IPTables con el puerto predeterminado TCP 2049. Sin una configuración IPTables, NFS no funcionará correctamente.

El script de inicialización NFS y el proceso rpc.nfsd ahora permiten la vinculación a cualquier puerto especificado durante el inicio del sistema. Sin embargo, esto puede ser susceptible a errores si el puerto no está disponible o si entra en conflicto con otro demonio.

19.1.1. Servicios requeridos

Red Hat Enterprise Linux utiliza una combinación de soporte a nivel del kernel y procesos demonio para proporcionar los archivos compartidos con NFS. Todas las versiones de NFS confía en las Llamadas de procedimientos remotos ((RPC)) para enrutar peticiones entre clientes y servidores. Los servicios RPC bajo Linux son controlados por el servicio portmap. Para compartir o montar sistemas de archivos NFS, los siguientes servicios funcionan juntos dependiendo de cuál versión de NFS se implemente:

  • nfs — (/sbin/service nfs start) inicia el servidor NFS y los procesos RPC apropiados para servir peticiones para los sistemas de archivos compartidos NFS.

  • nfslock — (/sbin/service nfslock start) es un servicio obligatorio que inicia los procesos RPC adecuados para permitir que clientes NFS bloqueen archivos en el servidor.

  • portmap — acepta reservas de puerto de servicio RPC locales. Estos puertos luego se hacen disponibles (o se publican) para que los servicios RPC remotos correspondientes los accedan. portmap responde a las peticiones para servicios RPC y configura las conexiones al servicio RPC solicitado. No se utiliza con NFSv4.

Los siguientes procesos RPC facilitan los servicios NFS:

  • rpc.mountd — Este proceso recibe las peticiones de montaje de los NFS y verifica que el sistema de archivos solicitado esté actualmente exportado. Este proceso es iniciado automáticamente por el servicio nfs y no requiere de la configuración del usuario. No se utiliza con NFSv4.

  • rpc.nfsd — Permite definir versiones y protocolos explícitas de NFS que son publicados por el servidor. Trabaja con el kernel Linux para satisfacer las demandas dinámicas de clientes NFS tal como proporcionar hilos del servidor cada vez que se conecta un cliente NFS. Este proceso corresponde al servicio nfs.

  • rpc.lockd — permite a los clientes NFS bloquear archivos en el servidor. Si no se inicia rpc.lockd fallará el bloqueo de archivos. rpc.lockd implementa el protocolo Network Lock Manager (NLM). Este proceso corresponde al servicio nfslock, no se utiliza con NFSv4.

  • rpc.statd — Este proceso implementa el protocolo RPC Network Status Monitor (NSM) el cual notifica a los clientes NFS cuando un servidor NFS es reiniciado luego de haber sido apagado abruptamente. Este proceso es iniciado automáticamente por el servicio nfslock y no requiere configuración por parte del usuario. No se utiliza con NFSv4.

  • rpc.rquotad — Este proceso proporciona información de cuota del usuario para los usuarios remotos. Este proceso se inicia automáticamente por el servicio nfs y no requiere configuración por parte del usuario.

  • rpc.idmapd — Este proceso proporciona al cliente y servidor NFSv4 llamadas ascendentes (upcalls) que hacen corresponder los nombres NFSv4 (los cuales son cadenas en la forma usuario@dominio) y los UIDs y GIDs locales. Para que idmapd funcione con NFSv4, el /etc/idmapd.conf debe estar configurado. Se requiere este servicio para su uso con NFSv4.

19.2. Configuración de clientes NFS

Los recursos compartidos NFS son montados en el lado del cliente usando el comando mount. El formato del comando es como sigue:

mount -t <tipo-nfs> -o <opciones><host>:</exportación/remota></directorio/local>

Reemplace <tipo-nfs> con nfs para servidores NFSv2 o NFSv3, o nfs4 para servidores NFSv4. Reemplace <opciones> con una lista de opciones separadas por comas para el sistema NFS (para más detalles, consulte la Sección 19.4, “Opciones de montaje NFS comunes”). Reemplace <host> con el host remoto, </exportación/remota> con el directorio remoto que está siendo montado y sustituya </directorio/local> con el directorio local donde el sistema de archivos remoto se montará.

Consulte la página man de mount para obtener más detalles.

Si está accediendo a un recurso compartido NFS emitiendo manualmente el comando mount, el sistema de archivos debe ser remontado manualmente después de reiniciar el sistema. Red Hat Enterprise Linux ofrece dos métodos para el montaje automático de sistemas de archivos al momento del arranque: el archivo /etc/fstab o el uso del servicio autofs.

19.2.1. Montaje del sistemas de archivos NFS con /etc/fstab

Un método alternativo para montar datos compartidos mediante NFS es añadir una línea en el archivo /etc/fstab. La línea debe incluir el nombre del servidor NFS, el directorio que el servidor está exportando y el directorio de nuestra máquina local donde queremos montar el sistema de archivos. Deberá ser administrador (root) para poder modificar el archivo /etc/fstab.

La sistaxis general de esta línea del archivo /etc/fstab es la siguiente:

server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr

Antes de que se pueda ejecutar este comando, debe existir el punto de montaje /pub en la máquina del cliente. Después de añadir esta línea a /etc/fstab en el sistema del cliente, escriba el comando mount /pub en el intérprete de comandos y el punto de montaje /pub es montado desde el servidor.

El archivo /etc/fstab lo referencia el servicio netfs al momento del arranque, por lo que las líneas haciendo referencia a las comparticiones NFS tienen el mismo efecto que escribir manualmente el comando mount durante el arranque.

Una muestra de línea de /etc/fstab para montar un NFS exportado será parecida a:

<server>:</remote/export></local/directory><nfs-type><options> 0 0

Reemplace <server> con el nombre de la máquina, dirección IP o nombre de dominio totalmente cualificado del servidor que exporta el sistema de archivos.

Reemplace </remote/export> con la ruta al directorio exportado.

Sustituya </local/directory> con el sistema de archivos local en el cual se montará el directorio exportado. Este punto de montaje debe existir antes de que /etc/fstab sea leído o el montaje fallará.

Reemplace <nfs-type> con nfs para servidores NFSv2 o NFSv3, o con nfs4 para servidores NFSv4.

Reemplace <options> con una lista de opciones separada por comas para el sistema NFS (refiérase a la Sección 19.4, “Opciones de montaje NFS comunes” para obtener más detalles). Consulte la página del manual fstab para obtener información adicional.

19.3. autofs

Una desventaja de usar /etc/fstab es que sin tener en cuenta con que frecuencia se use este sistema de archivos montado, el sistema debe dedicar recursos para mantener este montaje en su sitio. Esto no es un problema con uno o dos montajes, pero cuando su sistema está manteniendo demasiados montajes en muchos sistemas al mismo tiempo, el rendimiento general puede decaer. Una alternativa para /etc/fstab es usar la utilidad de automontaje basada en el kernel. Un automontaje consiste de dos componentes: uno es un módulo de kernel que implementa un sistema de archivos, mientras que el otro es un demonio de espacio de usuario que realiza todas las otras funciones. Esta utilidad puede montar y desmontar sistemas dearchivos NFS automáticamente (montaje a petición) por lo cual ahorra recursos del sistema. Esta utilidad se puede utilizar para montar otros sistemas de archivos incluyendo AFS, SMBFS, CIFS y sistemas de archivos locales.

autofs usa /etc/auto.master (mapa maestro) como su archivo de configuración primario por defecto. Esto se puede cambiar para que utilice otro recurso de red soportado y otro nombre utilizando la configuración autofs (en /etc/sysconfig/autofs) en conjunto con el mecanismo Cambio de Nombre del Servicio. Se ejecutó una instancia del demonio de la versión 4 para cada punto de montaje configurado en el mapa maestro y que de esta manera pueda ser ejecutado manualmente desde la línea de comandos para cualquier punto de montaje dado. Esto no es posible con la versión 5 ya que utiliza u sólo demonio para administrar todos los puntos de montaje configurados así que todos los automontajes tienen que ser configurados en el mapa maestro. El punto de montaje, nombre del host, el directorio exportado y las opciones pueden ser especificados en un grupo de archivos (u otros recursos de red soportados) en vez de configuraralos manualmente para cada host. Asegúrese de que tiene instalado el paquete autofs si desea utilizar este servicio.

19.3.1. Nuevas características de la versión 5 de autofs

Soporte de mapa directo

Los mapeos directops de autofs proporcionan un mecanismo para montar sistemas de archivos automáticamente en puntos arbitrarios en la jerarquía del sistema de archivos. Un mapeo directo es simbolizado por un punto de montaje de "/-" en el mapa maestro. Las entradas en el mapeo directo contienen un nombre de ruta absoluto como llave (en vez de los nombres de ruta relativos utilizados en mapeos indirectos).

Montaje perezozo y soporte para desmonte

Las entradas de mapeo multi-montaje describen una jerarquía de puntos de montaje bajo una sola llave. Un buen ejemplo de esto es el mapa "-hosts", el cual se utiliza comúnmente para automontar todo lo exportado desde un host bajo "/net/<host>" como una entrada de mapa multi-montaje. Cuando utiliza el mapa "-hosts", un 'ls' de "/net/<host>" montará montajes desencadenados de autofs para cada exportación desde <host> y los montará y los terminará al ser accedidos. Esto puede reducir en gran parte el número de montajes activos que se necesitan cuando se accede a un servidor con un gran número de exportaciones.

Soporte LDAP mejorado

En el Protocolo Ligero de Acceso a Directorios o LDAP el soporte en la versión 5 de autofs se ha mejorado de varias maneras con respecto a la versión 4 de autofs. El archivo de configuración de autofs (/etc/sysconfig/autofs) proporciona un mecanismo para especificar el esquema de autofs que un sitio implementa por lo cual elimina la necesidad de determinar esto por medio de ensayo y error en la aplicación misma. Además ahora se soportan los enlaces auténticados al servidor LDAP, utilizando la mayoría de mecanismos soportados por las implementaciones del servidor LDAP comúnes. Se ha añadido un nuevo archivo de configuración para este soporte: /etc/autofs_ldap_auth.conf. El archivo de configuración predeterminado es auto-documentado y utiliza un formato XML.

Uso apropiado de la configuración del Conmutador del Servicio de Nombres (nsswitch)

El archivo de configuración del Conmutador del Servicio de Nombres existe para proprocionar una manera de determinar de donde viene los datos de configuración especificos. La razón para esta configuración es el permitir al administrador la flexibilidad de utilizar la base de datos final de su preferencia y al mismo tiempo mantener una interfaz de software uniforme para acceder a los datos. Aunque la versión 4 de automontaje se está volviendo cada vez mejor en el manejo de la configuración del conmutador de servicios de nombre aún no se encuentra completa. Por otro lado, la versión 5 de autofs es una implementación completa. Vea la página del manual nsswitch.conf para obtener mayor información sobre la sintaxis de este archivo. Observe que no todas las bases de datos nss son recursos de mapeo válidos y el analizador rechazará los inválidos. Los recusos válidos son archivos yp, nis, nisplus, ldap y hesiod.

Múltiples entradas de mapeo maestro por punto de montaje autofs

Una cosa que se utiliza con bastante frecuencia pero que aún no se menciona es el manejo de múltiples entradas de mapeo maestro para el punto de montaje directo"/-". Se fusionan las llaves de mapeo para cada entrada y se comportan como un solo mapeo.

A continuación se ve un ejemplo en los mapeos de prueba de concatenación para los montajes directos:

/- /tmp/auto_dcthon
/- /tmp/auto_test3_direct
/- /tmp/auto_test4_direct

19.3.2. Configuración de autofs

El archivo de configuración primario para el automontaje es /etc/auto.master también se conoce como el mapeo maestro, el cual se puede cambiar como se describió en la introducción anterior. El mapeo maestro enumera los punos de montaje controlados por autofs en el sistema y sus archivos de configuración correspondientes o las fuentes de red conocidas como mapeos de automontaje. El formato del mapeo maestro es el siguiente:

<punto-de-montaje> <nombre-mapa> <opciones>

donde:

  • punto-de-montaje es el punto de montaje de autofs. Por ejemplo /home.

  • map-name es el nombre de una fuente de mapeo el cual contiene una lista de puntos de montaje y la ubicación del sistema de archivos desde donde se deben montar esos puntos de montaje. La sintaxis para una entrada de mapeo se describe a continuación.

  • Si options está presente entonces aplicará a todas las entradas en mapeo dado dado que ellos mismos no tengan las opciones epecificadas. Este comportamiento es diferente de la versión 4 de autofs en donde las opciones eran acumulativas. Esto se ha cambiado para satisfacer nuestra meta principal de contar con una compatilidad de entornos mixtos.

El siguiente es un archivo de ejemplo de /etc/auto.master:

 $ cat /etc/auto.master /home /etc/auto.misc

El formato general de los mapeos es similar al mapeo maestro; sin embargo, las "opciones" aparacen entre el punto de montaje y la ubicación y no al final de la entrada como en el mapeo maestro:

 <punto-de-montaje> [<opciones>] <ubicación>

donde:

  • <mount-point> es el punto de montaje de autofs. Esto puede ser el nombre de un solo directorio para un montaje indirecto o la ruta completa del punto de montaje para montajes directos. Cada llave de entrada de mapeo directo e indirecto (<mount-point> arriba) puede ser seguido por una lista de directorios conpensados separados por espacios (nombres de subdirectorios cada uno comenzando con "/") haciéndolos lo que se conoce como una entrada multi-montaje.

  • si se proporcionan <options> estos son las opciones de montaje para las entradas de mapeo que no especifican sus propias opciones.

  • <location> es la ubicación del sistema de archivos tal como la ruta del sistema de archivos locales (precedida por el símbolo de escape de formato de mapeo Sun ":" para nombres de mapeos que comienzan con "/"), un sistema de archivos NFS u otra ubicación válida para el sistema de archivos.

El siguiente es un archivo de mapa de ejemplo:

 $ cat /etc/auto.misc payroll -fstype=nfs personnel:/dev/hda3 sales -fstype=ext3 :/dev/hda4

La primera columna de un archivo de mapeo indica el punto de montaje de autofs (sales y payroll del servidor llamado personnel). La segunda columna indica las opciones para el montaje autofs mientras que la tercera columna indica la fuente del montaje. Siguiendo la configuración anterior, los puntos de montaje autofs serán /home/payroll y /home/sales. La opción -fstype= con frecuencia es omitiday generalmente no se necesita para una correcta operación.

El automontaje creará los directorios si no existen. si los directorios existen antes de que se iniciara el automontaje, este no los eliminará cuando existen. Puede iniciar o reiniciar el demonio de automontaje emitiendo el siguiente comando:

$/sbin/service autofs start 
o $/sbin/service autofs restart

Al usar la configuración anterior si un proceso requiere acceso a un directorio desmontado de autofs tal como /home/payroll/2006/July.sxc entonces el demonio de automontaje montará automáticamente el directorio. Si se especifica un tiempo de espera, el directorio será desmontado automáticamente si el directorio no es accedido durante el tiempo de espera.

Puede ver el estatus del demonio de automontaje con el siguiente comando:

 $/sbin/service/autofs status

19.3.3. Tareas comunes autofs

19.3.3.1. Anulación o incremento de los archivos de configuración de sitios

Puede llegar a ser útil el saber como anular sitios predeterminados para un punto de montaje específico en un sistema de clientes. Por ejemplo, asumiendo que los mapeos de automontaje se encuentran almacenados en NIS y que el archivo /etc/nsswitch.conf tiene la siguiente directiva:

automontaje: archivos nis

y el archivo de mapeo auto.master NIS contiene lo siguiente:

/home auto.home

También asume que el mapeo auto.home NIS contiene lo siguiente:

beth      fileserver.example.com:/export/home/beth
joe      fileserver.example.com:/export/home/joe
*      fileserver.example.com:/export/home/&

y el archivo mapa /etc/auto.home no existe.

Para el ejemplo anterior asumamos que el sistema de clientes necesita montar directorios principales desde un servidor diferente. En este caso, el cliente necesitará utilizar el siguiente mapeo /etc/auto.master:

/home /etc/auto.home2
+auto.master

y el mapa /etc/auto.home2 contiene la entrada:

*   labserver.example.com:/export/home/&

Debido a que la primera ocurrencia de un punto de montaje es procesada, /home tendrá en contenido de /etc/auto.home2 en vez del mapeo auto.home NIS.

De manera laternativa, si sólo quiere aumentar la amplitud del sitio del mapeo

auto.home

con unas pocas entradas cree un mapeo del archivo /etc/auto.home e en él pónga sus nuevas entradas y luego al final incluya en mapeo auto.home NIS. Entonces el mapeo del archivo /etc/auto.home se verá similar a esto:

mydir someserver:/export/mydir
+auto.home

Dado el mapeo auto.home NIS listado anteriormente, un ls de /home daría:

$ ls /home
beth        joe        mydir

Este último ejemplo funciona como se esperaba ya que autofs sabe que no debe incluir el contenido de un mapeo de archivo con el mismo nombre que el que está leyendo y por lo tanto se mueve a la siguiente fuente de mapeo en la configuración nsswitch.

19.3.3.2. Utilizando LDAP para almacenar mapas de automount

En todos los sistemas se deben instalar las bibliotecas de clientes LDAP, las cuales recuperan mapeos de automontaje desde LDAP. En RHEL 5, el paquete openldap debe ser instalado automáticamente como una dependencia del automounter. Para configurar el acceso LDAP modifique /etc/openldap/ldap.conf. Asegúrese de que BASE y URI se encuentran configurados apropiadamente para su sitio. Asegúrese de que el esquema se encuentra en la configuración.

El esquema establecido más recientemente para almacenar mapeos de automontaje en LDAP se describen en rfc2307bis. Para utilizar este esquema es necesario establecerlo en la configuración autofs (/etc/sysconfig/autofs) eliminando los comentarios de la definición del esquema. Por ejemplo:

DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"

Asegúrese de que sólo son entradas del esquema sin comentarios en la configuración. Observe que automountKey reemplaza el atributo cn en el esquema rfc2307bis. A continuación se describe un LDIFde una configuración de ejemplo:

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.master))
# requesting: ALL
#

# auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto.master

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.master,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# /home, auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: automount
cn: /home

automountKey: /home
automountInformation: auto.home

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.home))
# requesting: ALL
#

# auto.home, example.com
dn: automountMapName=auto.home,dc=example,dc=com
objectClass: automountMap
automountMapName: auto.home

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.home,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# foo, auto.home, example.com
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: foo
automountInformation: filer.example.com:/export/foo

# /, auto.home, example.com
dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: /
automountInformation: filer.example.com:/export/&

19.3.3.3. Adaptando mapas de Autofs v4 a Autofs v5

Entradas de mapas múltiples v4

La versión 4 de autofs introdujo la noción de una entrada multi-mapeada en el mapeo maestro. Una entrada multi-mapeada es así:

<mount-point> <maptype1> <mapname1> <options1> -- <maptype2> <mapname2> <options2> -- ...

Cualquier número de mapeos pueden ser combinados en un solo mapeo de esta manera. La versión 5 ya no cuenta con esta característica. Esto se debe a que la versión 5 soporta mapeos incluídos, los cuales se pueden utilizar para obtener los mismos resultados. Considere el siguiente ejemplo multi-mapeo: /home file /etc/auto.home -- nis auto.home.

Esto puede ser reemplazado por la configuración siguiente para v5:

/etc/nsswitch.conf debe listar:

automontaje: archivos nis

/etc/auto.master debe contener:

/home  auto.home

/etc/auto.home debe contener:

<entradas para el directorio home>
+auto.home

De esta manera, las entradas desde /etc/auto.home y el mapeo auto.home nis se combinan.

Múltiples mapeos maestros

En la versión 4 autofs es posible combinar el contenido de los mapeos maestros de cada fuente como archivos, nis, hesiod y LDAP. La versión 4 del automontaje busca un mapeo maestro para cada uno de los recursos enumerados en /etc/nsswitch.conf. El mapeo es leído si existe y su contenido es fusionado en un mapeo auto.master extenso.

En la versión 5 este ya no sucede así. Solo se consulta el primer mapeo maestro encontrado en la lista de recursos en nsswitch.conf. Si desea fusionar el contenido de múltiples mapeos maestros incluso se pueden utilizar los mapeos incluidos. Considere el siguiente ejemplo:

/etc/nsswitch.conf:
automount: files nis

/etc/auto.master:
/home  /etc/auto.home
+auto.master

La configuración anterior fusionará el contenido de auto.master con base en los archivos y el auto.master basado en NIS. Sin embargo, debido a que las entradas de mapeo incluidas sólo se permiten en mapeos de archivos no hay manera de incluir tanto un auto.master NIS y un auto.master LDAP.

Esta limitación se puede superar creando mapeos maestros que tiene un nombre diferente en la fuente. En el ejemplo anterior si teníamos un mapeo maestro LDAP llamado auto.master.ldap también podríamos añadir "+auto.master.ldap" al mapeo maestro basado en archivos y dado que "ldap" es enumerado como un recurso en nuestra configuración nsswitch entonces también sería incluído.

19.4. Opciones de montaje NFS comunes

Aparte de montar un sistema de archivos a través de NFS en un host remoto, existen otras opciones que se pueden ser especificar al momento del montaje que pueden hacerlo más fácil de usar. Estas opciones pueden usarse con el comando manual mount, las configuraciones /etc/fstab y autofs.

Las siguientes son opciones populares utilizadas para montajes NFS:

  • fsid=num — Obliga a que las configuraciones de manejo y de atributos de archivos en el cable, a ser num en vez de un número derivado desde el número menor y mayor del dispositivo de bloques en el sistema de archivos montado. El valor 0 tiene un significado especial cuando se utiliza con NFSv4. NFSv4 tiene un concepto de raíz del sistema de archivos exportado en general. El punto de exportación con fsid=0 se utiliza como esta raíz.

  • hard o soft — Especifican si el programa que usa un archivo vía una conexión NFS, debe parar y esperar (hard) a que el servidor vuelva a estar en línea, si el host que sirve el sistema de archivos no está disponible, o si debe informar de un error (soft).

    Si se especifica la opción hard, el usuario no podrá terminar el proceso que está esperando que la comunicación NFS se reanude a menos que especifique la opción intr.

    Si usa soft, puede usar la opción adicional timeo=<valor>, donde <valor> especifica el número de segundos que deben pasar antes de informar del error.

Nota

No se recomienda utilizar montajes suaves ya que pueden generar errores de E/S en redes bastante congestionadas o cuando utilizan un servidor muy ocupado.

  • intr — Permite que se interrumpan las peticiones NFS si el servidor se cae o no puede ser accedido.

  • nfsvers=2 o nfsvers=3 — Especifica cuál versión del protocolo NFS se utiliza. Esto es útil para los hosts que ejecutan múltiples servidores NFS. Si no se especifica ninguna versión, NFS utiliza la última versión compatible con el kernel y el comando mount. Esta opción no es soportada con NFSv4 y por tanto no se debería de utilizar.

  • noacl — Apaga todo el procesamiento de ACL. Esto puede ser necesario cuando se trate con versiones más viejas de Red Hat Enterprise Linux, Red Hat Linux o Solaris, puesto que la tecnología ACL más reciente no es compatible con sistemas más antiguos.

  • nolock — Desactiva el bloqueo de archivos. Esta configuración es requerida a veces cuando conectamos a servidores NFS antiguos.

  • noexec — No permite la ejecución de binarios en sistemas de archivos montados. Esto es útil si el sistema está montando un sistema de archivos no Linux a través de NFS que contiene binarios incompatibles.

  • nosuid — No permite que los bits set-user-identifier o set-group-identifier tomen efecto. Esto previene que los usuarios remotos obtengan privilegios mayores ejecutando un programa setuid.

  • port=num — Especifica el valor numérico del puerto del servidor NFS. Si num es 0 (el valor predeterminado) entonces mount consulta al portmapper del host remoto por el número de puerto. Si el demonio NFS del host remoto no está registrado con su portmapper, se utilizará el número de puerto estándar de NFS, TCP 2049.

  • rsize=num and wsize=num — Estas configuraciones pueden acelerar la comunicación NFS tanto para lecturas (rsize) como para escrituras (wsize), configurando un tamaño de bloque de datos mayor, en bytes, que serán transferidos de una sola vez. Tenga cuidado al cambiar estos valores; algunos kernels antiguos de Linux y tarjetas de red no funcionan bien con grandes tamaños de bloques. Para NFSv2 o NFSv3, los valores por defecto para ambos parámetros está configurado a 8192. Para NFSv4, los valores por defecto para ambos parámetros es 32768.

  • sec=mode — Especifica el tipo de seguridad a utilizar cuando se autentique una conexión NFS.

    sec=sys es la configuración por defecto, lo que utiliza UNIX UIDs y GIDs locales a través de AUTH_SYS para autentificar las operaciones NFS.

    sec=krb5 utiliza Kerberos V5 en vez de UNIX UIDs y GIDs locales para autentificar a los usuarios.

    sec=krb5i utiliza Kerberos V5 para la autenticación de usuarios y realiza la verificación de integridad de las operaciones NFS usando sumas de verificación para prevenir el daño de los datos.

    sec=krb5p utiliza Kerberos V5 para la autenticación de usuarios, la verficación de integridad y encriptar el tráfico NFS para prevenir el huzmeo del mismo. Esta es la configuración más segura, pero también tiene la sobrecarga de rendimiento más grande.

  • tcp — Especifica que se utilice el protocolo TCP para el montaje NFS.

  • udp — Especifica que NFS utilice el protocolo UDP para el montaje.

Hay muchas más opciones en la página del manual de mount y nfs

19.5. Iniciar y detener NFS

Para ejecutar un servidor NFS, debe estar ejecutándose el servicio portmap. Para verificar que portmap se encuentra activo, escriba el comando siguiente como root:

/sbin/service portmap status

Si el servicio portmap se está ejecutando entonces se puede iniciar nfs. Para iniciar un servidor NFS escriba como root:

/sbin/service nfs start

Nota

nfslocktambién tiene que ser inciado tanto para el cliente NFS como para el servidor para que funcione de manera apropiada. Para que NFS inicie el bloqueo como tipo root: /sbin/service nfslock start. Si NFS está configurado para que inice durante el arranque asugúrese de que nfslock también se inicie ejecutando chkconfig --list nfslock. Si nfslock no esta configurado como on, esto implica que necesitará ejecutar manualmente /sbin/service nfslock start cada vez que inicie el computador. Para configurar nfslock para que inicie automáticamnete durante el arranque, escriba el siguiente comando en una terminal chkconfig nfslock on.

Para detener el servidor, como usuario root, escriba:

/sbin/service nfs stop

La opción restart es un atajo para detener y luego iniciar NFS. Esta es la forma más eficiente de hacer que los cambios en la configuración tomen efecto luego de modificar el archivo de configuración por NFS.

Para reiniciar el servidor, como usuario root, escriba:

/sbin/service nfs restart

La opción condrestart (reinicio condicional) solamente arranca vsftpd si está ejecutándose en ese momento. Esta opción es muy útil para scripts puesto que no arranca el demonio si este no se está ejecutando.

Para reiniciar condicionalmente el servidor, como root escriba:

/sbin/service nfs condrestart

Para recargar el archivo de configuración del servidor NFS sin reiniciar el servicio, como root escriba:

/sbin/service nfs reload

Por defecto, el servicio nfsno se inicia automáticamente al momento del arranque. Para configurar NFS para que se inicie al momento del arranque, utilice una utilidad initscript tal como /sbin/chkconfig, /usr/sbin/ntsysv o el programa Herramienta de Configuración de Servicios. Consulte el Capítulo 16, Control de acceso a servicios para obtener mayor información sobre estas herramientas.

19.6. Configuración del servidor NFS

Existen tres formas de configurar un servidor NFS bajo Red Hat Enterprise Linux: usando la Herramienta de Configuración del Servidor NFS (system-config-nfs), modificando manualmente su archivo de configuración (/etc/exports), o utilizando el comando /usr/sbin/exportfs.

Para usar la Herramienta de Configuración del Servidor NFS debe estar ejecutando el sistema de Ventanas X, tener privilegios de root, y tener instalado el paquete RPM system-config-nfs. Para arrancar la aplicación haga click en Sistema => Administración => Configuración del Servidor => NFS Tmabién puede escribir el comando system-config-nfs en una terminal. La ventana de la herramienta de Configuración del Servidor NFS se ilustra a continuación.

Herramienta de configuración del servidor NFS

Herramienta de configuración NFS

Figura 19.1. Herramienta de configuración del servidor NFS

Con base en ciertas configuraciones del cortafuegos puede que necesite configurar los procesos del demonio NFS para utilizar puertos de red específicos. La configuración del servidor NFS le permite especificar los puertos para cada proceso en vez de utilizar los puertos aleatorios asignados por el portmapper. Puede modificar la configuración del Servidor NFS al hacer click en el botón Configuración del Servidor. La figura a continuación describe la ventana de Configuración del Servidor NFS.

Parámetros del servidor NFS

Parámetros del servidor NFS

Figura 19.2. Parámetros del servidor NFS

19.6.1. Exportar o compartir sistemas de archivos NFS

El compartir o servir archivos desde un servidor NFS se conoce como exportar los directorios. La Herramienta de Configuración del Servidor NFS se puede utilizar para configurar un sistema en un servidor NFS.

Para añadir un recurso compartido NFS haga click en el botón Añadir. Aparecerá el diálogo que se muestra en Figura 19.3, “Añadir particiones”.

La pestaña Básico requiere la siguiente información:

  • Directorio — Especifique el directorio a compartir, por ejemplo /tmp.

  • Host(s) — Especifica el host(s) con los cuales compartir el directorio. Refiérase a Sección 19.6.3, “Formatos del nombre de host” para obtener una explicación de los formatos posibles.

  • Permisos básicos — Especifique si el directorio debería tener permisos de sólo lectura o sólo escritura.

Añadir particiones

Añadir particiones NFS

Figura 19.3. Añadir particiones

La pestaña Opciones generales permite configurar las siguientes opciones:

Opciones generales de NFS

Opciones generales

Figura 19.4. Opciones generales de NFS

  • Permitir conexiones desde un puerto 1024 o superior — Los servicios iniciados en los puertos con números inferiores a 1024 deben iniciarse como root. Seleccione esta opción para permitir que el servicio NFS sea iniciado por un usuario regular y no root. Esta opción corresponde a insecure.

  • Permitir el bloqueo de archivos inseguros — No realiza una petición de bloqueo. Esta opción corresponde a insecure_locks.

  • Inhabilite la verificación de subárbol — Si se exporta un subdirectorio de un sistema de archivos, pero no se exporta el sistema de archivos completo, el servidor comprueba si el archivo en cuestión está en el subdirectorio exportado. A este control se le conoce como verificación de subárbol. Seleccione esta opción para inhabilitar el control del subárbol. Si se exporta el sistema de archivos completo, al seleccionar que se inhabilite la verificación del subárbol puede incrementar el ratio de transferencia. Esta opción corresponde a no_subtree_check.

  • Operaciones de escritura sincronizada a petición — Habilitada por defecto, esta opción no deja que el servidor responda a las peticiones antes de que los cambios hechos a petición sean escritos en el disco. Esta opción corresponde a sync. Si no la ha seleccionado, se usará la opción async.

    • Forzar la sincronización de operaciones de escritura inmediatamente — No retrase la escritura en disco. Esta opción corresponde a no_wdelay.

  • Ocultar sistemas de archivos debajo cambia la opción nohide a apagado o prendido. Cuando la opción nohide se encuentra apagada se revelan los directorios anidados. Por lo tabto los clientes pueden navegar en el sistema de archivos desde el padre sin notar ningún cambio.

  • Exportar solo si ha sido montado configura la opción mountpoint, la cual permite que se exporte un directorio sólo si ha sido montado.

  • El Punto de Montaje Opcional especifica la ruta hacia un punto de montaje opcional. Haga click en Navegar para ir hasta el punto de montaje preferido o escriba la ruta si la conoce.

  • Configurar explícitamente ID del sistema de archivos: configura la opción fsid=X. Esto se utiliza principalmente en una configuración con clústers. La utilización de un ID consistente para el sistema de archivos en todos loc clústers evita el tener manejadores de archivos NFS antiguos.

Acceso de usuarios NFS

Acceso de usuarios

Figura 19.5. Acceso de usuarios NFS

La pestaña Acceso al usuario le permite configurar las opciones siguientes:

  • Trate el usuario de root remoto como root local — Por defecto, el usuario y los IDs de grupo del usuario de root son 0. Root ubica el ID de usuario en 0 y el ID de grupo en 0 para los IDs de grupo y de usuario anónimos de manera que root en un cliente no posee privilegios de root en el servidor NFS. La selección de esta opción puede aminorar la seguridad del sistema. No lo seleccione a menos que sea absolutamente necesario. Esta opción corresponde a no_root_squash.

  • Trate a todos los usuarios de clientes como usuarios anónimos — Si selecciona esta opción, todos los IDs de usuarios y de grupos están ubicados en el usuario anónimo. Esta opción corresponde a all_squash.

    • Especificar el ID del usuario local para los usuarios anónimos — Si selecciona Tratar a todos los usuarios de clientes como usuarios anónimos, esta opción le permite especificar un ID de usuario para el usuario anónimo. Esta opción corresponde a anonuid.

    • Especificar el ID del grupo local para los usuarios anónimos — Si selecciona Tratar todos los usuarios de clientes como usuarios anónimos, esta opción le permite especificar un ID de grupo para el usuario anónimo. Esta opción corresponde a anongid.

Para modificar una partición NFS ya existente, selecciónela desde la lista y pulse el botón Propiedades. Para borrar un share NFS ya existente, selecciónelo desde la lista y pulse el botón Eliminar.

Después de hacer click en OK para añadir, editar o borrar un recurso compartido NFS de la lista, los cambios tiene lugar inmediatamente — el demonio del servidor es reiniciado y el archivo de configuración antiguo se guarda como /etc/exports.bak. La nueva configuración es escrita en /etc/exports.

La Herramienta de Configuración del Servidor NFS lee y escribe directamente al archivo de configuración /etc/exports. Por tanto, el archivo puede ser modificado manualmente después de usar la herramienta y la herramienta se puede usar después de modificar el archivo manualmente (asumiendo que el archivo fué modificado con la sintáxis correcta).

La siguiente sección discute la modificación manual de /etc/exports y la utilización del comando /usr/sbin/exportfs para exportar sistemas de archivos NFS.

19.6.2. Configuración desde la línea de comandos

Si prefiere modificar archivos de configuración usando un editor de texto o si no tiene el sistema X Window instalado, puede modificar el archivo de configuración directamente.

El archivo /etc/exports controla qué directorios exporta el servidor NFS. Su formato es como puede ver a continuación:

directorionombre-de-host(opciones)

La única opción que se debe especificar es una de sync o async (se recomienda sync). Si se especifica sync, el servidor no responde a las peticiones antes de que los cambios realizados sean escritos al disco.

Por ejemplo:

/misc/export speedy.example.com(sync)

permitirá a los usuarios desde speedy.example.com montar /misc/export con privilegios de lectura/escritura.

/misc/export speedy.example.com(rw,sync)

permitirá a los usuarios desde speedy.example.com montar /misc/export con privilegios de lectura/escritura.

Remítase a la Sección 19.6.3, “Formatos del nombre de host” para obtener una explicación de los posibles formatos de nombre de host.

Atención

Esté atento a los espacios en el archivo /etc/exports. Si no existen espacios entre el nombre del host y las opciones en paréntesis, las opciones se aplican sólo al nombre del host. Si existe un espacio entre el nombre del host y las opciones, las opciones se aplican al resto del mundo. Por ejemplo, examine las líneas siguientes:

/misc/export speedy.example.com(rw,sync) /misc/export speedy.example.com (rw,sync)

La primera línea otorga acceso de lectura/escritura a los usuarios desde speedy.example.com y niega acceso a todos los otros usuarios. La segunda línea otorga acceso de sólo lectura a los usuarios desde speedy.example.com (predeterminado) y permite al resto del mundo acceso de lectura/escritura.

Cada vez que cambie /etc/exports, debe informar al demonio NFS del cambio, o recargar el archivo de configuración con el siguiente comando:

/sbin/service nfs reload

19.6.3. Formatos del nombre de host

El host(s) puede ser de las siguientes maneras:

  • Máquina individual — Un nombre de dominio completamente calificado (que el servidor lo puede resolver), nombre de host (que el servidor lo puede resolver) o una dirección IP.

  • Series de máquinas especificadas con comodines — Use los caracteres * o ? para especificar una coincidencia de cadenas. Los comodines no son utilizados con direcciones IP; sin embargo, pueden funcionar accidentalmente si fallan las búsquedas inversas de DNS. Cuando se especifican comodines en un dominio de nombres completamente calificado, los puntos (.) no son incluidos en el comodín. Por ejemplo, *.example.com incluye one.example.com pero no incluye one.two.example.com.

  • Redes IP — Use a.b.c.d/z, donde a.b.c.d es la red y z es el número de bits en la máscara de red (por ejemplo 192.168.0.0/24). Otro formato aceptables es a.b.c.d/netmask, donde a.b.c.d es la red y netmask es la máscara de red (por ejemplo, 192.168.100.8/255.255.255.0).

  • Grupos de red — En el formato @group-name, donde group-name es el grupo de red de NIS.

19.7. El archivo de configuración /etc/exports

El archivo /etc/exports controla cuáles sistemas de archivos son exportados a las máquinas remotas y especifica las opciones. Las líneas en blanco se ignoran, se pueden realizar comentarios inciando la línea con el símbolo # y las líneas largas pueden ser divididas con una barra invertida (\). Cada sistema de archivos exportado debe tener su propia línea y cualquier lista de hosts autorizados colocada después de un sistema de archivos exportado debe estar separada por un espacio. Las opciones para cada uno de los hosts deben ser colocadas entre paréntesis directamente detrás del identificador del host sin ningún espacio separando el host y el primer paréntesis. Los tipos de hosts válidos son gss/krb5gss/krb5i y gss/krb5p.

Una línea para un sistema de archivos exportado tiene la estructura siguiente:

<export><host1>(<opciones>) <hostN>(<opciones>)...

En esta estructura, reemplace <export> con el directorio a exportar, reemplace <host1> con el host o la red a la cual va a compartir el directorio y reemplace <options> con las opciones para ese host o red. Los hosts adicionales se pueden especificar en una lista separada por espacios.

Se pueden usar los métodos siguientes para especificar nombres de host:

  • host único — Cuando una máquina en particular es especificada con nombre completo de dominio, nombre de máquina o dirección IP.

  • comodines — Usamos un carácter * o ? para referirnos a un grupo de nombres completos de dominio o direcciones IP o que coincidan con una cadena particular de letras. Los comodines no se deberían de utilizar con direcciones IP; sin embargo, es posible que funcionen de manera accidental si fallan las búsquedas inversas de DNS.

    Tenga cuidado cuando especifique comodines con nombres de dominio completos pues tienden a ser más exactos de lo que usted cree. Por ejemplo, el uso de *.example.com como comodín permitirá a sales.example.com acceder al sistema de archivos exportado, pero no a bob.sales.example.com. Para que ambas posibilidades coincidan debería usar *.example.com y también *.*.example.com.

  • Redes IP — Permite el emparejar hosts con base en sus direcciones IP dentro de una red más grande. Por ejemplo, 192.168.0.0/28 permite el acceso a las primeras 16 direcciones IP, desde la 192.168.0.0 a la 192.168.0.15, para acceder al sistema de archivos exportado, pero no a la 192.168.0.16 y superiores.

  • grupos de redes — Permite usar un nombre de grupo de red NIS escrito como @<group-name>. Esto pone al servidor NIS al control del acceso de este sistema de archivos, en donde se pueden añadir o borrar usuarios de un grupo NIS sin que afecte a /etc/exports.

En su forma más sencilla el archivo /etc/exports sólo especifica el directorio a exportar y los hosts que pueden usarlo como en el siguiente ejemplo:

/exported/directory bob.example.com

En el ejemplo, bob.example.com puede montar /exported/directory/. Como no se especifica ninguna opción en este ejemplo tendrán efecto las siguientes opciones predeterminadas de NFS:

  • ro — Se montan los sistemas de archivos como de sólo lectura (read-only). Los host remotos no pueden hacer cambios a los datos compartidos en el sistema de archivos. Para permitir que los hosts puedan hacer cambios, debe especificar la opción rw (lectura-escritura, read-write).

  • wdelay — Provoca que el servidor NFS retrase el escribir a disco si sospecha que otra petición de escritura es inminente. Esto puede mejorar el rendimiento reduciendo las veces que se debe acceder al disco por comandos de escritura separados. Use no_wdelay para desactivar esta opción, la cual sólo funciona si está usando la opción sync.

  • root_squash — Previene a los usuarios root conectados remotamente de tener privilegios como root asignándoles el id del usuario de nfsnobody. Esto reconvierte el poder del usuario root remoto al de usuario local más bajo, previniendo los cambios no autorizados a archivos en el servidor remoto. De manera alternativa, la opción no_root_squash lo desactiva. Para reconvertir a todos los usuarios, incluyendo a root, use la opción all_squash. Para especificar los ID de usuario y grupo para usar con usuarios remotos desde un host particular, utilice las opciones anonuid y anongid, respectivamente. En este caso puede crear una cuenta de usuario especial para que los usuarios NFS remotos compartan y especificar (anonuid=<uid-value>,anongid=<gid-value>), en donde <uid-value> es el número de ID del usuario y <gid-value> es el número de ID del grupo.

Importante

Por defecto, las listas de control de acceso (ACLs) son soportadas por NFS bajo Red Hat Enterprise Linux. Para desactivar esta funcionalidad especifique la opción no_acl cuando esté exportando el sistema de archivos.

Cada valor predeterminado para un sistema de archivos exportado debe ser ignorado explícitamente. Por ejemplo, si no se especifica la opción rw, entonces el sistema de archivos es exportado como de sólo lectura. Lo siguiente es una línea de muestra de /etc/exports la cual sobreescribe dos opciones predeterminadas:

/another/exported/directory 192.168.0.3(rw,sync)

En este ejemplo 192.168.0.3 puede montar /another/exported/directory/ como lectura/escritura y todas las transferencias al disco son efectuadas antes de completar la petición de escritura del cliente.

Adicionalmente, hay otras opciones que están disponibles que no tienen especificado un valor predeterminado. Estas incluyen la habilidad para desactivar la verificación por subdirectorios, permitir el acceso desde puertos inseguros y permitir el bloqueo de archivos inseguros (necesario para algunas implementaciones antiguas de clientes NFS). Vea la página del manual exports para ver detalles sobre estas opciones menos usadas.

Aviso

La manera en que el archivo /etc/exports está organizado es muy importante particularmente en lo que concierne a los espacios en blanco. Recuerde separar siempre los sistemas de archivos exportados de una máquina a la otra con un espacio. Sin embargo, no debería haber otros espacios en el archivo a menos que se usen en líneas de comentarios.

Por ejemplo, las siguientes dos líneas significan cosas distintas:

/home bob.example.com(rw) /home bob.example.com (rw)

La primera línea permite sólo a los usuarios de bob.example.com acceder en modo de lectura/escritura al directorio /home. La segunda línea permite a los usuarios de bob.example.com montar el directorio como de sólo lectura (el predeterminado) pero el resto del mundo puede instalarlo como lectura/escritura.

19.7.1. El comando exportfs

Cada sistema de archivos que se exporta a usuarios remotos a través de NFS, así como los niveles de acceso relativos a ellos, se listan en el archivo /etc/exports. Cuando comienza el servicio nfs, se lanza el comando /usr/sbin/exportfs y lee este archivo, pasa el control a rpc.mountd (si es NFSv2 o NFSv3) para el proceso de montaje real, luego a rpc.nfsd en donde los sistemas de archivos están disponibles para los usuarios remotos.

Cuando se ejecuta manualmente, el comando /usr/sbin/exportfs permite al superusuario exportar o no de forma selectiva, directorios concretos sin reiniciar los servicios NFS. Cuando se le dan las opciones apropiadas, el comando /usr/sbin/exportfs escribe los sistemas de archivos exportados a /var/lib/nfs/xtab. Como rpc.mountd se refiere al archivo xtab para decidir privilegios de acceso a un sistema de archivos, los cambios en la lista de sistemas de archivos exportados tienen efecto inmediatamente.

La siguiente es una lista de las opciones más comunes disponibles para /usr/sbin/exportfs:

  • -r — Provoca que todos los directorios listados en /etc/exports sean exportados construyendo una nueva lista de exportación en /etc/lib/nfs/xtab. Esta opción refresca la lista de exportación con cualquier cambio que se haya realizado a /etc/exports.

  • -a — Provoca que todos los directorios sean exportados o no, dependiendo de qué otras opciones hemos pasado a /usr/sbin/exportfs. Si no se pasan otras opciones, /usr/sbin/exportfs exporta todos los sistemas de archivos especificados en /etc/exports.

  • -o sistema-de-archivos — Permite especificar directorios a exportar que no estén listados en /etc/exports. Reemplace file-systems con los sistemas de archivos adicionales a exportar. Estos sistemas de archivos deben tener el mismo formato en que fueron especificados en /etc/exports. Consulte la Sección 19.7, “El archivo de configuración /etc/exports para más información sobre la sintaxis de /etc/exports. Esta opción se utiliza a menudo para probar un sistema de archivos antes de añadirlo de forma permanente a la lista de sistemas a exportar.

  • -i — Ignora /etc/exports; sólo se utilizan las opciones dadas desde la línea de comandos para definir los sistemas de archivos exportados.

  • -u — No exporta todos los directorios compartidos. El comando /usr/sbin/exportfs -ua suspende la compartición de archivos NFS mientras que mantiene todos los demonios NFS activos. Para reactivar NFS escriba exportfs -r.

  • -v — Operación descriptiva, en donde se muestran en gran detalle los sistemas de archivos exportados o dejados de exportar al ejecutar el comando exportfs.

Si no se pasan opciones al comando /usr/sbin/exportfs, mostrará una lista de los sistemas de archivos actualmente exportados.

Para obtener mayor información sobre /usr/sbin/exportfs, consulte la página man de exportfs.

19.7.1.1. Uso de exportfs con NFSv4

El comando exportfs se utiliza para mantener la tabla NFS de los sistemas de archivos exportados. Cuando se escribe en una terminal sin argumentos, el comando exportfs muestra todos los directorios exportados.

Puesto que en NFSv4 ya no utiliza el protocolo rpc.mountd como se utilizó en NFSv2 y NFSv3, el montaje de sistemas de archivos ha cambiado.

Un cliente NFSv4 ahora tiene la habilidad de ver todas las exportaciones servidas por el servidor NFSv4, como un único sistema de archivos, llamado el pseudo sistema de archivos NFSv4. En Red Hat Enterprise Linux se identifica el pseudo sistema de archivos como un sistema de archivos único y verdadero, identificado con la opción fsid=0.

Por ejemplo, los comandos siguientes no se podrían ejecutar en un servidor NFSv4:

mkdir /exports mkdir /exports/opt mkdir /exports/etc mount --bind /usr/local/opt /exports/opt mount --bind /usr/local/etc /exports/etc exportfs -o fsid=0,insecure,no_subtree_check gss/krb5p:/exports exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/opt exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/etc

En este ejemplo, se proporciona a los clientes con múltiples sistemas de archivos a montar usando la opción --bind, la cual crea enlaces irrompibles.

Debido a la característica del sistema de pseudo archivos las versiones 2, 3 y 4 no simpre son compatibles. Por ejemplo, dado el siguiente árbol de directorios:

 /home /home/sam /home/john /home/joe

y el archivo export:

 /home *(rw,fsid=0,sync)

Lo siguiente debe funcionar para las versiones 2, 3 y 4 NFS:

 mount server:/home /mnt/home ls /mnt/home/joe

El siguiente comando debe funcionar con v4

 mount -t nfs4 server:/ /mnt/home ls /mnt/home/joe

La diferencia es "server:/home" y "server:/". Para que todas las configuraciones de las exportaciones sean compatibles para todas las veriones necesita exportar (solo lectura) la raíz del sistema de archivos con un fsid=0. fsid=0 le señala al servidor NFS que la exportación es la raíz.

 / *(ro,fsid=0) /home *(rw,sync,nohide)

Ahora con estas exportaciones tanto "mount server:/home /mnt/home" como "mount -t nfs server:/home /mnt/home" funcionarán como se espera.

19.8. Protección de NFS

NFS trabaja muy bien compartiendo sistemas de archivos enteros con un gran número de hosts conocidos de una manera muy transparente. Sin embargo, esta facilidad de uso trae una variedad de problemas potenciales de seguridad.

Los puntos siguientes deberían ser considerados cuando se exporten sistemas de archivos NFS en un servidor o cuando se monten en un cliente. Haciendo esto reducirá los riesgos de seguridad NFS y protegerá mejor los datos en el servidor.

19.8.1. Acceso al sistema

La versión de NFS que planee implementar, depende de su red existente y de sus preocupaciones de seguridad. La sección siguiente explica las diferencias entre las medidas de seguridad con NFSv2, NFSv3 y NFSv4. Si es posible, utilice NFSv4. Es el más recomendado.

19.8.1.1. Uso de NFSv2 o NFSv3

NFS controla quien puede montar y exportar sistemas de archivos basados en la máquina que hace la petición, no el usuario que utiliza el sistema de archivos. Los hosts tienen que tener los derechos para montar los sistemas de archivos exportados explícitamente. El control de acceso no es posible para usuarios, aparte de los permisos de archivos y directorios. En otras palabras, una vez que un sistema de archivos es exportado vía NFS, cualquier usuario en cualquier máquina remota conectada al servidor NFS puede acceder a los datos compartidos. Para limitar estos riesgos potenciales, los administradores sólo pueden permitir acceso de sólo-lectura o reducir a los usuarios a un usuario común y groupid. Pero estas soluciones pueden impedir que la compartición NFS sea usada de la forma en que originalmente se pensó.

Adicionalmente, si un atacante gana el control del servidor DSN usado por el sistema que exporta el sistema de archivos NFS, el sistema asociado con un nombre de host concreto o nombre de dominio totalmente cualificado, puede ser dirigido a una máquina sin autorización. En este punto, la máquina desautorizada es el sistema que tiene permitido montar la compartición NFS, ya que no hay intercambio de información de nombre de usuario o contraseña para proporcional seguridad adicional al montaje NFS.

Los comodines o metacaracteres deben ser usados lo menos posible cuando garantizamos el acceso a una compartición NFS. El uso de los comodines puede incluir más sistemas de los que se desean.

También es posible restringir el acceso al servicio portmap a través de los TCP wrappers. El acceso a los puertos usados por portmap, rpc.mountd y rpc.nfsd se puede limitar creando reglas de cortafuegos con iptables.

Para obtener mayor información sobre la manera de asegurar NFS y portmap, consulte el Sección 43.7, “IPTables”.

19.8.1.2. Uso de NFSv4

El lanzamiento de NFSv4 trajo consigo una revolución para la autentificación y la seguridad cuando se comparten directorios a través de NFS. NFSv4 manda la implementación del módulo del kernel RPCSEC_GSS, el mecanismo GSS-API de la versión Kerberos 5, SPKM-3, y LIPKEY. Con NFSv4, los mecanismos de seguridad obligatorios están orientados hacia la autenticación de usuarios individuales y no a máquinas clientes, como lo hace NFSv2 y NFSv3.

Nota

Se asume que se tiene instalado un servidor de entrega de tíckets (KDC) y que está configurado de la forma correcta, antes de configurar el servidor NFSv4. Kerberos es un sistema de autenticación de red, el cual permite a los clientes y servidores auteticarse unos a otros mediante el uso de encriptación simétrica y una tercera parte confible, el KDC.

NFSv4 incluye el soporte a ACL basado en el modelo de Microsoft Windows NT, no en el modelo POSIX, por sus funcionalidades y porque es implementado ampliamente. NFSv2 y NFSv3 no son compatibles con los atributos nativos de ACL.

Otra funcionalidad de seguridad importante de NFSv4 es la eliminación del demonio rpc.mountd. El demonio rpc.mountd presentaba posibles agujeros de seguridad debido a la forma en que trataba con los manejadores de archivos.

Para obtener más información sobre la estructura de RPCSEC_GSS, incluyendo cómo rpc.svcgssd and rpc.gssd interoperan, consulte en http://www.citi.umich.edu/projects/nfsv4/gssd/.

19.8.2. Permisos de archivos

Una vez que el sistema de archivos NFS es montado como lectura/escritura por un host remoto, la única protección que tiene cada archivo compartido son sus permisos. Si dos usuarios que comparten el mismo valor de identificador de usuario montan el mismo NFS, ellos podran modificar sus archivos mutuamente. Adicionalmente, cualquiera con acceso root en el sistema cliente puede usar el comando su - para volverse un usuario que tenga acceso a determinados archivos a través del recurso compartido NFS.

Por defecto, las listas de control de acceso (ACL según sus siglas en inglés) para NFS son aceptadas en Red Hat Enterprise Linux. No se recomienda desactivar esta función.

El comportamiento predeterminado cuando se está exportando un sistema de archivos a través NFS es usar compresión de root. Esto coloca el identificador del usuario de cualquiera que esté accediendo a la compartición NFS, como el usuario root en su máquina local a un valor de la cuenta de nfsnobody. Nunca desactive la compresión de root.

Si se está exportando un recurso compartido NFS como de sólo lectura, considere usar la opción all_squash, la cual hace que todos los usuarios que acceden al sistema de archivos exportado tomen el ID de usuario del nfsnobody.

19.9. NFS y portmap

Nota

La siguiente sección solamente aplica para las implementaciones NFSv2 o NFSv3 que requieren del servicio portmap para la compatibilidad retroactiva.

El servicio portmapper asigna las peticiones RPC a los puertos que están escuchando. Los procesos RPC notifican a portmap cuando comienzan, registrando el número de puerto que ellos están supervisando y el número de programas RPC que esperan servir. El sistema cliente entonces contacta con el portmap del servidor con un número de programa RPC particular. Entonces portmap redirecciona al cliente al número del puerto apropiado para que se comunique con el servicio solicitado.

Como los servicios basados en RPC confían en portmap para hacer todas las conexiones con las peticiones de clientes entrantes, portmap debe estar disponible antes de que cualquiera de esos servicios comience.

El servicio portmap puede utilizar TCP wrappers para el control de acceso, y las reglas de control de acceso para portmap afectan a todos los servicios basados en RPC. Alternativamente, es posible especificar reglas de control de acceso para cada demonio RPC NFS. Las páginas del manual para rpc.mountd y rpc.statd contienen información relativa a la sintaxis precisa de estas reglas.

19.9.1. Solución de problemas de NFS y portmap

Como portmap proporciona la coordinación entre los servicios RPC y los números de puertos usados para comunicarlos, es útil poder visualizar el estado de los servicios RPC actuales usando portmap cuando estamos resolviendo algún problema. El comando rpcinfo muestra cada servicio basado en RPC con su número de puerto, número de programa RPC, versión y tipo de protocolo (TCP o UDP).

Para asegurarse de que están activos los servicios NFS basados en RPC para portmap, use el comando siguiente como root:

rpcinfo -p

A continuación se presenta una muestra de la salida de este comando:

 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100021 1 udp 32774 nlockmgr 100021 3 udp 32774 nlockmgr 100021 4 udp 32774 nlockmgr 100021 1 tcp 34437 nlockmgr 100021 3 tcp 34437 nlockmgr 100021 4 tcp 34437 nlockmgr 100011 1 udp 819 rquotad 100011 2 udp 819 rquotad 100011 1 tcp 822 rquotad 100011 2 tcp 822 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100005 1 udp 836 mountd 100005 1 tcp 839 mountd 100005 2 udp 836 mountd 100005 2 tcp 839 mountd 100005 3 udp 836 mountd 100005 3 tcp 839 mountd

Si uno de los servicios NFS no inicia correctamente, portmap no puede mapear las peticiones RPC de los clientes para ese servicio al puertos correcto. En muchos casos, si NFS no está presente en la salida de rpcinfo, reiniciar NFS provocará que estos servicios se registren correctamente con portmap y empezarán a funcionar. Para obtener más instrucciones sobre el inicio de NFS consulte la Sección 19.5, “Iniciar y detener NFS”.

Hay disponibles otras opciones útiles para el comando rpcinfo. Para obtener más información consulte la página del manual rpcinfo.

19.10. Uso de NFSv4 sobre TCP

Aunque el protocolo de transporte predeterminado para NFSv4 is TCP; el kernel de Red Hat Enterprise Linux 5 incluy soporte para NFS sobre UDP. Para utilizar NFS sobre UDP incluya la opción -o udp para mount cuando se encuentre montando el sistema de archivos exportados NFS en el sistemas del cliente.

Hay tres maneras de configurar una exportación de sistemas de acrhivos NFS. A petición por medio de la línea de comandos (del lado del cliente), automáticamente por medio del archivo /etc/fstab (del lado del cliente) y automáticamente por medio de los archivos de configuración autofs tal como /etc/auto.master y /etc/auto.misc (del lado del servidor con NIS).

Por ejemplo, en demanda por medio de la línea de comandos (del lado del cliente):

mount -o udp shadowman.example.com:/misc/export /misc/local

Cuando el montaje de NFS se especifica en /etc/fstab (en el cliente):

server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr,udp

Cuando se especifica el montaje NFS en un archivo de configuración autofs para un servidor NIS disponible para estaciones de trabajo activadas para NIS:

myproject -rw,soft,intr,rsize=8192,wsize=8192,udp penguin.example.net:/proj52

Ya que el predeterminado es TCP, si no se especifica la opción -o udp, se accede al sistema de archivos exportados NFS por medio de TCP.

Las ventajas de usar TCP incluyen lo siguiente:

  • Durabilidad de la conexión mejorada, por lo tanto habrá menos mensajes de manejadores de archivos NFS viejos.

  • Ganancia en rendimiento en redes con mucha carga debido a que TCP notifica cada paquete, a diferencia de UDP, que solamente notifica cuando termina.

  • TCP tiene un mejor control de congetión que UDP. En una red muy congestionada, los paquetes UDP son los primeros que se ignoran. Esto quiere decir que si NFS se encuentra escribiendo datos (en pedazos de 8K) todos esos 8K deben ser retransmitidos por UDP. Debido a la confiabilidad de TCP solo se transmite partes de esos datos 8K a la vez.

  • Detección de errores. Cuando una conexión TCP se rompe (debido a que el servidor no se encuentra disponible) el cliente para de enviar datos y reinicia el proceso de conexión una qez que el servidor stá disponible. Con UDP, debido a que no necesita de conexión, el cleinte continua llamando la rd con datos hasta que el servidor reestablece una conexión.

La principal desventaja es que hay un muy pequeño impacto en el rendimiento debido a la sobrecarga asociada con el protocolo TCP.

19.11. Recursos adicionales

Administrar un servidor NFS puede ser un desafío. Muchas opciones, incluyendo algunas no mencionadas en este capítulo, están disponibles para exportar sistemas de archivos NFS o montarlos como cliente. Consulte las siguientes fuentes de información para más detalles.

19.11.1. Documentación instalada

  • /usr/share/doc/nfs-utils-<version-number>/ — Reemplace <version-number> con el número de la versión del paquete NFS instalado. Este directorio contiene bastante información sobre la implementación NFS para Linux, incluyendo un vistazo a varias configuraciones NFS y su impacto en el rendimiento de la transferencia de archivos.

  • man mount — Contiene una vista completa de las opciones de montaje para configuraciones tanto del servidor como del cliente NFS.

  • man fstab — Presenta detalles sobre el formato del archivo /etc/fstab usado para montar sistemas de archivos en el momento de arranque.

  • man nfs — Proporciona detalles de opciones de montaje y de exportación de sistemas de archivos NFS específicos.

  • man exports — Muestra las opciones comunes usadas en el archivo /etc/exports cuando exportamos sistemas de archivos NFS.

19.11.2. Sitios Web útiles

19.11.3. Libros sobre el tema

  • Managing NFS and NIS por Hal Stern, Mike Eisler, y Ricardo Labiaga; O'Reilly & Associates — Es una guía de referencia excelente para las diferentes opciones NFS de montaje y exportación disponibles.

  • NFS Illustrated por Brent Callaghan; Addison-Wesley Publishing Company — Proporciona comparaciones entre NFS y otros sistemas de archivos de red y muestra en detalle como funcionan las comunicaciones NFS.

Capítulo 20. Samba

Samba es una implementación de código abierto del protocolo Server Message Block (SMB). Permite la interconexión de redes Microsoft Windows®, Linux, UNIX y otros sistemas operativos juntos, permitiendo el acceso a archivos basados en Windows y compartir impresoras. El uso de Samba de SMB lo hace parecer como un servidor Windows a clientes Windows.

20.1. Introducción a Samba

El tercer lanzamiento principal de Samba, versión 3.0.0, introduce varias mejoras con respecto a las versiones previas, incluyendo:

  • La habilidad para unirse a un dominio Active Directory a través de LDAP y Kerberos

  • Soporte incorporado de Unicode para la internacionalización

  • Soporte para las conexiones de clientes Microsoft Windows XP Professional a servidores Samba sin la necesidad de hacer hacking del registro local

  • Dos documentos desarrollados por el equipo de desarrollo Samba.org: un manual de referencia de más de 400 páginas y un manual de implementación e integración de más de 300 páginas. Para obtener mayor información sobre estos títulos, consulte la Sección 20.12.2, “Libros relacionados”.

20.1.1. Características de Samba

Samba es una aplicación de servidor poderosa y versátil. Hasta los administradores bien empapados deben conocer sus habilidades y limitaciones antes de intentar una instalación y configuración.

Lo que Samba puede hacer:

  • Sirve árboles de directorios e impresoras a clientes Linux, UNIX y Windows

  • Asiste en la navegación de la red (con o sin NetBIOS)

  • Autentifica las conexiones a dominios Windows

  • Proporciona resolución de nombres de Windows Internet Name Service (WINS)

  • Actúa como un Controlador de Dominio Primario (Primary Domain Controller, PDC) estilo Windows NT®

  • Actúa como un Backup Domain Controller (BDC) para un PDC basado en Samba

  • Actúa como un miembro servidor de dominio de Active Directory

  • Une un Windows NT/2000/2003 PDC

Lo que Samba no puede hacer:

  • Actúa como un BDC para un Windows PDC (y viceversa)

  • Actúa como un controlador de dominio de Active Directory

20.2. Demonios Samba y Servicios relacionados

Lo siguientes es una breve introducción a los demonios individuales y servicios de Samba.

20.2.1. Demonios Samba

Samba está compuesto por tres demonios (smbd, nmbd y winbindd). Dos servicios (smb y windbind) controlan los demonios son detenidos arrancados y otras funcionalidades relacionadas a servicios. Cada demonio se lista en detalle, así como también qué servicio específico tiene control sobre él.

smbd

El demonio de servidor smbd suministra servicios para compartir archivos e impresión a clientes Windows. Además, es responsable por la autenticación de usuarios, el bloqueo de recursos y compartir datos a través del protocolo SMB. Los puertos predeterminados en los cuales el servidor escucha por tráfico SMB, son los puertos TCP 139 y 445.

El demonio smbd es controlado por el servicio smb.

nmbd

El demonio del servidor nmbd entiende y responde a las peticiones de servicio de nombres NetBIOS tales como aquellas producidas por SMB/CIFS en sistemas basados en Windows. Estos sistemas incluyen clientes 95/98/ME, Windows NT, Windows 2000, Windows XP y LanManager. También participa en los protocolos de navegación que forman la vista Entorno de red de Windows. El puerto predeterminado en el que el servidor escucha por tráfico NMB es el puerto UDP 137.

El demonio nmbd es controlado por el servicio smb.

winbindd

El servicio winbind resuelve la información de usuarios y grupos en un servidor Windows NT o Windows Server 2003. Ésto hace que la información de usuarios y grupos pueda ser entendida en UNIX. Esto se logra usando las llamadas RPC de Microsoft, PAM (siglas del inglés Pluggable Authentication Modules) y NSS (siglas del inglés Name Service Switch). Esto permite que los usuarios del dominio Windows NT aparezcan y operen como usuarios UNIX en un máquina UNIX. Aunque está enlazado con la distribución Samba, el servicio winbind se controla separadamente de smb.

El servicio winbind controla al demonio winbindd y no requiere que el servicio smb sea iniciado para poder funcionar. Winbindd también es usado cuando Samba es un miembro del Active Directory y podría se usado asimismo en un controlador de dominio Samba (para implementar grupos anidados y confianza entre dominios). Debido a que winbind es un servicio del lado del cliente utilizado para conectar a los servidores Windows NT, una discusión más detallada de winbind está fuera del ámbito de este manual.

Nota

Consulte Sección 20.11, “Programas de distribución Samba” para obtener una lista de las utilidades incluidas en la distribución Samba.

20.3. Conexión a un recurso compartido Samba

Puede usar Nautilus para ver las comparticiones de Samba disponibles en su red. Seleccione Lugares (en el Panel) => Servidores de red para ver la lista de los grupos de trabajo Samba en su red. También puede escribir smb: en la barra Archivo => Abrir ubicación de Nautilus para ver los grupos de trabajo.

Como se muestra en la Figura 20.1, “Grupos de trabajo SMB en Nautilus”, aparece un icono para cada grupo de trabajo SMB disponible en la red.

Grupos de trabajo SMB en Nautilus

Grupos de trabajo SMB en Nautilus

Figura 20.1. Grupos de trabajo SMB en Nautilus

Haga doble-clic en uno de los iconos de los grupos de trabajo para ver una lista de las computadoras dentro del grupo.

Máquinas SMB en Nautilus

Máquinas SMB en Nautilus

Figura 20.2. Máquinas SMB en Nautilus

Como puede ver en la Figura 20.2, “Máquinas SMB en Nautilus”, hay un icono para cada máquina dentro del grupo de trabajo. Haga doble-clic en un icono para ver las comparticiones Samba en la máquina. Si se requiere una combinación de nombre de usuario y contraseña, se le pedirá.

Alternativamente, puede especificar el servidos Samba y el nombre del recurso compartido en la barra Ubicación: de Nautilus usando la sintaxis siguiente (sustituya <nombre-servidor> y <recurso-compartido> con los valores apropiados):

ks=http://<nombre-servidor>/<recurso-compartido>

20.3.1. Línea de comandos

Para consultar a la red sobre servidores Samba, utilice el comando findsmb. Para cada servidor encontrado se muestra su dirección IP, nombre del NetBIOS, nombre de grupo, sistema operativo y la versión del servidor SMB.

Para conectarse a un recurso compartido Samba desde el intérprete de comandos de la shell, escriba:

smbclient //<nombre-host>/<recurso-compartido> -U <nombre-usuario>

Tendrá que reemplazar <nombre-host> por el nombre de la máquina o la dirección IP del servidor Samba al que desee conectarse, <recurso-compartido> por el nombre del directorio compartido al que quiera acceder y <nombre-usuario> por el nombre del usuario para el sistema Samba. Introduzca la contraseña correcta o presione Intro si no se requiere contraseña.

Si ve smb:\> en la pantalla, la conexión se habrá realizado sin ningún problema. Una vez que se haya conectado, escriba help para ver la lista de comandos. Si desea ver los contenidos de su directorio principal, reemplace recurso-compartido por su nombre del usuario. Si la opción -U no es usada, el nombre de usuario del usuario actual es pasado al servidor Samba.

Para salir de smbclient, escriba exit en la inea de comandos smb:\>.

20.3.2. Montar el recurso compartido Samba

Algunas veces es útil montar un recurso compartido Samba a un directorio para que los archivos en el directorio puedan ser tratados como si éstos fuesen parte del sistema de archivos local.

Para montar un recurso compartido Samba a un directorio, cree el directorio si este aún no existe, y ejecute el comando siguiente como root:

mount -t cifs -o <username>,<password> //<servername>/<sharename>/mnt/point/

Este comando monta <recurso-compartido> desde <nombre-servidor> en el directorio local /mnt/point/. Para obtener mayor información sobre cómo montar recursos compartidos samba, consulte man mount.cifs.

20.4. Configuración del servidor Samba

El archivo de configuración (/etc/samba/smb.conf) le permite a los usuarios ver sus directorios principales como un recurso compartido Samba. También comparte todas las impresoras configuradas para el sistema como impresoras compartidas de Samba. En otras palabras, por ejemplo, puede conectar una impresora al sistema e imprimir a ella desde las máquinas Windows en su red.

20.4.1. Configuración gráfica

Para configurar Samba usando una interfaz gráfica, use la Herramienta de configuración del servidor Samba. Para configurar Samba desde la línea de comandos, salte a la Sección 20.4.2, “Configuración desde la línea de comandos”.

La Herramienta de configuración del servidor Samba es una interfaz gráfica para el manejo de recursos compartidos Samba, usuarios y configuraciones básicas. Modifica los archivos de configuración en el directorio /etc/samba/. Cualquier cambio que no se haya realizado usando esta aplicación a estos archivos, se mantienen.

Para usar esta aplicación, debe estar ejecutando el sistema de ventanas X, tener privilegios de root, y tener el paquete RPM system-config-samba instalado. Para arrancar la Herramienta de configuración del servidor Samba desde el escritorio, vaya al Sistema (en el Panel) => Administración => Configuración de servidores => Samba o escriba el comando system-config-samba en el intérprete de comandos (por ejemplo, desde un terminal XTerm o GNOME).

Herramienta de configuración del servidor Samba

Herramienta de configuración del servidor Samba

Figura 20.3. Herramienta de configuración del servidor Samba

Nota

La Herramienta de configuración del servidor Samba no muestra las impresoras compartidas o la estancia por defecto que permite a los usuarios ver sus propios directorios principales en el Servidor Samba.

20.4.1.1. Configuración de las propiedades del servidor

El primer paso para configurar un servidor Samba es configurar las propiedades básicas y algunas opciones de seguridad. Después de arrancar la aplicación, seleccione Preferencias => Configuración de servidores desde el menú. En la Figura 20.4, “Configuración de las propiedades básicas del servidor” se muestra la pestaña Básica.

Configuración de las propiedades básicas del servidor

Configuración de las propiedades básicas del servidor

Figura 20.4. Configuración de las propiedades básicas del servidor

En la pestaña Básico, especifique en cual grupo debería estar el computador así como también una breve descripción del computador. Esto corresponde a las opciones grupo de trabajo y server string en smb.conf.

Configuración de las propiedades de seguridad

Configuración de las propiedades de seguridad

Figura 20.5. Configuración de las propiedades de seguridad

La pestaña de Seguridad contiene las opciones siguientes:

  • Modo de autenticación — Esto corresponde a la opción seguridad. Seleccione uno de los siguientes tipos de autenticación.

    • ADS — El servidor Samba actúa como un miembro del dominio en un reino Active Directory Domain (ADS). Para esta opción, Kerberos debe estar instalado y configurado en el servidor y Samba debe ser un miembro del reino ADS usando la utilidad net, la cual es parte del paquete samba-client. Consulte la página del manual de net para obtener más detalles. Esta opción no configura Samba para ser un controlador de ADS.

      Nota

      El campo Ámbito de Kerberos debe estar en mayúsculas, por ejemplo: EJEMPLO.COM

      El uso de un servidor Samba como miembro de un dominio en un reino ADS asume que Kerberos está propiamente configurado, incluyendo el archivo /etc/krb5.conf

    • Dominio — El servidor Samba confía en un Controlador de Dominio Windows NT Primario o de Backup para verificar un usuario. El servidor pasa el nombre del usuario y la contraseña al Controlador y espera para que éste la devuelva. Especifique el nombre NetBIOS del Controlador de dominio primario o de backup en el campo Servidor de autenticación.

      La opción Encriptar contraseñas debe estar en si se selecciona.

    • Servidor — El servidor Samba intenta verificar la combinación del nombre de usuario y la contraseña pasándolos a otro servidor Samba. Si no puede, el servidor intenta verificar usando el modo de autenticación del usuario. Especifique el nombre del NetBIOS del otro servidor Samba en el campo Servidor de autenticación.

    • Recurso compartido — Los usuarios Samba no tienen que ingresar un nombre de usuario y contraseña para cada servidor. No se les pide un nombre de usuario y contraseña hasta que ellos traten de conectarse a un directorio compartido específico desde el servidor Samba.

    • Usuario — (Por defecto) Los usuarios Samba deben proporcionar un nombre de usuario y contraseña válidos por servidor Samba. Seleccione esta opción si desea que la opción Nombre de usuario Windows funcione. Consulte la Sección 20.4.1.2, “Administración de usuarios Samba” para más detalles.

  • Encriptar contraseñas — Esta opción debe estar activada si los clientes se están conectando desde Windows 98, Windows NT 4.0 con el Service Pack 3 u otras versiones más recientes de Microsoft Windows. Las contraseñas se transfieren entre el servidor y el cliente en un formato encriptado en vez de texto plano, el cual puede ser fácilmente interceptado. Esto corresponde a la opción encrypted passwords. Consulte la Sección 20.4.3, “Contraseñas encriptadas” para obtener mayor información sobre contraseñas encriptadas Samba.

  • Cuenta invitado — Cuando los usuarios o invitados se conectan a un servidor Samba, ellos deben ser comparados con un usuario válido en el servidor. Seleccione uno de los nombres de usuarios válidos en el sistema para que sea la cuenta de invitados de Samba. Cuando los invitados se conectan a un servidor Samba, ellos tienen los mismos privilegios que este usuario. Esto corresponde a la opción guest account.

Después de pulsar OK, los cambios serán escritos en el archivo de configuración y el demonio será reiniciado; de este modo los cambios toman efecto de inmediato.

20.4.1.2. Administración de usuarios Samba

La Herramienta de configuración del servidor Samba requiere que haya una cuenta activa de usuarios en el sistema actuando como el servidor Samba antes de que se pueda agregar un usuario Samba. El usuario Samba está asociado con la cuenta de usuario existente.

Administración de usuarios Samba

Administración de usuarios Samba

Figura 20.6. Administración de usuarios Samba

Para añadir un usuario Samba, seleccione Preferencias => Usuarios Samba desde el menú y haga clic en el botón Añadir usuario. En la ventana Crear un nuevo usuario Samba seleccione Nombre de usuario Unix desde la lista de usuarios existentes en el sistema local.

Si el usuario tiene un nombre diferente en una máquina Windows y será conectado en un servidor Samba desde una máquina Windows, especifique ese nombre de usuario Windows en el campo Nombre de usuario Windows. El Modo de autenticación en la pestaña Seguridad de Configuraciones de servidores debe estar en Usuario para que esta opción funcione.

También configure una Contraseña Samba para el usuario Samba y confírmela escribiéndola nuevamente. Aún si selecciona usar contraseñas encriptadas para Samba, se recomienda que las contraseñas Samba para todos los usuarios sean diferentes que sus contraseñas del sistema.

Para modificar un usuario existente, seleccione el usuario desde la lista y haga clic en Modificar usuario. Para eliminar un usuario Samba existente, seleccione el usuario, y haga clic en el botón Eliminar usuario. Cuando borra un usuario Samba no está borrando la cuenta del sistema asociada a éste.

Los usuarios son modificados inmediatamente después de hacer clic en el botón OK.

20.4.1.3. Añadir una partición Samba

Para crear un recurso compartido Samba, haga clic en el botón Añadir un recurso compartido en la ventana principal.

Añadir una partición Samba

Añadir una partición Samba

Figura 20.7. Añadir una partición Samba

La pestaña Básico configura las siguientes opciones:

  • Directorio — El directorio a compartir vía Samba. Este directorio debe existir antes de ser introducido en este campo.

  • Nombre de recurso compartido — El nombre del recurso compartido que será visto desde las máquinas remotas. Por defecto, este valor es igual al dado en Directorio pero puede ser configurado.

  • Descripción — Una breve descripción del recurso compartido.

  • Permiso de escritura — Al estar activada, los usuarios pueden leer y escribir los directorios compartidos.

  • Visible — Otorga a los usuarios derechos de sólo lectura para el directorio compartido.

En la pestaña de Acceso, seleccione si desea que sólo usuarios específicos accedan al recurso compartido o si quiere que todos los usuarios Samba tengan acceso a la partición. Si selecciona permitir el acceso a usuarios específicos, seleccione a los usuarios desde la lista de usuarios Samba disponibles.

El recurso compartido es añadida inmediatamente después de presionar OK.

20.4.2. Configuración desde la línea de comandos

Samba usa el archivo de configuración /etc/samba/smb.conf. Si cambia el archivo de configuración, los cambios no tienen efecto hasta que no reinicie el demonio Samba con el comando service smb restart.

Para especificar el grupo de trabajo Windows y una breve descripción del servidor Samba, modifique las líneas siguientes en su archivo smb.conf:

workgroup = NOMBRE-GRUPO-DE-TRABAJO 
server string = COMENTARIO ACERCA DEL SERVIDOR

Reemplace WORKGROUPNAME con el nombre del grupo de trabajo Windows al cual debería pertenecer la máquina. El BRIEF COMMENT ABOUT SERVER es opcional y es usado como el comentario de Windows sobre el sistema Samba.

Para crear un directorio compartido Samba en su sistema Linux, agregue la siguiente sección a su archivo smb.conf (después de modificarlo para reflejar las necesidades de su sistema):

[recurso-compartido] 
comment = Introduzca un comentario aquí 
path = /home/share/ 
valid users = tfox carole 
public = no 
writable = yes 
printable = no 
create mask = 0765

El ejemplo anterior permite a los usuarios tfox y carole leer y escribir en el directorio /home/share, en el servidor Samba, desde un cliente Samba.

20.4.3. Contraseñas encriptadas

La encriptación de contraseñas está activada por defecto por seguridad. Para crear un usuario con una contraseña encriptada, utilice el comando smbpasswd -a <nombre-usuario>.

20.5. Arrancar y detener el Samba

Para arrancar el servidor Samba, escriba el comando siguiente en un intérprete de comandos conectado como root:

/sbin/service smb start

Importante

Para configurar un servidor miembro de dominio, primero debe unirse al dominio o Active Directory usando el comando net joinantes de arrancar el servicio smb.

Para detener el servidor, escriba el comando siguiente en un intérprete de comandos mientras está conectado como root:

/sbin/service smb stop

La opción restart es una forma fácil de detener y luego arrancar Samba. Esta es la forma más confiable de hacer que los cambios tomen lugar después de editar el archivo de configuración Samba. Observe que la opción de reinicio arranca el demonio aún si no estaba ejecutándose originalmente.

Para reiniciar el servidor, escriba el comando siguiente en un intérprete de comandos mientras está conectado como usuario root:

 /sbin/service smb restart 

La opción condrestart (reinicio condicional) solamente arranca smb con la condición de que se esté ejecutando actualmente. Esta opción es útil para los scripts, debido a que no arranca el demonio si este no se está ejecutando.

Nota

Cuando el archivo smb.conf cambia, Samba automáticamente vuelve a cargarlo después de unos minutos. Es igualmente efectivo ejecutar un restart o un reload manualmente.

Para reiniciar condicionalmente el servidor, desde el indicador de comandos, escriba el comando siguiente como root:

 /sbin/service smb condrestart 

Una recarga manual del archivo smb.conf puede ser útil en caso de que una recarga automática del servicio smb falle. Para asegurarse de que el archivo de configuración del servidor Samba es recargado sin reiniciar el servicio, escriba el comando siguiente como usuario root:

 /sbin/service smb reload 

Por defecto, el servicio vsftpdno se inicia automáticamente al momento del arranque. Para configurar el servicio vsftpd para que se inicie al momento del arranque, utilice una utilidad initscript, tal como /sbin/chkconfig, /sbin/ntsysv o la Herramienta de configuración de servicios. Consulte el Capítulo 16, Control de acceso a servicios para obtener mayor información sobre estas herramientas.

20.6. Tipos de servidores Samba y el archivo smb.conf

La configuración de Samba es bien directa. Todas las modificaciones a Samba se realizan en el archivo de configuración /etc/samba/smb.conf. Aunque el archivo predeterminado smb.conf está bien documentado, no menciona tópicos complejos como LDAP, Active Directory y numerosas implementaciones de controladores de dominio.

Las secciones siguientes describen las diferentes formas en que se puede configurar un servidor Samba. Tenga en cuenta sus necesidades y los cambios requeridos al archivo smb.conf para una configuración exitosa.

20.6.1. Servidor independiente

Un servidor independiente puede ser un servidor de un grupo de trabajo o un miembro de entorno de grupo de trabajo. Un servidor independiente no es un controlador de dominio y no participa en un dominio de ninguna manera. Los ejemplos siguientes incluyen varias configuraciones de seguridad a nivel de recursos compartidos anónimos y una configuración de seguridad a nivel de usuario. Para obtener mayor información sobre los modos de seguridad a nivel de recurso compartido y de usuarios, consulte la Sección 20.7, “Modos de seguridad Samba”.

20.6.1.1. Anónimo de sólo lectura

El archivo smb.conf siguiente muestra una configuración de ejemplo necesaria para compartir recursos de archivos de forma anónima y de sólo lectura. El parámetro security = share hace que el recurso compartido sea anónimo. Observe que los niveles de seguridad para un servidor Samba único no se pueden mezclar. La directriz security es un parámetro Samba global localizado en la sección [global] del archivo de configuración smb.conf.

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV 
security = share  
[data] 
comment = Documentation Samba Server 
path = /export 
read only = Yes 
guest only = Yes

20.6.1.2. Anónimo Lectura/Escritura

El siguiente archivo smb.conf muestra una configuración de muestra necesaria para implementar compartir recursos de archivos de lectura/escritura de forma anónima. Para activar compartir archivos de lectura/escritura anónimos, configure la directriz read only a no. Las directrices force user y force group también se añaden para reforzar la propiedad de cualquier archivo nuevo especificado en el recurso compartido.

Nota

Es posible tener un servidor de lectura/escritura anónimo, pero no es recomendable. Cualquier archivo colocado en el espacio compartido, sin importar el usuario, se le asigna la combinación de usuario/grupo como se especificó para un usuario (force user) y un grupo (force group) genérico en el archivo smb.conf.

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV 
security = share  
[data] 
comment = Data 
path = /export 
force user = docsbot 
force group = users 
read only = No 
guest ok = Yes

20.6.1.3. Servidor de impresión anónimo

El siguiente archivo smb.conf muestra una configuración de muestra necesaria para implementar un servidor de impresión anónimo. Configurando browseable a no como se muestra, no lista la impresora en el Entorno de red. Aunque está oculto para propósitos de navegación, se puede configurar la impresora explícitamente. Al conectar DOCS_SRV usando NetBIOS, el cliente puede tener acceso a la impresora si el cliente también es parte del grupo de trabajo DOCS. También se asume que el cliente tiene el controlador de impresora correcto, pues la directriz de use client driver está configurada a Yes. En este caso, el servidor Samba no tiene responsabilidad de compartir los controladores de impresora con el cliente.

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV 
security = share 
printcap name = cups 
disable spools= Yes 
show add printer wizard = No 
printing = cups  
[printers] 
comment = All Printers 
path = /var/spool/samba 
guest ok = Yes 
printable = Yes 
use client driver = Yes 
browseable = Yes

20.6.1.4. Archivo seguro de lectura/escritura y servidor de impresión

El archivo siguiente smb.conf muestra una configuración de ejemplo necesaria para implementar un servidor de impresión seguro de lectura/escritura. Configurando la directriz security a user obliga a Samba a autenticar las conexiones de clientes. Observe que el recurso compartido [homes] no tiene una directriz force user o force group como si lo tiene el recurso [public]. El recurso compartido [homes] utiliza los detalles del usuario autenticado para cualquier archivo al contrario de force user y force group en [public].

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV 
security = user 
printcap name = cups 
disable spools = Yes 
show add printer wizard = No 
printing = cups  
[homes] 
comment = Home Directories 
valid users = %S 
read only = No 
browseable = No  
[public] 
comment = Data 
path = /export 
force user = docsbot 
force group = users 
guest ok = Yes  
[printers] 
comment = All Printers 
path = /var/spool/samba 
printer admin = john, ed, @admins 
create mask = 0600 
guest ok = Yes 
printable = Yes 
use client driver = Yes 
browseable = Yes

20.6.2. Servidor miembro de dominio

Un miembro de dominio, aunque es similar a un servidor independiente, es conectado a un controlador de dominio (bien sea Windows o Samba) y está sujeto a las reglas de seguridad del dominio. Un ejemplo de un servidor miembro de dominio podría ser un servidor departamental ejecutando Samba que tiene una cuenta de máquina en el Controlador de Dominio Primario (PDC). Todos los clientes del departamento todavía se autentifican con el PDC y se incluyen los perfiles del escritorio y todas los archivos de políticas. La diferencia es que el servidor departamental tiene la habilidad de controlar las impresoras y recursos de red compartidos.

20.6.2.1. Servidor miembro de dominio Active Directory

El archivo siguiente smb.conf muestra una configuración de ejemplo necesaria para implementar un servidor miembro de dominio Active Directory. En este ejemplo, Samba autentifica usuarios para servicios que se ejecutan localmente pero también es un cliente del Active Directory. Asegúrese de que su parámetro realm se muestra en mayúsculas (por ejemplo realm = EXAMPLE.COM). Puesto que Windows 2000/2003 requiere de Kerberos para la autenticación de Active Directory, se requiere de la directriz realm. Si Active Directory y Kerberos se están ejecutando en servidores diferentes, se puede necesitar la directriz password server para ayudar a diferenciar.

[global] 
realm = EXAMPLE.COM 
security = ADS 
encrypt passwords = yes 
# Opcional. Se utiliza si Samba no puede determinar el servidor Kerberos automáticamente. 
password server = kerberos.example.com

Para poder unir un servidor miembro a un dominio de Active Directory, se deben completar los pasos siguientes:

  • Configuración del archivo smb.conf en el servidor miembro

  • Configuración de Kerberos, incluyendo el archivo /etc/krb5.conf file, en el servidor miembro

  • Creación de la cuenta de la máquina en el servidor de dominio Active Directory

  • Asociación del servidor miembro al dominio Active Directory

Para la cuenta de la máquina y unirse al Active Directory de Windows 2000/2003, primero Kerberos se debe inicializar para el servidor miembro que desea unirse al dominio Active Directory. Para crear un tíquet administrativo Kerberos, escriba el comando siguiente como root en el servidor miembro:

kinit administrator@EXAMPLE.COM

Para unir un servidor Active Directory (windows1.example.com), escriba el comando siguiente como root en el servidor miembro:

net ads join -S windows1.example.com -U administrator%password

Puesto que la máquina windows1 se encontró automáticamente en el reino Kerberos correspondiente (el comando kinit fue exitoso), el comando net se conecta al servidor Active Directory usando su cuenta administrativa y contraseña rerquerida. Esto crea la cuenta de la máquina en el Active Directory y otorga los permisos para que el servidor miembro Samba se una al dominio.

Nota

Puesto que se utiliza security = ads y no security = user, no se necesita un motor de contraseñas tal como smbpasswd. Los clientes más viejos que no soportan security = ads son autentificados como si security = domain estuviese configurado. Este cambio no afecta la funcionalidad y permite a los usuarios locales que no se encontraban previamente en el dominio.

20.6.2.2. Servidor miembro de dominio basado en Windows NT4

El archivo smb.conf siguiente muestra una configuración de ejemplo necesaria para implementar un servidor miembro de dominio basado en Windows NT4. Convertirse en un servidor miembro de un dominio basado en Windows NT4 es similar a conectarse a un Active Directory. La principal diferencia es que los dominios basados en Windows NT4 no utilizan Kerberos en su método de autenticación, haciendo que el archivo smb.conf más sencillo. En este caso, el servidor miembro Samba sirve como un pase al servidor de dominio basado en NT4.

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV 
security = domain  
[homes] 
comment = Home Directories 
valid users = %S 
read only = No 
browseable = No  
[public] 
comment = Data 
path = /export 
force user = docsbot 
force group = users 
guest ok = Yes

Tener un servidor miembro Samba puede ser útil en muchas situaciones. Hay veces en donde el servidor Samba puede tener otros usos además de compartir archivos e impresoras. Puede ser útil hacer Samba un servidor miembro de dominio en casos en los que se requiere utilizar aplicaciones puramente Linux en el entorno del dominio. A los administradores les gusta llevar un seguimiento de todas las máquinas en el dominio, aún si no están basadas en Windows. En el caso de que el hardware del servidor basado Windows esté descontinuado, es fácil modificar el archivo smb.conf para convertir el servidor a un PDC basado en Samba. Si los servidores basados en Windows NT son actualizados a Windows 2000/2003, es fácil modificar el archivo smb.conf para incorporar el cambio de infraestructura a un Active Directory si se necesita.

Importante

Despues de configurar el archivo smb.conf, únase al dominio antes de iniciar Samba, escribiendo el comando siguiente como root:

net rpc join -U administrator%password

Observe que la opción -S, que especifica el nombre de host para el servidor de dominio, no necesita especificarse en el comando net rpc join. Samba utiliza el nombre de host especificado por la directriz en el archivo smb.conf en vez de este especificarlo explícitamente.

20.6.3. Domain Controller

Un controlador de dominio en Windows NT es similar funcionalmente a un servidor NIS, Servicio de Información de Red (Network Information Service), en un entorno Linux. Los controladores de dominio y los servidores NIS ambos hospedan bases de datos de información sobre usuarios/grupos así como también servicios relacionados. Los controladores de dominioo son utilizados principalmente por seguridad, incluyendo la autenticación de usuarios accediendo a recursos del dominio. El servicio que mantiene la integridad de la base de datos de usuarios/grupos se llama Administrador de Cuentas de Seguridad (Security Account Manager, SAM). La base de datos SAM es almacenada de forma diferente entre sistemas Windows y sistemas Linux basados en Samba, por lo tanto la replicación SAM no se puede lograr y las plataformas no se pueden mezclar en un entorno PDC/BDC.

En un ambiente Samba, solamente pueden existir un PDC y cero o más BDCs.

Importante

Samba no puede existir en un ambiente controlador de dominios mixto Samba/Windows, (Samba no puede ser un BCD de un PDC de Windows o viceversa). Alternativamente, los PDCs y BDCs de Samba pueden coexistir.

20.6.3.1. Primary Domain Controller (PDC) usando tdbsam

La implementación más simple y común de un PDC Samba utiliza el motor de bases de datos de contraseñas tdbsam. Diseñada para convertirse en el reemplazo del motor smbpasswd, tdbsam tiene varias mejoras que se explican con más detalles en la Sección 20.8, “Bases de datos de información de cuentas Samba”. La directriz passdb backend controla cual motor se utilizará para el PDC.

[global] 
workgroup = DOCS 
netbios name = DOCS_SRV  
passdb backend = tdbsam 
security = user 
add user script = /usr/sbin/useradd -m %u 
delete user script = /usr/sbin/userdel -r %u 
add group script = /usr/sbin/groupadd %g  
delete group script = /usr/sbin/groupdel %g  
add user to group script = /usr/sbin/usermod -G %g %u 
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null  -g machines %u 
# The following specifies the default logon script  
# Per user logon scripts can be specified in the user 
# account using pdbedit logon script = logon.bat 
# This sets the default profile path. 
# Set per user paths with pdbedit 
logon drive = H: 
domain logons = Yes 
os level = 35 
preferred master = Yes 
domain master = Yes  
[homes] 
        comment = Home Directories 
        valid users = %S 
        read only = No  
[netlogon] 
        comment = Network Logon Service 
        path = /var/lib/samba/netlogon/scripts 
        browseable = No         
        read only = No
# For profiles to work, create a user directory under the 
# path shown. mkdir -p /var/lib/samba/profiles/john 
[Profiles] 
        comment = Roaming Profile Share 
        path = /var/lib/samba/profiles 
        read only = No 
        browseable = No 
        guest ok = Yes 
        profile acls = Yes  
# Other resource shares ... ...

Nota

Si necesita más de un controlador de dominios o tiene más de 250 usuarios, no utilice un motor de autenticación tdbsam. En estos casos se recomienda LDAP.

20.6.3.2. Primary Domain Controller (PDC) con Active Directory

Aunque es posible para Samba ser miembro de un Active Directory, no le es posible operar como un controlador de dominio Active Directory

20.7. Modos de seguridad Samba

Solamente hay dos tipos de modos de seguridad para Samba, share-level y user-level, que se conocen de forma colectiva como niveles de seguridad. Solamente se puede implementar la seguridad a nivel de recurso compartido de una forma, mientras que la seguridad a nivel de usuario se puede implementar en una de cuatro formas diferentes. Las diferentes formas de implementar un nivel de seguridad se llama modos de seguridad.

20.7.1. Seguridad a nivel de usuario

La seguridad a nivel de usuario es la configuración predeterminada para Samba. Aún si la directriz security = user no está listada en el archivo smb.conf, es utilizada por Samba. Si el servidor acepta la combinación de nombre de usuario/contraseña del cliente, el cliente puede montar múltiples recursos compartidos sin tener que especificar una contraseña para cada instancia. Samba también puede aceptar solicitudes de nombre de usuario/contraseña basadas en la sesión. El cliente mantiene múltiples contextos de autenticación usando un único UID por cada inicio de sesión.

En smb.conf, la directiva security = user que configura la seguridad a nivel del usuarios es:

[GLOBAL] 
... 
security = user 
...

Las secciones siguientes describen otras implementaciones de seguridad a nivel de usuario.

20.7.1.1. Modo de seguridad de dominio (seguridad a nivel del usuario)

En un modo de seguridad de dominio, el servidor Samba tiene una cuenta de máquina (cuenta confiable de seguridad del dominio) y hace que todas las solicitudes de autenticación se pasen a través de los controladores de dominio. El servidor Samba se convierte en un servidor miembro de dominio usando las directrices siguientes en smb.conf:

[GLOBAL] 
... 
security = domain 
workgroup = MARKETING 
...

20.7.1.2. Modo de seguridad de Active Directory (seguridad a nivel de usuario)

Si tiene un entorno Active Directory, es posible unirse al dominio como un miembro nativo de Active Directory. Aún si una política de seguridad limita el uso de protocolos de autenticación compatibles con NT, el servidor Samba se puede unir al ADS utilizando Kerberos. Samba en un modo de miembro de Active Directory puede aceptar tíquets Kerberos.

En smb.conf, las directivas siguientes hacen a Samba un servidor miembro de Active Directory:

[GLOBAL] 
... 
security = ADS 
realm = EXAMPLE.COM 
password server = kerberos.example.com  
...

20.7.1.3. Modo de seguridad de servidor (seguridad a nivel de usuario)

Se utilizó el modo de seguridad de servidor previamente cuando Samba no fue capaz de actuar como un servidor miembro de dominio.

Nota

Se recomienda que no utilice este modo puesto que existen numerosas desventajas desde el punto de vista de la seguridad.

En smb.conf, las directrices siguientes permiten que Samba opere en modo de seguridad de servidor:

[GLOBAL] 
... 
encrypt passwords = Yes 
security = server 
password server = "NetBIOS_of_Domain_Controller" 
...

20.7.2. Seguridad a nivel de usuarios

Con la seguridad a nivel de recurso compartido o servicio, el servidor acepta solamente una contraseña sin un nombre de usuario explícito desde el cliente. El servidor espera una contraseña para cada recurso compartido, independientemente del nombre de usuario. Han surgido informes recientes de clientes Microsoft Windows con problemas de compatibilidad con servidores de seguridad a nivel de recurso compartido. Los desarrolladores de Samba no recomiendan el uso de la seguridad a este nivel.

En smb.conf, la directiva security = share que configura la seguridad a nivel de directorio compartidos es:

[GLOBAL] 
... 
security = share 
...

20.8. Bases de datos de información de cuentas Samba

La última versión de Samba ofrece varias funcionalidades incluyendo nuevos motores de bases de datos de contraseñas que antes no estaban disponibles. La versión 3.0.0 de Samba es completamente compatible con las versiones anteriores de Samba. Sin embargo, aunque sean compatibles, hay muchos motores que no son convenientes para ser utilizados en producción.

La siguiente es una lista de los diferentes motores que puede utilizar con Samba. Otros motores que no se encuentran listados aquí podrían estar disponibles.

Texto plano

Los motores de texto plano son simplemente motores del tipo /etc/passwd. Con un motor de texto plano, todos los nombres de usuarios y contraseñas son enviados sin encriptar entre el cliente y el servidor Samba. Este método es muy inseguro y no se recomienda su uso de ninguna manera. Es posible que diferentes clientes Windows conectándose al servidor Samba con contraseñas en texto plano no puedan soportar este método de autenticación.

smbpasswd

Un motor popular utilizado en los paquetes previos de Samba, el motor smbpasswd, utiliza un formato de texto ASCII que incluye el MS Windows LanMan y la cuenta NT e información encriptada de contraseñas. Al motor smbpasswd le falta el almacenamiento de los controles extendidos NT/2000/2003 SAM. No se recomienda el motor smbpasswd porque no escala bien ni guarda información de Windows, tal como RIDs para grupos basados en NT. El motor tdbsam resuelve estos problemas para el uso en una base de datos más pequeña (250 usuarios), pero no es una solución de clase empresarial.

ldapsam_compat

El motor ldapsam_compat permite el soporte continuo de OpenLDAP para ser utilizado con las versiones actualizadas de Samba. Esta opción es usada generalmente para la migración a Samba 3.0.

tdbsam

El motor tdbsam proporciona un motor de base de datos ideal para los servidores locales, para servidores que no necesitan una replicación de bases de datos incorporada y para servidores que no requieren la escalabilidad o complejidad de LDAP. El motor tdbsam incluye toda la información de bases de datos de smbpasswd así como también la información SAM anteriormente excluída. La inclusión de los datos extendidos SAM permiten a Samba implementar la misma cuenta y controles de acceso a sistema como se ve en los sistemas basados en Windows NT/2000/2003.

Se recomienda el motor tdbsam para no más de 250 usuarios. Las organizaciones más grandes deberían optar por la integración de Active Directory o LDAP debido a la escabilidad y a posibles consideraciones relacionadas a la infraestructura.

ldapsam

El motor ldapsam proporciona un método óptimo de instalación de cuentas distribuídas para Samba. LDAP es óptimo por su habilidad de replicar su base de datos a cualquier número de servidores usando el demonio de OpenLDAP slurpd. Las bases de datos LDAP son ligeras y escalables, perfectas para la mayoría de las organizaciones, especialmente grandes corporaciones.

Si está realizando una migración desde una versión anterior de Samba a la versión 3.0, tenga en cuenta que el /usr/share/doc/samba-<versión>/LDAP/samba.schema ha cambiado. Este archivo tiene las definiciones de sintaxis de atributos y definiciones objectclass necesarias para que el motor ldapsam funcione apropiadamente.

Si está usando el motor ldapsam para su servidor Samba, deberá configurar slapd para incluir el archivo de esquema. Consulte la Sección 25.5, “El directorio /etc/openldap/schema/ para obtener direcciones sobre cómo llevar a cabo dicha configuración.

Nota

Usted debe tener el paquete openldap-server instalado si desea utilizar el motor ldapsam.

mysqlsam

mysqlsam utiliza un motor de base de datos basado en MySQL. Esto es muy útil para los sitios que ya tienen implementado MySQL. En estos momentos, mysqlsam se encuentra en un módulo diferente de Samba y por tanto no está oficialmente soportado por Samba.

20.9. Navegación de red con Samba

El explorar la red es un concepto que permite a los servidores Windows y Samba aparecer en el Entorno de red de Windows. Dentro del Entorno de red, los iconos son representados como servidores y si se abren, se mostrarán los recursos compartidos disponibles.

Las capacidades de explorar la red requieren NetBIOS sobre TCP/IP. La interconexión basada en NetBIOS utiliza difusión de mensajes (UDP) para lograr la administración de exploración de listas. Sin NetBIOS y WINS como los métodos principales para la resolución TCP/IP de nombres de host, se deben utilizar otros métodos tales como archivos estáticos (/etc/hosts) o DNS.

Un explorador maestro de dominios compagina las listas de exploración desde los navegadores maestros locales en todas las subredes para que se pueda realizar la navegación entre grupos de trabajo y subredes. Preferiblemente, el explorador maestro de dominios debería ser el explorador maestro local para su propia subred.

20.9.1. Navegación de dominios

Por defecto, un PDC servidor de Windows para un dominio es también el navegador maestro de dominio para ese dominio. No se debe configurar un servidor Samba como servidor maestro de dominio en este tipo de situación.

Para las subredes que no incluyen el PDC de Windows, se puede implementar un servidor Samba como un explorador maestro local. Configurando smb.conf para un explorador maestro local (o ningún tipo de navegación) en un entorno de controlador de dominio es lo mismo que la configuración de grupos de trabajo.

20.9.2. WINS (Windows Internetworking Name Server)

Un servidor Samba o un servidor Windows NT pueden funcionar como servidor WINS. Cuando se utiliza un servidor WINS con NetBIOS activado, se pueden enrutar los unicasts UDP lo que permite la resolución de nombres a través de la red. Sin un servidor WINS, la difusión UDP está limitada a la subred local y por lo tanto no tiene que ser enrutada a otras subredes, grupos de trabajo o dominios. Si se necesita la replicación WINS, no utilice Samba como su servidor WINS primario pues actualmente Samba no soporta la replicación WINS.

En un entorno mezclado de servidores NT/2000/2003 y Samba, se recomienda que utilice las capacidades de Microsoft WINS. En un entorno de Samba, se recomienda que utilice solamente un servidor Samba para WINS.

Lo siguiente es un ejemplo de un archivo smb.conf en el cual el servidor Samba está sirviendo como un servidor WINS:

[global] 
wins support = Yes

Sugerencia

Todos los servidores (incluyendo Samba) deberían conectarse a un servidor WINS para resolver los nombres NetBIOS. Sin WINS, la navegación solamente ocurre en la subred local. Más aún, si se obtiene una lista global al dominio, los hosts no se pueden resolver para el cliente sin WINS.

20.10. Samba con soporte para la impresión con CUPS

Samba permite a las máquinas cliente compartir impresoras conectadas al servidor Samba, así como también enviar documentos Linux a las impresoras compartidas Windows. Aunque hay otros sistemas de impresión que funcionan con Red Hat Enterprise Linux, CUPS (Common UNIX Print System) es el sistema de impresión recomendado debido a su integración con Samba.

20.10.1. Configuraciones simples de smb.conf

El ejemplo siguiente muestra una configuración muy básica de smb.conf para el soporte de CUPS:

[global] 
load printers = Yes 
printing = cups 
printcap name = cups  
[printers] 
comment = All Printers 
path = /var/spool/samba/print 
printer = IBMInfoP 
browseable = No 
public = Yes 
guest ok = Yes 
writable = No 
printable = Yes 
printer admin = @ntadmins  
[print$] 
comment = Printer Drivers Share 
path = /var/lib/samba/drivers 
write list = ed, john 
printer admin = ed, john

Se pueden establecer otras configuraciones de impresora. Para añadir seguridad adicional y privacidad para la impresión de documentos confidenciales, los usuarios pueden tener su propio espacio de impresión que no esté en una ruta pública. Si el trabajo falla, otros usuarios no tendrán acceso al archivo.

El recurso print$ contiene los controladores de impresora para que los clientes puedan acceder a ellos si no se encuentran disponibles localmente. El recurso print$ es opcional y puede que no sea requerido dependiendo de la organización.

Configurando browseable a Yes activa que la impresora sea vista en el Entorno de red de Windows, asumiendo que el servidor Samba esté configurado de forma correcta en el dominio/grupo de trabajo.

20.11. Programas de distribución Samba

findsmb

findsmb <subnet_broadcast_address>

El programa es un script de Perl que reporta información sobre los sistemas compatibles con SMB en una subred específica. Si no se especifica ninguna subred, se utilizará la subred local. Los items mostrados incluyen direcciones IP, nombres NetBIOS, nombre de dominio o grupo de trabajo, sistema operativo y versión.

El ejemplo siguiente muestra la salida de la ejecución de findsmb como cualquier usuario válido en un sistema:

findsmb   
IP ADDR       NETBIOS NAME  WORKGROUP/OS/VERSION 
------------------------------------------------------------------ 
10.1.59.25    VERVE         [MYGROUP] [Unix] [Samba 3.0.0-15] 
10.1.59.26    STATION22     [MYGROUP] [Unix] [Samba 3.0.2-7.FC1] 
10.1.56.45    TREK         +[WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager] 
10.1.57.94    PIXEL         [MYGROUP] [Unix] [Samba 3.0.0-15] 
10.1.57.137   MOBILE001     [WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager] 
10.1.57.141   JAWS         +[KWIKIMART] [Unix] [Samba 2.2.7a-security-rollup-fix] 
10.1.56.159   FRED         +[MYGROUP] [Unix] [Samba 3.0.0-14.3E] 
10.1.59.192   LEGION       *[MYGROUP] [Unix] [Samba 2.2.7-security-rollup-fix] 
10.1.56.205   NANCYN       +[MYGROUP] [Unix] [Samba 2.2.7a-security-rollup-fix]

net

net <protocolo> <función> <opciones_misc> <opciones_objetivo>

La utilidad net es similar a la utilidad net utilizada por Windows y MS-DOS. El primer argumento es utilizado para especificar el protocolo utilizado cuando se ejecuta un comando. La opción <protocol> puede ser ads, rap o rpc para especificar el tipo de conexión al servidor. Active Directory utiliza ads, Win9x/NT3 usa rap y Windows NT4/2000/2003 utiliza rpc. Si se omite el protocolo, net intentará determinarlo automáticamente.

El ejemplo siguiente muestra una lista de los directorios compartidos para un host llamado wakko:

net -l share -S wakko 
Password:   

Enumerating shared resources (exports) on remote server:     

Share name   Type     Description 
----------   ----     ----------- 
data         Disk     Wakko data share 
tmp          Disk     Wakko tmp share 
IPC$         IPC      IPC Service (Samba Server) 
ADMIN$       IPC      IPC Service (Samba Server)

El ejemplo siguiente muestra una lista de usuarios Samba para un host llamado wakko:

net -l user -S wakko 
root password:   
User name             Comment 
----------------------------- 
andriusb              Documentation 
joe                   Marketing 
lisa                  Sales

nmblookup

nmblookup <options> <netbios_name>

El programa nmblookup resuelve los nombres NetBIOS en direcciones IP. El programa difunde su consulta en la subred local hasta que las máquina objetivo contesta.

He aquí un ejemplo:

nmblookup trek 
querying trek on 10.1.59.255 
10.1.56.45 trek<00>

pdbedit

pdbedit <options>

El programa pdbedit maneja cuentas ubicadas en la base de datos SAM. Todos los motores son soportados incluyendo smbpasswd, LDAP, NIS+ y la biblioteca de base de datos tdb.

Los siguientes son ejemplos para añadir, eliminar y listar usuarios:

pdbedit -a kristin 
new password: 
retype new password: 
Unix username:        kristin 
NT username: 
Account Flags:        [U          ] 
User SID:             S-1-5-21-1210235352-3804200048-1474496110-2012 
Primary Group SID:    S-1-5-21-1210235352-3804200048-1474496110-2077 
Full Name: Home Directory:       \\wakko\kristin 
HomeDir Drive: 
Logon Script: 
Profile Path:         \\wakko\kristin\profile 
Domain:               WAKKO 
Account desc: 
Workstations: Munged 
dial: 
Logon time:           0 
Logoff time:          Mon, 18 Jan 2038 22:14:07 GMT 
Kickoff time:         Mon, 18 Jan 2038 22:14:07 GMT 
Password last set:    Thu, 29 Jan 2004 08:29:28 
GMT Password can change:  Thu, 29 Jan 2004 08:29:28 GMT 
Password must change: Mon, 18 Jan 2038 22:14:07 GMT  pdbedit -v -L kristin 
Unix username:        kristin 
NT username: 
Account Flags:        [U          ] 
User SID:             S-1-5-21-1210235352-3804200048-1474496110-2012 
Primary Group SID:    S-1-5-21-1210235352-3804200048-1474496110-2077 
Full Name: 
Home Directory:       \\wakko\kristin 
HomeDir Drive: 
Logon Script: 
Profile Path:         \\wakko\kristin\profile 
Domain:               WAKKO 
Account desc: 
Workstations: Munged 
dial: 
Logon time:           0 
Logoff time:          Mon, 18 Jan 2038 22:14:07 GMT 
Kickoff time:         Mon, 18 Jan 2038 22:14:07 GMT 
Password last set:    Thu, 29 Jan 2004 08:29:28 GMT 
Password can change:  Thu, 29 Jan 2004 08:29:28 GMT 
Password must change: Mon, 18 Jan 2038 22:14:07 GMT  pdbedit -L 
andriusb:505: 
joe:503: 
lisa:504: 
kristin:506:  pdbedit -x joe  pdbedit -L 

andriusb:505: lisa:504: kristin:506:

rpcclient

rpcclient <server> <options>

El programa rpcclient ejecuta comandos administrativos usando Microsoft RPCs, el cual proporciona acceso a la interfaz de administración gráfica del usuario Windows (GUIs) para la administración de sistemas. Usualmente es utilizado por los usuarios más avanzados que entienden la complejidad de Microsoft RPCs.

smbcacls

smbcacls <//server/share> <filename> <options>

El programa smbcacls modifica las ACLs de Windows en archivos y directorios compartidos por el servidor Samba.

smbclient

smbclient <//server/share> <password> <options>

El programa smbclient es un cliente UNIX versátil que proporciona una funcionalidad similar a ftp.

smbcontrol

smbcontrol -i <options>

smbcontrol <options> <destination> <messagetype> <parameters>

El programa smbcontrol envía mensajes de control para demonios en ejecución smbd o nmbd. Al ejecutar smbcontrol -i corre de forma interactiva hasta que se introduce una línea en blanco o una 'q'.

smbpasswd

smbpasswd <options> <username> <password>

El programa smbpasswd maneja las contraseñas encriptadas. Este programa lo puede ejecutar el superusuario para cambiar cualquier contraseña de usuarios así como también por un usuario normal para cambiar su propia contraseña Samba.

smbspool

smbspool <job> <user> <title> <copies> <options> <filename>

El programa smbspool es una intefaz de impresión compatible con CUPS a Samba. Aunque está diseñada para utilizarse con impresoras CUPS, smbspool también puede trabajar con impresoras no CUPS.

smbstatus

smbstatus <options>

El programa smbstatus muestra el estado de las conexiones actuales a un servidor Samba.

smbtar

smbtar <options>

El programa smbtar realiza respaldos y restauraciones de archivos y directorios compartidos basados en Windows a un archivo de cinta local. A pesar de que es similar al comando tar, estos dos no son compatibles.

testparm

testparm <options> <filename> <hostname IP_address>

El programa testparm verifica la sintaxis del archivo smb.conf. Si su archivo smb.conf está en la ubicación predeterminada (/etc/samba/smb.conf) no necesita especificar la ubicación. Al especificar el nombre de host y la dirección IP al programa testparm este verifica que los archivos hosts.allow y host.deny estén correctamente configurados. El programa testparm también muestra un resúmen de su archivo smb.conf y el papel del servidor (independiente, dominio, etc.) después de la prueba. Esto es conveniente cuando se hace depuraciones pues excluye los comentarios y presenta la información de forma concisa para que la lean los administradores.

Por ejemplo:

testparm 
Load smb config files from /etc/samba/smb.conf 
Processing section "[homes]" 
Processing section "[printers]" 
Processing section "[tmp]" 
Processing section "[html]" 
Loaded services file OK. 
Server role: ROLE_STANDALONE 
Press enter to see a dump of your service definitions <enter> 
# Parámetros globales 
[global]
        workgroup = MYGROUP         
        server string = Samba Server         
        security = SHARE         
        log file = /var/log/samba/%m.log         
        max log size = 50         
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192         
        dns proxy = No   
[homes]         
        comment = Home Directories         
        read only = No         
        browseable = No   
[printers]         
        comment = All Printers         
        path = /var/spool/samba         
        printable = Yes         
        browseable = No   
[tmp]         
        comment = Wakko tmp         
        path = /tmp         
        guest only = Yes   
[html]         
        comment = Wakko www         
        path = /var/www/html         
        force user = andriusb         
        force group = users         
        read only = No         
        guest only = Yes

wbinfo

wbinfo <options>

El programa wbinfo muestra información desde el demonio winbindd. El demonio winbindd debe estar ejecutándose para que wbinfo funcione.

20.12. Recursos adicionales

Las secciones siguientes proporcionan formas de explorar Samba en más detalles.

20.12.1. Documentación instalada

  • /usr/share/doc/samba-<número-versión>/ — Todos los archivos adicionales incluídos con la distribución Samba. Esto incluye todos los scripts de ayuda, archivos de configuración de ejemplo y documentación.

    Este directorio también contiene las versiones en línea de The Official Samba-3 HOWTO-Collection y Samba-3 by Example, los cuales están situados posteriormente.

20.12.2. Libros relacionados

  • The Official Samba-3 HOWTO-Collection por John H. Terpstra y Jelmer R. Vernooij; Prentice Hall — La documentación oficial de Samba-3 lanzada por el equipo de desarrollo de Samba. Este es más un manual de referencia que una guía paso-a-paso.

  • Samba-3 by Example por John H. Terpstra; Prentice Hall — Este es otro lanzamiento oficial del equipo de desarrollo de Samba en el que se discuten ejemplos detallados de OpenLDAP, DNS, DHCP y archivos de configuración de impresión. Tiene información relacionada paso a paso que es de ayuda en las implementaciones del mundo real.

  • Using Samba, 2nd Edition por Jay T's, Robert Eckstein, y David Collier-Brown; O'Reilly — Una buena fuente para los usuarios novatos a avanzados, que incluye material de referencia bastante completo.

20.12.3. Sitios web útiles

  • http://www.samba.org/ — Página principal de la distribución Samba y toda la información oficial creada por el grupo de desarrollo de Samba. Están disponibles muchos recursos en formatos HTML y PDF, mientras que otros solamente están disponibles para la compra. Aunque muchos de estos enlaces no son específicos para Red Hat Enterprise Linux, algunos conceptos son aplicables.

  • http://samba.org/samba/archives.html — Listas de correo activas para la comunidad Samba. Se recomienda habilitar el modo en resúmen o digest debido a la gran actividad de la lista.

  • Grupos de noticias Samba — También están disponibles los grupos de discusión Samba, tales como gmane.org, que utilizan el protocolo NNTP. Esto es una alternativa a recibir mensajes desde listas de correo.

  • http://samba.idealx.org/ — Idealx.org distribuye scripts de instalación y configuración para la integración de Samba y OpenLDAP. Estos son muy recomendados para asistir en la administración de recursos relacionados a LDAP. Los scripts se pueden encontrar en /usr/share/doc/samba-número-version/LDAP/smbldap-tools o descargarlos desde el sitio web de Idealx.

Capítulo 21. Protocolo de Configuración Dinámica de Hosts (DHCP)

DHCP (Dynamic Host Configuration Protocol) es un protocolo de red para asignar automáticamente información TCP/IP a equipos cliente. Cada cliente DHCP se conecta a un servidor DHCP centralizado que devuelve la configuración de red del cliente (incluyendo la dirección IP, la puerta de enlace y los servidores DNS).

21.1. Motivos para usar el protocolo DHCP

DHCP es útil para proporcionar de un modo rápido la configuración de la interfaz de red del cliente. Al configurar el sistema cliente, el administrador puede seleccionar el protocolo DHCP y no especificar una dirección IP, una máscara de red, una puerta de enlace o servidores DNS. El cliente recupera esta información desde el servidor DHCP. DHCP también es útil si un administrador desea cambiar las direcciones IP de muchos sistemas. En lugar de volver a configurar todos los sistemas, puede modificar un archivo de configuración DHCP en el servidor para establecer el nuevo conjunto de direcciones IP. Si los servidores DNS de una organización cambian, los cambios son hechos en el servidor DHCP, no en los clientes DHCP. Una vez que se reinicie la red en los clientes (o se reinicien los clientes), se aplicarán los cambios.

Si una organización tiene un servidor DHCP funcional conectado correctamente a una red, los usuarios de portátiles pueden mover estas máquinas de oficina a oficina.

21.2. Configuración de un servidor DHCP

Para configurar un servidor DHCP se debe crear el archivo de configuración dhcpd.conf en el directorio /etc/. Se puede encontrar un archivo de ejemplo en /usr/share/doc/dhcp-<version>/dhcpd.conf.sample.

DHCP también usa el archivo /var/lib/dhcp/dhcpd.leases para almacenar la base de datos de arrendamiento de clientes. Consulte la Sección 21.2.2, “Base de datos de arrendamiento” para más información.

21.2.1. Archivo de configuración

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.

El archivo de configuración puede contener tabulaciones o líneas en blanco adicionales para facilitar el formato. Las palabras clave no distinguen entre mayúsculas y minúsculas. Las líneas que empiezan con una almohadilla o símbolo numeral (#) se consideran comentarios.

Hay dos tipos de esquemas de actualización DNS implementados actualmente — el modo de actualización DNS ad-hoc y el modo de actualización intermedio de boceto de interacción DHCP-DNS. Si y cuando estos dos son aceptados como parte del proceso estándar de IETF, habrá un tercer modo — el método estándar de actualización DNS. El servidor DHCP tiene que estar configurado para usar uno de estos dos esquemas actuales. La versión 3.0b2pl11 y las versiones anteriores usaban el modo ad-hoc, el cual no es utilizado en la actualidad. Si quiere conservar el mismo comportamiento, añada la siguiente línea al inicio del archivo de configuración:

ddns-update-style ad-hoc;

Para usar el modo recomendado, añada la siguiente línea al inicio del archivo de configuración:

ddns-update-style interim;

Lea la página man de dhcpd.conf para más detalles sobre los diferentes modos.

El archivo de configuración posee dos tipos de información:

  • Parámetros — establece cómo se realiza una tarea, si ésta se debe llevar a cabo o las opciones de configuración de red que se enviarán al cliente.

  • Declaraciones — describen la topología de la red, describen los clientes, proporcionan direcciones para los clientes o aplican un grupo de parámetros a un grupo de declaraciones.

Los parámetros que inician con la palabra clave option son conocidos como opciones. Estas opciones controlan las opciones de DHCP mientras que los parámetros configuran valores que no son opcionales o que controlan el comportamiento del servidor DHCP.

Los parámetros (incluidas las opciones) declarados antes de una sección encerrada entre paréntesis ({ }) se consideran parámetros globales. Los parámetros globales se aplican a todas las secciones situadas debajo de ellos.

Importante

Si cambia el archivo de configuración, los cambios no se aplicarán hasta reiniciar el demonio DHCP con el comando service dhcpd restart.

Sugerencia

En vez de cambiar un archivo de configuración DHCP y reiniciar el equipo cada vez, el comando omshell proporciona una manera interactiva de conectarse, preguntar y cambiar la configuración de un servidor DHCP. Al utilizar omshell, todos los cambios pueden realizarse mientras el servidor está en ejecución. Para obtener mayor información sobre omshell, consulte la página man omshell.

En el Ejemplo 21.1, “Ejemplo de declaración de Subred”, las opciones routers, subnet-mask, domain-name, domain-name-servers, y time-offset son usadas para cualquier sentencia host declarada debajo de ellas.

Adicionalmente, se puede declarar una subnet. Debe incluir una declaración subnet para cada subred en la red. Si no lo hace, el servidor DHCP no podrá ser iniciado.

En este ejemplo, hay opciones globales para cada cliente DHCP en la subred y un range declarado. A los clientes se les asigna una dirección IP dentro del range.

subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;

        option domain-name              "example.com";
        option domain-name-servers       192.168.1.1;

        option time-offset              -18000;     # Eastern Standard Time

        range 192.168.1.10 192.168.1.100;
}
Ejemplo 21.1. Ejemplo de declaración de Subred

Todas las subredes que comparten la misma red física deben especificarse dentro de una declaración shared-network como se muestra en el Ejemplo 21.2, “Ejemplo de declaración de red compartida”. Los parámetros dentro de shared-network pero fuera del cerco de las declaraciones subnet se consideran parámetros globales. El nombre de shared-network debe ser el título descriptivo de la red, como, por ejemplo, test-lab, para describir todas las subredes en un entorno de laboratorio de pruebas.

shared-network name {
    option domain-name              "test.redhat.com";
    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;
    option routers                  192.168.0.254;
    more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}
Ejemplo 21.2. Ejemplo de declaración de red compartida

Como se muestra en el Ejemplo 21.3, “Declaración de Group”, la declaración group puede utilizarse para aplicar parámetros globales a un grupo de declaraciones. Por ejemplo, puede agrupar redes compartidas, subredes, hosts u otros grupos.

group {
   option routers                  192.168.1.254;
   option subnet-mask              255.255.255.0;

   option domain-name              "example.com";
   option domain-name-servers       192.168.1.1;

   option time-offset              -18000;     # Eastern Standard Time

   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA; 
      fixed-address 192.168.1.4;
   }

   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}
Ejemplo 21.3. Declaración de Group

Para configurar un servidor DHCP que arrienda una dirección IP dinámica a un sistema dentro de una subred, modifique el Ejemplo 21.4, “Parámetro Range (Rango)” con sus valores. Así se declara un tiempo de arrendamiento por defecto, un tiempo de arrendamiento máximo y los valores de configuración de red para los clientes. Este ejemplo asigna una dirección IP en el range 192.168.1.10 y 192.168.1.100 a los sistemas clientes.

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}
Ejemplo 21.4. Parámetro Range (Rango)

Para asignar una dirección IP a un cliente según la dirección MAC de la tarjeta de interfaz de red, use el parámetro hardware ethernet dentro de la declaración host. Como se muestra en el Ejemplo 21.5, “Ejemplo de dirección IP estática con DHCP”, la declaración host apex especifica que la interfaz de red con una dirección MAC 00:A0:78:8E:9E:AA siempre recibe la dirección IP 192.168.1.4.

Tenga en cuenta que también puede usar el parámetro opcional host-name para asignar un nombre host al cliente.

host apex {
   option host-name "apex.example.com";
   hardware ethernet 00:A0:78:8E:9E:AA; 
   fixed-address 192.168.1.4;
}
Ejemplo 21.5. Ejemplo de dirección IP estática con DHCP

Sugerencia

Puede usar el archivo de configuración de ejemplo proporcionado como punto de partida y, a continuación, agregarle opciones de configuración personalizadas. Para copiar el archivo en la ubicación adecuada, use el comando

cp /usr/share/doc/dhcp-<version-number>/dhcpd.conf.sample /etc/dhcpd.conf

(donde <version-number> es la versión de DHCP que está usando).

Para obtener una lista completa de sentencias de opciones e información relacionada, consulte la página del manual de dhcp-options.

21.2.2. Base de datos de arrendamiento

En el servidor DHCP, el archivo /var/lib/dhcp/dhcpd.leases almacena la base de datos de arrendamiento del cliente DHCP. Este archivo no debe modificarse manualmente. La información sobre arrendamiento de DHCP de cada dirección IP asignada recientemente se almacena de modo automático en la base de datos de arrendamiento. La información incluye la longitud del arrendamiento, a quién se ha asignado la dirección IP, las fechas iniciales y finales de la renta y la dirección MAC de la tarjeta de interfaz de red utilizada para recuperar el arrendamiento.

Todas las horas de la base de datos de arrendamiento se expresan según el Tiempo Universal Coordinado (UTC por sus siglas en inglés), no con la hora local.

Cada cierto tiempo, la base de datos de arrendamiento es nuevamente creada para controlar su tamaño. En primer lugar, se guardan todas las concesiones conocidas en una base de datos de renta temporal. El archivo dhcpd.leases es renombrado a dhcpd.leases~ y la base de datos temporal se registra en dhcpd.leases.

El demonio DHCP podría ser terminado o el sistema puede fallar después de que la base de datos ha sido renombrada al archivo de copia de seguridad pero antes de que el nuevo archivo haya sido escrito. Si ocurre esto, el archivo dhcpd.leases no existirá a pesar de ser requerido para arrancar el servicio. No cree un nuevo archivo de arrendamiento si esto ocurre. Si lo hace, se perderán las versiones anteriores del arrendamiento y podrían generarse muchos problemas. La solución correcta consiste en cambiar el nombre del archivo de copia de seguridad dhcpd.leases~ de nuevo a dhcpd.leases y, a continuación, arrancar el demonio.

21.2.3. Iniciar y detener el servidor

Importante

Cuando el servidor DHCP arranca por primera vez, fallará si no existe un archivo dhcpd.leases. Use el comando touch /var/lib/dhcp/dhcpd.leases para crear el archivo en caso de que no exista.

Si el mismo servidor está utilizando BIND con servidor DNS, este paso no será necesario, ya que al iniciar el servicio named se revisa automáticamente la existencia del archivo dhcpd.leases.

Para arrancar el servicio DHCP, use el comando /sbin/service dhcpd start. Para detener el servidor DHCP, use el comando /sbin/service dhcpd stop.

Si tiene más de una interfaz de red conectada al sistema, pero sólo desea que el servidor DHCP arranque en una de las interfaces, puede configurar el servidor DHCP para que sólo arranque en ese dispositivo. En /etc/sysconfig/dhcpd, agregue el nombre de la interfaz a la lista de DHCPDARGS:

# Opciones de línea de comandos
DHCPDARGS=eth0

Esto es útil si tiene una máquina cortafuegos con dos tarjetas de red. Se puede configurar una tarjeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra tarjeta de red puede utilizarse como servidor DHCP para la red interna detrás del cortafuegos. Su sistema será más seguro si sólo especifica la tarjeta de red conectada a la red interna ya que los usuarios no pueden conectarse al demonio vía Internet.

Otras opciones de línea de comandos que pueden ser especificadas en /etc/sysconfig/dhcpd incluyen:

  • -p<portnum> — Especifique el número de puerto UDP en el cual dhcpd debería escuchar. El puerto predeterminado es el 67. El servidor DHCP transmite las respuestas al cliente DHCP a un puerto con un número más grande que el puerto UDP especificado. Por ejemplo, si se usa el puerto predeterminado, el servidor escucha peticiones en el puerto 67 y responde al cliente en el puerto 68. Si especifica un puerto en este momento y usa el agente de transmisión DHCP, se debería especificar el mismo puerto en el que el agente DHCP debería escuchar. Consulte la Sección 21.2.4, “Agente de transmisión DHCP” para más detalles.

  • -f — Ejecuta el demonio como un proceso en primer plano. Casi siempre se usa para la depuración.

  • -d — Registra el demonio del servidor DCHP en el descriptor de errores estándar. Casi siempre se usa para el depurado. Si no está especificado, el registro será escrito en /var/log/messages.

  • -cf <filename> — Especifica la localización del archivo de configuración. La ubicación por defecto es /etc/dhcpd.conf.

  • -lf <filename> — Especifica la ubicación de la base de datos de arrendamiento. Si ya existe el archivo de la base de datos de arrendamiento, es muy importante que el mismo archivo sea usado cada vez que el servidor DHCP se inicia. Se le recomienda que use esta opción sólo para propósitos de depuración en máquinas que no estén en producción. La ubicación por defecto es /var/lib/dhcp/dhcpd.leases.

  • -q — No imprima el mensaje de copyright entero cuando inicie el demonio.

21.2.4. Agente de transmisión DHCP

El Agente de transmisión DHCP (dhcrelay) le permite transmitir las peticiones DHCP y BOOTP desde una subred sin un servidor DHCP a uno o más servidores DHCP en otras subredes.

Cuando un cliente DHCP pide información, el agente de transmisión DHCP reenvía la petición a la lista de servidores DHCP especificada cuando se inicia el agente de transmisión DHCP. Cuando un servidor DHCP devuelve una respuesta, la respuesta puede ser broadcast o unicast en la red que ha enviado la petición original.

El agente de transmisión escucha las peticiones DHCP en todas las interfaces a menos que las interfaces estén especificadas en /etc/sysconfig/dhcrelay con la directiva INTERFACES.

Para iniciar el agente de transmisión DHCP, use el comando service dhcrelay start.

21.3. Configuración de un cliente DHCP

Para configurar un cliente DHCP manualmente, debe modificar el archivo /etc/sysconfig/network para habilitar redes y el uso del archivo de configuración para cada dispositivo de red en el directorio /etc/sysconfig/network-scripts. En este directorio, cada dispositivo debería tener un archivo de configuración llamado ifcfg-eth0 donde eth0 es el nombre del dispositivo de red.

El archivo /etc/sysconfig/network debería contener la línea siguiente:

NETWORKING=yes

Si quiere que se inicie la red en el momento de arranque debe asegurarse de que la variable NETWORKING sea yes.

El archivo /etc/sysconfig/network-scripts/ifcfg-eth0 debería contener las líneas siguientes:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

Necesita un archivo de configuración para cada dispositivo que desee configurar para el uso de DHCP.

Otras opciones para el script de la red incluyen:

  • DHCP_HOSTNAME — Utilice esta opción solamente si el servidor DHCP requiere que el cliente especifique un nombre de host antes de recibir una dirección IP. (El demonio del servidor DHCP en Red Hat Enterprise Linux no soporta esta característica.)

  • PEERDNS=<answer>, donde <answer> es uno de los siguientes:

    • yes — Modifica /etc/resolv.conf con información desde el servidor. Si se está usando DHCP, entonces yes es el valor por defecto.

    • no — No modifica /etc/resolv.conf.

  • SRCADDR=<address>, donde <address> es la dirección IP fuente especificada para los paquetes salientes.

  • USERCTL=<answer>, donde <answer> es uno de los siguientes:

    • yes — Los usuarios que no sean root pueden modificar este dispositivo.

    • no — Los usuarios no root no tienen derecho a controlar este dispositivo.

Si prefiere usar una interfaz gráfica, consulte el Capítulo 15, Configuración de la red para obtener más información sobre la Herramienta de administración de red para configurar la interfaz de red para usar DHCP.

Sugerencia

Para configurar opciones avanzadas de clientes DHCP tal como tiempo del protocolo, requerimientos y peticiones de asignación, soporte dinámico DNS, aliases y una amplia gama de valores para sobreescribir o añadir a la configuración del lado del cliente, consulte dhclient y las páginas man de dhclient.conf

21.4. Recursos adicionales

Para obtener mayor información sobre otras opciones, consulte los recursos siguientes.

21.4.1. Documentación instalada

  • La página del manual dhcpd — describe cómo funciona el demonio DHCP

  • La página del manual dhcpd.conf — explica cómo configurar el archivo de configuración de DHCP; incluye algunos ejemplos.

  • La página del manual dhcpd.leases — explica cómo configurar el archivo de arrendamiento DHCP; incluye también algunos ejemplos.

  • La página del manual dhcp-options — explica la sintaxis para la declaración de opciones DHCP en dhcpd.conf; incluye ejemplos.

  • La página del manual dhcrelay — explica el Agente de transmisión DHCP y sus opciones de configuración.

  • /usr/share/doc/dhcp-<version>/ — Contiene archivos de ejemplo, archivos README y las notas de lanzamiento para la versión específica del servicio DHCP.

Capítulo 22. Servidor HTTP Apache

El Servidor HTTP Apache es un servidor Web de tecnología Open Source sólido y para uso comercial desarrollado por Apache Software Foundation (http://www.apache.org/). Red Hat Enterprise Linux incluye el Servidor HTTP Apache versión 2.2 así como también una serie de módulos de servidor diseñados para mejorar su funcionalidad.

El archivo de configuración predeterminado instalado en el Servidor HTTP Apache funciona sin necesidad de modificarlo, en la mayor parte de los casos. Este capítulo da una idea general de las directrices dentro de este archivo de configuración (/etc/httpd/conf/httpd.conf) para ayudar a aquellos que requieren una configuración personalizada o que necesitan convertir un archivo de configuración del formato más antiguo del Servidor HTTP Apache versión 1.3.

Advertencia

Si utiliza la Herramienta de configuración HTTP (system-config-httpd ), no cambie el archivo de configuración del Servidor Apache HTTP manualmente porque la Herramienta de configuración HTTP vuelve a generar este archivo cada vez que se usa.

22.1. Servidor HTTP Apache Versión 2.2

Existen diferencias importantes entre el Servidor HTTP Apache Versión 2.2 y la versión 2.0 (la versión 2.0 incluida con Red Hat Enterprise Linux 4 y las versiones anteriores). Esta sección revisa algunas de las características del Servidor HTTP Apache Versión 2.2 y esboza los cambios principales. Si necesita actualizar desde la versión 1.3 también debe leer las instrucciones sobre como migrar desde la versión 1.3 a la 2.0. Para obtener las instrucciones sobre como migrar un archivo de configuración versión 1.3 al formato 2.0 refiérase a Sección 22.2.2, “Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0”.

22.1.1. Características del Servidor HTTP Apache Versión 2.2

El Servidor HTTP Apache Versión 2.2 presenta las siguientes mejoras sobre las versión 2.0:

  • Módulos de cacheo mejorados (mod_cache, mod_disk_cache, mod_mem_cache).

  • Una nueva estructura para el soporte de autenticación y autorización que remplaza los módulos de autenticación proporcionados en las versiones anteriores.

  • Soporte para balanceo de carga proxy (mod_proxy_balancer)

  • soporte para manejo de archivos grandes (más grandes de 2 GB) en plataformas de 32 bits.

Se han realizado los siguientes cambios a la configuración httpd predeterminada:

  • Los módulos mod_cern_meta y mod_asis ya no se cargan por defecto.

  • Ahora el módulo mod_ext_filter se carga por defecto.

Si actualiza desde un lanzamiento previo de Red Hat Enterprise Linux, la configuración httpd necesitará actualizarse para httpd 2.2. Para obtener más información refiérase a http://httpd.apache.org/docs/2.2/upgrading.html.

22.2. Migración de los Archivos de Configuración del Servidor HTTP Apache

22.2.1. Migración de los Archivos de Configuración del Servidor HTTP Apache Versión 2.0.

Esta sección esboza la migración desde la versión 2.0 a la 2.2. Si está migrando desde la versión 1.3 por favor refiérase a Sección 22.2.2, “Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0”.

  • Los archivos de configuración y los scripts de inicialización de la versión 2.0 necesitan ajustes mínimos particularmente en los nombres de los módulos los cuales pueden haber cambiado. Los módulos de terceros que servían en la versión 2.0 también sirven en la versión 2.2 pero necesitan ser recompilados antes de que los cargue. Los módulos claves que se deben observar son los módulos de autenticación y autorización. Para cada unos de los módulos que ha sido renombrado será necesario actualizar la línea LoadModule.

  • El módulo mod_userdir sólamente actuará bajo pedidos si proporciona una directiva UserDir indicando un nombre de directorio. Si desea mantener los procedimientos utilizados en la versión 2.0 añada la directiva UserDir public_html en su archivo de configuración.

  • Para habilitar SSL, edite el archivo httpd.conf añadiendo las directivas necesarias mod_ssl. Utilice apachectl start ya que apachectl startssl no se encuentra disponible en la versión 2.2. Puede ver un ejemplo de la configuración SSL para httpd en conf/extra/httpd-ssl.conf.

  • Para probar su configuración se le aconseja que utilice service httpd configtest la cual detectará errores de configuración.

Para obtener más información sobre como actualizar desde la versión 2.0 a la 2.2 puede ir a http://httpd.apache.org/docs/2.2/upgrading.html.

22.2.2. Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0

Esta sección detalla la migración de un archivo de configuración del Servidor HTTP Apache versión 1.3 para el Servidor HTTP Apache versión 2.0 lo pueda utilizar.

Si está actualizando a Red Hat Enterprise Linux 5 desde Red Hat Enterprise Linux 2.1 tenga en cuenta que el nuevo archivo de configuración para el paquete del Servidor HTTP Apache versión 2.0 es instalado como /etc/httpd/conf/httpd.conf.rpmnew y no se toca la versión original 1.3 httpd.conf. Depende absolutamente de usted si decide utilizar el nuevo archivo de configuración y migrar los viejos cambios o si utilizar el archivo ya existente como base y modificarlo para que se adapte; sin embargo, algunas partes del archivo se han cambiado más que otras y lo mejor es llegar a un punto intermedio. Los archivos de configuración para ambas versiones la 1.3 y la 2.0 están dividos en tres secciones.

Si el archivo /etc/httpd/conf/httpd.conf es una versión modificada de la versión por defecto recién instalada y ha guardado una copia del original, entonces le será más fácil invocar el comando diff, como se muestra a continuación (conectándose como root):

diff -u httpd.conf.orig httpd.conf | less

Este comando subraya los cambios realizados. Si no tiene una copia del archivo original, cójalo del paquete RPM usando los comandos rpm2cpio y cpio, como en el ejemplo siguiente:

rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make

En el comando de arriba, sustituya <version-number> con el número de versión para el paquete apache.

Finalmente, es útil saber que el Servidor HTTP Apache tiene un modo de prueba para verificar si hay errores en la configuración. Para ello, escriba el siguiente comando:

apachectl configtest

22.2.2.1. Configuración del entorno a nivel global

La sección del entorno global del archivo de configuración contiene directrices que afectan la operación general del Servidor HTTP Apache como por ejemplo el número de peticiones que puede manejar al mismo tiempo y la ubicación de varios archivos que usa. Esta sección requiere un gran número de cambios y por ello se recomienda que base esta sección en el archivo de configuración del Servidor HTTP Apache versión 2.0 y que migre sus configuraciones anteriores a este.

22.2.2.1.1. Interfaces y vinculación de puertos

Ya no existen las directrices BindAddress y Port; porque quedan recogidas en la directriz Listen.

Si tenía configurado el Puerto 80 en el archivo de configuración de la versión 1.3, debe cambiarlo a Listen 80 en el archivo de configuración 2.0. Si el valor del Puerto estaba configurado a un valor diferente que 80, tiene que poner el número del puerto a los contenidos de la directriz ServerName.

Por ejemplo, el siguiente es un ejemplo de la directtriz de Servidor HTTP Apache de la versión 1.3:

Port 123 ServerName www.example.com

Para migrar esta configuración al Servidor HTTP Apache versión 2.0 utilice la siguiente estructura:

Listen 123 ServerName www.example.com:123

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.1.2. Regulación del tamaño del pool de servidores

Cuando el Servidor HTTP Apache acepta peticiones, este despacha procesos hijo o hilos para que los manejen. Este grupo de procesos o hilos es conocido como un pool de servidores. Bajo el Servidor HTTP Apache versión 2.0 se ha abstraído la responsabilidad de crear y mantener estos pool de servidores a un grupo de módulos llamados Módulos de Procesos Múltiples (MPMs). A diferencia de otros módulos, el Servidor HTTP Apache sólamente puede cargar un módulo del grupo MPM. Hay tres módulos MPM incluidos con la versión 2.0: prefork, worker, y perchild. Actualmente, únicamente están disponibles los MPMs prefork y worker, aunque el MPM perchild estará disponible más adelante.

El comportamiento del Servidor HTTP Apache 1.3 original ha sido movido al MPM prefork. El MPM prefork acepta las mismas directrices que el Servidor HTTP Apache versión 1.3 por tanto, las siguientes directrices se pueden migrar directamente:

  • StartServers

  • MinSpareServers

  • MaxSpareServers

  • MaxClients

  • MaxRequestsPerChild

El MPM worker implementa un servidor multi-proceso y multi-hilos proporcionando una mayor escalabilidad. Cuando este utilizando este MPM, los hilos manejan las peticiones conservando recursos del sistema y permitiendo servir a grandes números de peticiones de manera eficiente. Aún cuando algunas de las directrices aceptadas por el MPM worker son las mismas que aquellas aceptadas por el MPM prefork los valores para esas directrices no deberían ser transferidos directamente desde una instalación del Servidor HTTP Apache versión 1.3. Es mejor utilizar los valores por defecto como una guía y luego experimentar para determinar los valores que funcionan mejor.

Importante

Para utilizar el MPM worker, cree el archivo /etc/sysconfig/httpd y añada la directriz siguiente:

HTTPD=/usr/sbin/httpd.worker

Para mayor información sobre el tema de MPMs, consulte la documentación siguiente en el sitio web de la Apache Software Foundation:

22.2.2.1.3. Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)

Se tienen que realizar muchos cambios aquí, por eso se recomienda que para modificar la configuración del Servidor HTTP Apache 1.3 para adaptarse a la versión 2.0 (al contrario de migrar los cambios en la configuración de la versión 2.0) copie esta sección del archivo de configuración del Servidor HTTP Apache 2.0.

Aquellos que no deseen copiar la sección desde la configuración del Servidor HTTP Apache versión 2.0 deberían tomar en cuenta lo siguiente:

  • Las directrices AddModule y ClearModuleList ya no existen. Estas directrices eran usadas para asegurarse de que se pudiesen activar los módulos en el orden correcto. El Servidor HTTP Apache versión 2.0 permite a los módulos especificar su orden, eliminando la necesidad de estas dos directrices.

  • El orden de las líneas LoadModule ya no es relevante en la mayoría de los casos.

  • Se han añadido muchos módulos, otros han sido eliminados, renombrado, dividido o incorporados con otros.

  • Ya no son necesarias las líneas LoadModule para los módulos empaquetados en sus propios RPMs (mod_ssl, php, mod_perl y similares) ya que se pueden encontrar en sus archivos relevantes dentro del directorio /etc/httpd/conf.d/.

  • Las definiciones HAVE_XXX ya no existen.

Importante

Si se está modificando el archivo original, por favor tenga en cuenta que es de suma importancia que httpd.conf contenga la directriz siguiente:

Include conf.d/*.conf

La omisión de esta directriz podría resultar en la falla de todos los módulos enpaquetados en sus propios RPMs (tales como mod_perl, php y mod_ssl).

22.2.2.1.4. Otros cambios en el entorno global

Se han eliminado las siguientes directrices de la configuración del Servidor HTTP Apache 2.0:

  • ServerType — El Servidor HTTP Apache se puede ejecutar sólamente como ServerType standalone por lo que esta directriz es irrelevante.

  • AccessConfig y ResourceConfig — Se han eliminado estas directrices porque su funcionalidad aparece ya en la directriz Include. Si las directrices AccessConfig y ResourceConfig son configuradas, entonces reemplácelas por las directrices Include.

    Para asegurarse que estos archivos se lean en el orden de las antiguas directrices, las directrices Include se deberían colocar al final de httpd.conf, con la correspondiente a ResourceConfig precediendo la que corresponde a AccessConfig. Si se estan usando los valores por defecto, inclúyalos explícitamente como archivos conf/srm.conf y conf/access.conf.

22.2.2.2. Configuración del servidor principal

La sección de la configuración del servidor principal del archivo de configuración configura el servidor principal que responde a todas aquellas peticiones que no maneja un host virtual definido dentro de un contenedor <VirtualHost>. Los valores aquí también proporcionan valores por defecto para cualquier contenedor <VirtualHost> definido.

Las directrices utilizadas en esta sección han cambiado ligeramente respecto a las del Servidor HTTP Apache versión 1.3 y la versión 2.0. Si la configuración del servidor principal está altamente personalizada, le será más fácil modificar el archivo de configuración existente para que se adapte a la versión 2.0 del Servidor HTTP Apache. Los usuarios con secciones del servidor principal ligeramente personalizadas deberían migrar sus cambios al archivo de configuración 2.0 predeterminado.

22.2.2.2.1. Asignaciones UserDir

La directriz UserDir se usa para habilitar URLs tales como http://example.com/~bob/ para mapear a un subdirectorio dentro del directorio home del usuario bob tal como /home/bob/public_html/. Un efecto secundario de esta característica es que un potencial atacante puede determinar si un nombre de usuario dado se encuentra en el sistema; por esta razón la configuración por defecto para el Servidor HTTP Apache desactiva esta directriz.

Para habilitar la asignación de UserDir, cambie la directriz en httpd.conf desde:

UserDir disable

a lo siguiente:

UserDir public_html

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.2.2. Conexión

Se han eliminado las siguientes directrices de conexión:

  • AgentLog

  • RefererLog

  • RefererIgnore

Sin embargo, las conexiones agent y referrer estan disponibles usando las directrices CustomLog y LogFormat.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.2.3. Índice de directorios

Se ha eliminado la directriz FancyIndexing. La misma funcionalidad se encuentra ahora en FancyIndexingoption dentro de la directriz IndexOptions.

La opción VersionSort para la directriz IndexOptions causa que los archivos conteniendo números de versiones sean ordenados de una forma más natural. Por ejemplo, httpd-2.0.6.tar aparece antes de httpd-2.0.36.tar en una página de índices de directorio.

Las directrices predeterminadas ReadmeName y HeaderName han sido cambiadas desde README y HEADER a README.html y HEADER.html.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.2.4. Negociación de contenido

La directriz CacheNegotiatedDocs toma ahora el argumento on o off. Las instancias existentes de CacheNegotiatedDocs deberían ser cambiadas con CacheNegotiatedDocs on.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.2.5. Documentos de error

Para utilizar un mensaje codificado con la directriz ErrorDocument el mensaje tiene que aparecer en un par de comillas dobles " en vez de estar simplemente precedido por las comillas como en el Servidor HTTP Apache 1.3.

Por ejemplo, el siguiente es un ejemplo de la directtriz de Servidor HTTP Apache de la versión 1.3:

ErrorDocument 404 "The document was not found

Para migrar la configuración de ErrorDocument al Servidor HTTP Apache versión 2.0, utilice la siguiente estructura:

ErrorDocument 404 "The document was not found"

Observe las dobles comillas en la directriz ErrorDocument del ejemplo anterior.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.3. Configuración de host virtuales

Los contenidos de todos los contenedores <VirtualHost> se deben migrar de la misma manera que en la sección del servidor principal como se describió en Sección 22.2.2.2, “Configuración del servidor principal”.

Importante

Observe que la configuración de las máquinas virtuales SSL/TLS se han quitado del archivo de configuración del servidor principal al archivo /etc/httpd/conf.d/ssl.conf.

22.2.2.4. Módulos y el Servidor HTTP Apache 2.0

En la versión 2.0 del Servidor HTTP Apache el sistema de módulos se ha cambiado para permitir que los módulos se encadenen o se combinen en maneras nuevas e interesantes. Los scripts CGI (Common Gateway Interface), por ejemplo, pueden generar documentos HTML interpretados por el servidor que luego pueden ser procesados por mod_include. Esto abre una gran cantidad de posibilidades en lo que se refiere a cómo los módulos pueden combinarse para lograr una meta determinada.

La forma en que esto funciona es que cada petición es servida por exáctamente un módulo handler seguido por cero o más módulos filtro.

Bajo el Servidor HTTP Apache 1.3, por ejemplo, un script Perl es manejado completamente por el módulo Perl (mod_include). En la versión 2.0 del Servidor HTTP Apache la petición la gestiona inicialmente el módulo principal — que sirve archivos estáticos — y que es luego filtrado por mod_perl.

Exactamente cómo utilizar esto y otras de las nuevas características del Servidor HTTP Apache 2.0, están más allá del alcance de este documento; sin embargo, el cambio tiene ramificaciones si ha usado la directriz PATH_INFO para un documento que es gestionado por un módulo que ahora se implementa como un filtro, pues cada uno contiene información del recorrido del nombre del archivo verdadero. El módulo principal, que inicialmente manejaba la petición, no entiende por defecto PATH_INFO y devuelve el error 404 Not Found para las peticiones que contienen dicha información. Como alternativa puede utilizar la directriz AcceptPathInfo para obligar al módulo principal a que acepte peticiones con PATH_INFO.

A continuación se presenta un ejemplo de esta directriz:

AcceptPathInfo on

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.4.1. El módulo suexec

En el Servidor HTTP Apache 2.0, el módulo mod_suexec utiliza la directriz SuexecUserGroup en vez de las directrices User y Group, la cual se utiliza para configurar hosts virtuales. Las directrices User y Group también se pueden utilizar en general, pero no para la configuración de hosts virtuales.

Por ejemplo, el siguiente es un ejemplo de la directtriz de Servidor HTTP Apache de la versión 1.3:

<VirtualHost vhost.example.com:80> User someone Group somegroup </VirtualHost>

Para migrar esta configuración al Servidor HTTP Apache versión 2.0 utilice la siguiente estructura:

<VirtualHost vhost.example.com:80> SuexecUserGroup someone somegroup </VirtualHost>
22.2.2.4.2. El módulo mod_ssl

La configuración para mod_ssl se ha cambiado desde httpd.conf al archivo /etc/httpd/conf.d/ssl.conf. Para cargar este archivo y hacer que mod_ssl funcione, tiene que tener la declaración Include conf.d/*.conf en httpd.conf como se describe en la Sección 22.2.2.1.3, “Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)”.

Las directrices ServerName en las máquinas virtuales SSL tienen que especificar el número del puerto.

Por ejemplo, el siguiente es un ejemplo de la directtriz de Servidor HTTP Apache de la versión 1.3:

<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.example.name ... </VirtualHost>

Para migrar esta configuración al Servidor HTTP Apache versión 2.0 utilice la siguiente estructura:

<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.host.name:443 ... </VirtualHost>

También es importante tener en cuenta que ambas directrices SSLLog y SSLLogLevel han sido eliminadas. El módulo mod_ssl obedece las directrices ErrorLog y LogLevel . Para más información sobre estas directrices, consulte la ErrorLog y LogLevel

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.4.3. El módulo mod_proxy

Las declaraciones de control del acceso proxy se encuentran ahora en el bloque <Proxy> en vez de en <Directory proxy:>.

La funcionalidad de caché del antiguo mod_proxy se ha dividido en tres módulos siguientes:

  • mod_cache

  • mod_disk_cache

  • mod_mem_cache

Estos generalmente usan directrices similares a las versiones anteriores del módulo mod_proxy, pero se recomienda que verifique cada directriz antes de migrar cualquier configuración caché.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.4.4. El módulo mod_include

El módulo mod_include ahora es implementado como un filtro y por lo tanto se activa de una forma diferente. Consulte la Sección 22.2.2.4, “Módulos y el Servidor HTTP Apache 2.0” para obtener más información sobre filtros.

Por ejemplo, el siguiente es un ejemplo de la directtriz de Servidor HTTP Apache de la versión 1.3:

AddType text/html .shtml AddHandler server-parsed .shtml

Para migrar esta configuración al Servidor HTTP Apache versión 2.0 utilice la siguiente estructura:

AddType text/html .shtml AddOutputFilter INCLUDES .shtml

Observe que la directriz Options +Includes aún es requerida para el contenedor <Directory> o en el archivo .htaccess.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.4.5. Los módulos mod_auth_dbm y mod_auth_db

El Servidor HTTP Apache 1.3 soportaba dos módulos de autenticación, mod_auth_db y mod_auth_dbm que usaba las bases de datos Berkeley y DBM respectivamente. Estos módulos se han combinado en un único módulo que se llama mod_auth_dbm en el Servidor HTTP Apache 2.0, que puede acceder a diferentes formatos de bases de datos. Para migrar desde mod_auth_db los archivos de configuración se tienen que ajustar reemplazando AuthDBUserFile y AuthDBGroupFile con los equivalentes: AuthDBMUserFile y AuthDBMGroupFile. También, se debe añadir la directriz AuthDBMType DB para indicar el tipo de archivo de base de datos en uso.

El siguiente ejemplo muestra una configuración mod_auth_db de ejemplo para el Servidor HTTP Apache 1.3:

<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location>

Para migrar esta configuración a la versión 2.0 del Servidor HTTP Apache 2.0 utilice la siguiente estructura:

<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location>

Observe que la directriz AuthDBMUserFile también puede ser usada en archivos .htaccess.

El script Perl dbmmanage que se utiliza para manipular bases de datos de nombres de usuarios y contraseñas ha sido reemplazado por htdbm en el Servidor HTTP Apache 2.0. El programa htdbm ofrece una funcionalidad equivalente y como mod_auth_dbm puede operar en una variedad de formatos de bases de datos; la opción -T se puede usar en la línea de comandos para especificar el formato a utilizar.

Tabla 22.1, “Migración del dbmmanage a htdbm muestra cómo migrar desde un formato de base de datos DBM al formato htdbm utilizando g dbmmanage.

Acción comando dbmmanage (1.3) comando equivalente htdbm (2.0)
Añade un usuario a la base de datos (usando la contraseña dada) dbmmanage authdb add username password htdbm -b -TDB authdb username password
Añade un usuario a la base de datos ( le pide la contraseña) dbmmanage authdb adduser username htdbm -TDB authdb username
Eliminar el usuario de la base de datos dbmmanage authdb delete username htdbm -x -TDB authdb username
Listar usuarios en la base de datos dbmmanage authdb view htdbm -l -TDB authdb
Verificar una contraseña dbmmanage authdb check username htdbm -v -TDB authdb username
Tabla 22.1. Migración del dbmmanage a htdbm

Las opciones -m y -s trabajan con dbmmanage y con htdbm, permitiendo el uso de los algortimos MD5 o SHA1 para las contraseñas hashing, respectivamente.

Cuando cree una nueva base de datos con htdbm, use la opción -c.

Para mayor información, consulte los siguientes sitios web de la Apache Software Foundation:

22.2.2.4.6. El módulo mod_perl

La configuración para mod_perl se ha pasado del httpd.conf al archivo /etc/httpd/conf.d/perl.conf. Para cargar este archivo, y hacer funcionar mod_perl se debe incluir la declaración Include conf.d/*.conf en el httpd.conf como se describe en la Sección 22.2.2.1.3, “Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)”.

Las ocurrencias del Apache:: en el httpd.conf tienen que ser sustituídas por ModPerl::. Además, se ha cambiado el modo en que se registran los manejadores.

Ejemplo de configuración del Servidor HTTP Apache 1.3 mod_perl:

<Directory /var/www/perl> SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI </Directory>

Este es el equivalente del mod_perl para el Servidor HTTP Apache 2.0:

<Directory /var/www/perl> SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI </Directory>

La mayoría de los módulos para mod_perl 1.x deberían funcionar sin modificación con los módulos mod_perl 2.x. Los módulos XS requieren recompilación y quizás algunas modificaciones menores de Makefile.

22.2.2.4.7. El módulo mod_python

La configuración para mod_python ha sido movida desde httpd.conf al archivo /etc/httpd/conf.d/python.conf. Para que se cargue este archivo y por lo tanto para que funcione mod_python se debe incluir la declaración Include conf.d/*.conf en el httpd.conf como se describe en la Sección 22.2.2.1.3, “Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)”.

22.2.2.4.8. PHP

La configuración del PHP ha sido movida de httpd.conf al archivo /etc/httpd/conf.d/php.conf. Para cargar este archivo, tiene que tener la declaración Include conf.d/*.conf en httpd.conf tal y como se describe en la Sección 22.2.2.1.3, “Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)”.

Nota

Cualquier directriz de configuración PHP utilizada en el Servidor HTTP Apache 1.3 ahora es completamente compatible cuando se migra al Servidor HTTP Apache 2.0 en Red Hat Enterprise Linux 5.

En PHP 4.2.0 y posterior, el conjunto predeterminado de variables predefinidas que están disponibles en el ámbito global, han cambiado. Las entradas individuales y las variables del servidor, por defecto, ya no se colocan directamente en el ámbito global. Este cambio puede hacer que se rompan los scripts. Cámbiese al antiguo comportamiento colocando register_globals a On en el archivo /etc/php.ini.

Para mayor información sobre estos temas, consulte los siguientes sitios web:

22.2.2.4.9. El módulo mod_authz_ldap

Red Hat Enterprise Linux 5. se entrega con el módulo mod_authz_ldap para el Servidor HTTP Apache. Este módulo utiliza la forma corta del nombre distinguido para un sujeto y el emisor del certificado de cliente SSL para determinar el nombre distinguido de un usuario dentro de un directorio LDAP. También es capaz de autorizar usuarios basado en los atributos de esa entrada del usuario del directorio LDAP, determinando el acceso a los activos basado en los privilegios de usuario y de grupo de ese activo y negando el acceso a los usuarios con contraseñas caducadas. Se requiere el módulo mod_ssl cuando se utilice el módulo mod_authz_ldap.

Importante

El módulo mod_authz_ldap no valida un usuario a un directorio LDAP usando un hash de contraseña encriptada. Esta funcionalidad es proporcionada por el módulo experimental mod_auth_ldap. Consulte la documentación en línea de mod_auth_ldap en http://httpd.apache.org/docs-2.0/mod/mod_auth_ldap.html para más detalles sobre el estatus de este módulo.

El archivo /etc/httpd/conf.d/authz_ldap.conf configura al módulo mod_authz_ldap.

Consulte el /usr/share/doc/mod_authz_ldap-<version>/index.html (reemplazando <version> con el número de versión del paquete) o http://authzldap.othello.ch/ para más información sobre la configuración del módulo mod_authz_ldap.

22.3. Arrancar y detener httpd

Después de instalar el paquete httpd revise la documentación del Servidor HTTP Apache disponible en línea en http://httpd.apache.org/docs/2.2/.

El RPM de httpd instala el script /etc/init.d/httpd, el cual se puede acceder usando el comando /sbin/service.

Iniciando httpd utilizandoel script de control apachectl configura las variables del entorno en /etc/sysconfig/httpd e inicia httpd. También puede configurar las variables del entorno utilizando el script de inicialización.

Para arrancar el servidor utilizando el script de control apachectl como tipo root:

apachectl start

También puede arrancar httpd utilizando /sbin/service httpd start. Esto inicia httpd pero no configura las variables del entorno. Si está utilizando la directriz predeterminada Listen en httpd.conf, la cual es el puerto 80, necesitará contar con privilegios de usuario root para iniciar el servidor apache.

Para detener el servidor, como root escriba:

apachectl stop

También puede detener httpd utilizando /sbin/service httpd stop. La opción restart es una manera más rápida de detener y luego iniciar el Servidor HTTP Apache.

Para reiniciar el servidor como root escriba:

apachectl restart 
or:/sbin/service httpd restart

Apache presentará un mensaje en la consola o en el ErrorLog si encuentra un error al iniciar.

Por defecto, el servicio httpdno inicia automáticamente al momento de arranque. Si quiere que Apache inicie al momento de arranque necesitará añadir una llamada a apachectl en sus archivos de inicalización dentro de su directorio rc.local. Un archivo que se utiliza típicamente es rc.local. Ya que esto inicia Apache como usuario root se recomienda que configure apropiadamente su seguridad y autenticación antes de añadir esta llamada.

También puede configurar el servicio httpd para iniciar en tiempo de arranque utilizando una herramienta script de inicialización tal como /sbin/chkconfig, /usr/sbin/ntsysv, o el programa Services Configuration Tool.

También puede visualizar el estado de su servidor httpd escribiendo:

apachectl status

Sin embargo, el módulo de estado mod_status necesita ser habilitado en su archivo de configuración mod_status para que esto funcione. Para obtener más detalles sobre mod_status vaya a http://httpd.apache.org/docs/2.2/mod/mod_status.html.

Nota

Si esta ejecutando el Servidor HTTP Apache como un servidor seguro, se le pedirá la contraseña del servidor seguro después de que la máquina arranca cuando se utilice una llave privada SSL encriptada.

Puede encontrar más información en http://httpd.apache.org/docs/2.2/ssl

22.4. Configuración del Servidor HTTP Apache

La Herramienta de Configuración HTTP le permite configurar el archivo de configuración /etc/httpd/conf/httpd.conf para el Servidor HTTP Apache. No utiliza los antiguos archivos de configuración srm.conf o access.conf, déjelos vacíos. Podrá configurar las directrices tales como hosts virtuales, atributos de registro y número máximo de conexiones a través de la interfaz gráfica. Para iniciar la Herramienta de Configuración HTTD haga clic en System => Administration => Server Settings => HTTP.

Sólo se pueden configurar con la Herramienta de Configuración HTTPaquellos módulos que estén incluídos con Red Hat Enterprise Linux. Si se instalan otros módulos, no se podrán configurar utilizando esta herramienta.

Advertencia

No modifique el archivo de configuración /etc/httpd/conf/httpd.conf manualmente si desea utilizar esta herramienta. La Herramienta de Configuración HTTP genera este archivo después de que haya grabado los cambios y haya salido del programa. Si desea añadir módulos u opciones de configuración que no se encuentran en la Herramienta de Configuración HTTP no podrá usarla.

Los pasos generales para configurar el Servidor HTTP Apache utilizando la Herramienta de Configuración HTTP son los siguientes:

  1. Configure los aspectos básicos que se encuentran en la pestaña Principal

  2. Haga clic en Hosts Virtualesy configure las opciones predeterminadas.

  3. Bajo la pestaña Hosts Virtuales configure el Host Virtual Predeterminado.

  4. Para servir más de una URL o más de un host virtual, añada cualquier host virtual adicional.

  5. Configure las características del servidor bajo la pestaña Servidor.

  6. Configure la configuración de las conexiones bajo la pestaña Ajuste de Rendimiento.

  7. Copie todos los archivos necesarios a los directorios DocumentRoot y cgi-bin

  8. Salga de la aplicación y seleccione guardar sus configuraciones.

22.4.1. Configuración Básica

Use la pestaña Principal para establecer las configuraciones básicas del servidor.

Configuración Básica

Configuración Básica

Figura 22.1. Configuración Básica

Ingrese un nombre de dominio completamente calificado al que tenga derecho de utilizar en el área de texto Server Name. Esta opción corresponde a la directriz ServerName en httpd.conf. La directriz ServerName establece el nombre del host del servidor web. Se utiliza cuando se crea la redireccióm de URLs. Si no define un nombre de servidor, el servidor web intenta resolverlo desde la dirección IP del sistema. El nombre del servidor no tiene que ser el nombre del dominio resuelto desde la dirección IP del servidor. Por ejemplo, usted puede establecer el nombre del servidor como www.example.com mientras que el nombre DNS real del servidor es foo.example.com.

Ingrese la dirección de correo electrónico de la persona que mantiene el servidor web en el área de texto Dirección de correo electrónico del webmaster. Esta opción corresponde a la directriz ServerAdmin en httpd.conf. Si configura las páginas de error del servidor para que incluyan una dirección de correo electrónico, esta se utilizará para que los usuarios puedan reportar un problema al administrador del servidor. El valor predeterminado es root@localhost.

Utilice el área Direcciones Disponibles para definir los puertos en los que el servidor acepta pedidos entrantes. Esta opción corresponde a la directriz Listen en httpd.conf. Por defecto, Red Hat configura el Servidor HTTP Apache para que escuche el puerto 80 para comunicaciones de web no seguras.

Haga clic en el botón Añadir para definir puertos adicionales sobre los cuales se aceptan pedidos. Aparecerá una ventana como lo muestra Figura 22.2, “Direcciones Disponibles”. Puede escoger la opción Escuchar todas las direcciones para escuchar a todas IP en el puerto definido o especificque una dirección IP en particular sobre la cual el servidor acepta las conexiones en el campo Dirección. Especifique sólamente una dirección IP por número de puerto. Para especificar más de una dirección IP con el mismo número de puerto cree una entrada para cada dirección IP. Si es posible utilice una dirección IP en vez de un nombre d edominio para evitar una falla de búsqueda DNS. Refiérase a http://httpd.apache.org/docs/2.2/dns-caveats.html para obtener más información sobre Asuntos Relacionados con DNS y Apache.

Si introduce un asterisco (*) en el campo Direccionesequivaldrá a elegir la opción Escuchar todas las direcciones. Haga click en el botón Modificar en el recuadro de Direcciones disponibles muestra la misma ventana que el botón Añadir excepto los campos de la entrada seleccionada. Para borrar una entrada, seleccionela y haga clic en el botón Eliminar.

Sugerencia

Si configuró el servidor para escuchar en el puerto 1024, deberá ser root para arrancarlo. Para el puerto 1024 y superiores, se puede arrancar httpd como un usuario normal.

Direcciones Disponibles

Direcciones Disponibles

Figura 22.2. Direcciones Disponibles

22.4.2. Configuraciones predeterminadas

Después de definir el Nombre del Servidor, Dirección de correo eletrónico del webmaster y Direcciones Disponibles haga clic en la pestaña Hosts Virtuales. La figura a continuación ilustra la pestaña Hosts Virtuales.

Pestaña Hosts Virtuales

Pestaña Hosts Virtuales

Figura 22.3. Pestaña Hosts Virtuales

Al hacer clic en Modificar presentará la ventana de las Propiedades del Host Virtual desde donde usted puede configurarlo como desee. Para añadir nuevas configuraciones haga clic en el botón Añadir, el cual también presentará la ventana Propiedades del Host Virtual. Al hacer clic en el botón Modificar Configuración Predeterminada aparecerá una ventana Propiedades del Host Virtual sin la pestaña Opciones Generales.

En la pestaña Opciones Generales puede cambiar el nombre del host, el directorio root del documento y también puede establecer la dirección de correo electrónico del webmaster. En la información del Host puede establecer la Dirección IP del Host Virtual y el Nombre del Host. La figura a continuación ilustra la pestaña Opciones Generales.

Opciones Generales

Opciones Generales

Figura 22.4. Opciones Generales

Si añade un host virtual, la configuración del host virtual tiene prioridad para ese host virtual. Para una directriz no definida dentro de la configuración del host virtual se utiliza el valor predeterminado.

22.4.2.1. Configuración del Sitio

La figura a continuación ilustra la pestaña Opciones de Página desde la cual puede configurar la Lista de Páginas del Directorio y Páginas de Error. Si no está seguro de esta configuración no la modifique.

Configuración del Sitio

Configuration del Sitio

Figura 22.5. Configuración del Sitio

Las entradas que aparecen en la Lista de Búsqueda de Página de Directorio definen la directiva DirectoryIndex. ElDirectoryIndex es la página predeterminada que el servidor da a un usuario que pide el índice de un directorio escribiendo la barra inclinada (/) al final del nombre del directorio.

Por ejemplo, cuando un usuario pide la páginahttp://www.example.com/this_directory/ recibe la página del índice del directorio, DirectoryIndex, si existe, o un listado de directorios generado por el servidor. El servidor intentará encontrar uno de los archivos incluidos en DirectoryIndex y entregará el primero que encuentre. Si no encuentra ninguno de estos archivos y siOptions Indexes está configurado para ese directorio, el servidor genera y devuelve una lista, en formato HTML, de los subdirectorios y archivos dentro del directorio.

Utilice la sección Código Error para configurar el Servidor HTTP Apache para redireccionar el cliente a una URL local o externa en el caso de que haya un error o un problema. Esta opción corresponde a la directriz ErrorDocument. Si ocurre un error o si se presenta un problema cuando un clienta trata de conectarse al Servidor HTTP Apache, la acción predeterminada es presentar un corto mensaje de error en la columna Código Error. Para cancelar esta configuración predeterminada seleccione el código error y haga clic en el botón Modificar. Seleccione Predeterminado para visualizar el mensaje corto de error predeterminado. Elija URL para redireccionar el cliente a la URL externa e ingresar una URL completa incluyendo el http:// en el campo Location. Seleccione File para redireccionar el cliente a una URL interna e ingresar la ubicación de un archivo bajo la raíz del documento para el servidor Web. La ubicación debe comenzar con la barra inclinada (/) y debe estar relacionada con la Raíz del Documento.

Por ejemplo, para redirigir un código de error 404 Not Found a una página web que usted ha creado en un archivo llamado 404.html copie 404.html a DocumentRoot/../error/404.html. En este caso, DocumentRoot es el directorio del documento raíz que ha definido (el valor por defecto es /var/www/html/). Si se deja el documento raíz como la ubicación por defecto, el archivo debería ser copiado a /var/www/error/404.html. Luego, elija Archivo como el Comportamiento para el código de error 404 - Not Found e introduzca /error/404.html como la Ubicación.

Desde el menú Pie de Página de Error por Defecto escoja una de las siguientes opciones:

  • Mostrar el pie de página con la dirección de correo electrónico — Esta opción muestra el pie de página predeterminado en todas las páginas de error junto con la dirección de correo electrónico del encargado del sitio web especificado por la directriz ServerAdmin.

  • Muestra el pie de página — Esta opción le muestra el pie de página predeterminado en todas las páginas de error.

  • Ningún pie de página — No muestra el pie de página en las páginas de error.

22.4.2.2. Soporte SSL

El mod_ssl le permite encriptar el protocolo HTTP sobre SSL. El protocolo SSL(Secure Sockets Layer) se utiliza para comunicación y para encriptar sobre redes TCP/IP. La pestaña SSL le permite configurar SSL para su servidor. Para configurar SSL necesita proporcionar la ruta a su:

  • Archivo de certificado - equivalente a utilizar la directriz SSLCertificateFile la cual apunta la ruta al archivo de certificado de servidor codificado PEM (Privacy Enhanced Mail).

  • Archivo de la llave - equivalente a utilizar la directriz SSLCertificateKeyFile la cual apunta la ruta al archivo de la llave privada del servidor codificado PEM.

  • Archivo de cadena del certificado - equivalente a utilizar la directriz SSLCertificateChainFile la cual apunta la ruta al archivo del certificado que incluye todos los certificados de cadena del servidor.

  • Archivo de autoridad del certificado - es un archivo encriptado utilizado para confirmar la autenticidad o identidad de las partes que se comunican con el servidor.

Puede encontrar más información sobre las directrices de configuración para SSL en http://httpd.apache.org/docs/2.2/mod/directives.html#S. También necesita determinar que opciones SSL debe habilitar. Estas son equivalentes a utilizar SSLOptions con las siguientes opciones:

  • FakeBasicAuth - habilita los métodos de autenticación estándares utilizados por Apache. Esto significa que el Nombre Distinguido del Sujeto del certificado del Cliente X509 es traducido a un nombre de usuario HTTP básico.

  • ExportCertData - crea variables de entorno CGI en SSL_SERVER_CERT, SSL_CLIENT_CERT y SSL_CLIENT_CERT_CHAIN_n en donde n es un número 0,1,2,3,4... Los scripts CGI utilizan estos archivos para más chequeos de certificados.

  • CompatEnvVars - habilita una compatibilidad retroactiva para Apache SSL añadiendo variables de entorno CGI.

  • StrictRequire - habilita acceso estricto el cual obliga a denegar acceso cuando las directrices SSLRequireSSL y SSLRequire indican que es prohibido el acceso.

  • OptRenegotiate - permite eludir los apretones de manos de mod_ssl el cual también realiza chequeos de parámetros seguros. Se recomienda que habilite OptRenegotiate con base en el directorio.

Para obtener más información sobre las opciones SSL mencionadas anteriormente vaya a http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions. La figura a continuación ilustra la pestaña SSL y las opciones que se discutieron anteriormente.

SSL

SSL

Figura 22.6. SSL

22.4.2.3. Conexión

Utilice la pestaña Registro para configurar las opciones para registro de errores y transferencia específica.

Por defecto, el servidor escribe el registro de transferencia en el archivo /var/log/httpd/access_log y el registro de error en el archivo /var/log/httpd/error_log.

El registro de transferencias contiene una lista de todos los intentos para acceder al servidor web. Graba las direcciones IP del cliente que está tratande de conectarse, la fecha y hora en que intentó, y el archivo en el servidor web que está tratando de recuperar. Introduzca el nombre de la ruta y del archivo en donde se alamacenará esta información. Si el nombre de la ruta y del archivo no comienzan con una barra inclinada (/), la ruta es relativa al directorio root del servidor como se configurá. Esta opción corresponde a la directriz TransferLog.

Conexión

Conexión

Figura 22.7. Conexión

Puede configurar un registro con formato personalizado chequeando Usar las facilidades de registro personalizado e introduciendo una cadena personalizada en el campo Cadena de registro personalizada. Esto configura la directriz LogFormat. Para mayor información sobre los detalles del formato de la directiva consulte http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#logformat.

El registro de transferencia incluye una lista de los errores del servidor. Introduzca el nombre de la ruta y del archivo en donde se debe almacenar esta información. Si el nombre de la ruta y del archivo no empiezan con una barra inclinada (/), la ruta es relativa al directorio root del servidor como se configuró. Esta opción corresponde a la directriz ErrorLog.

Utilice el menú Nivel de Registro para establecer la verbosidad de los emnsajes de error en los registrs de error. Se puede configurar (del menos verbos al más verboso) como emerg, alerta, crit, error, advert, aviso, info o depurar. Esta opción corresponde a la directriz LogLevel.

El valor escogido en el menú Búsqueda inversa del DNS define la directiva HostnameLookups Si escoge Ninguna búsqueda inversa se desactiva el valor, si escoge Búsqueda inversa el valor está activado y si escoge Doble búsqueda inversa éste se duplica.

Si escoje Búsuqeda Inversa su servidor resuelve automáticamente la dirección IP para cada conexión la cual pide un documento de su servidor web. El resolver una dirección IP significa que su servidor realiza una o más conexiones al DNS para encontrar el nombre del host que corresponde a una dirección IP en particular.

Si elije Búsqueda Inversa Doble su servidor realiza un DNS inverso doble. Es decir, después de que se realiza una búsqueda inversa, se realiza una búsqueda avanzada en el resultado. Por lo menos una de las direcciones IP en la búsqueda vanazada debe coincidir con la dirección de la primera búqieda inversa.

Generalmente, esta opción debería de estar en Ninguna Búsqueda Inversa porque sino se sobrecarga al servidor y disminuye el ritmo de trabajo. Si su servidor tiene mucha carga, al tratar de realizar estas búsquedas, los efectos serán bastante notables.

Las búsquedas inversas y las búsquedas inversas dobles también son un problema para el internet en general. Cada conexión individual que se realiza para buscar cada nombre de host se va sumando. Por lo tanto, para el beneficio de su propio servidor web así como para el beneficio de internet, usted debe dejar configurada esta opción como No Búsqueda Inversa.

22.4.2.4. Variables del entorno

Utilice la pestaña Entorno para configurar las opciones para variables específicas para establecer, pasar o desconfigurar para scripts CGI.

Algunas veces es necesario modificar las variables del entorno para scripts CGI o páginas server-side include (SSI). El Servidor HTTP Apache puede usar el módulo mod_env para configurar las variables del ambiente que son pasadas a los scripts CGI y a las páginas SSI. Utilice la página Variables de entorno para configurar las directivas para este módulo.

Utilice la sección Configuración para el Script CGI para establecer una variable de entorno que se pasa a los scripts CGI y a las páginas SSI. Por ejemplo, para establecer la variable de entorno MAXNUM como 50 haga clic en el botón Añadir dentro de la sección Configuración para el Script CGI como se muestra en Figura 22.8, “Variables del entorno” y escriba MAXNUM en el campo de texto Variables de Entorno y 50 en el campo de texto Valor a establecer. Haga clic en OK para añadirlo a la lista. La sección Configuración para el Script CGI configura la directriz ConfigEnt

Utilice la sección Pasar a los Scripts CGI para pasar el valor de una variable de entorno cuando el servidor se inicia por primera vez en scripts CGI. Para ver esta variable de entrada escriba el comando env en un intérprete de comandos. Haga clic en el botón Añadir dentro de la sección Pasar a Scripts CGI e introduzca el nombre de la variable de entorno en la ventana de diálogo que aparece. Haga clic en OK para añadirla a la lista. La sección Pass to CGI Scripts configura la directriz PasarEnt.

Variables del entorno

Variables del Entorno

Figura 22.8. Variables del entorno

Para eliminar una variable de entorno de manera que el valor no se pase a a los scripts CGI y a las páginas SSI utilice la sección Desconfigurar para Scripts CGI. Haga clic en Añadir en la sección Desconfigurar para Scripts CGI e introduzca el nombre de la variable de entorno en desconfigurar. Haga clic en OK para añadirla a la lista. Esto corresponde a la directriz DesconfigEnt

Para modificar cualquier de estos valores de entorno selecciónelo de la lista y haga clic en el botón Modificar . Para borrar cualquier entrada de la lista selecciónela y haga clic en el botón Eliminar correspondiente.

Para obtener más información sobre las variables de entorno en el Servidor HTTP Apache refiérase a: http://httpd.apache.org/docs/2.2/env.html

22.4.2.5. Directorios

Utilice la página Directorios en la pestaña Rendimiento para configurar las opciones para directorios específicos. Esto corresponde a la directriz <Directory>.

Directorios

Directorios

Figura 22.9. Directorios

Haga clic en el botón Modificar en la parte de arriba de la esquina derecha para configurar las Opciones del Directorio Predeterminadas para todos los directorios que no se especifican en la lista Directorio debajo de esta. Las opciones que puede escoger como la directriz Opciones dentro de la directriz <Directorio>. Puede configurar las siguientes opciones:

  • ExecCGI — Permite la ejecución de los scripts CGI. Los scripts no se ejecutan si no elige esta opción.

  • FollowSymLinks — Permite que se sigan enlaces simbólicos.

  • Includes — Permite las inclusiones en el servidor (SSI).

  • IncludesNOEXEC — Permite las inclusiones en el servidor pero anula los comandos #exec y #include en los scripts CGI.

  • Indexes — Muestra una lista formateada de los contenidos de un directorio si la opción DirectoryIndex (como por ejemplo index.html) existe en el directorio pedido.

  • index.html Soporta las visualizaciones múltiples de los contenidos; esta opción no está activada por defecto.

  • SymLinksIfOwnerMatch — Permite seguir un enlace simbólico sólamente si el archivo o el directorio en cuestión tienen el mismo propietario que el enlace.

Para especificar opciones para directorios específicos haga clic en el botón Añadir al lado de la lista Directorio. Aparecerá una ventana como en Figura 22.10, “Configuración de Directorio”. Ingrese el directorio a configurar en el campo de texto Figura 22.10, “Configuración de Directorio” en la parte de abajo de la ventana. Seleccione las opciones en la lista del lado derecho y configure la directriz Order con las opciones que se encuentran del lado izquierdo. La directriz Orden controla el orden en que se evaluan las directrices de permiso y de rechazo. En los campos de texto Permitir Allow hosts de y Rechazar hosts de puede especificar uno de los siguientes:

  • Permitir todas los hosts — Escriba all para permitir el acceso a todos los hosts.

  • Nombre parcial de dominio — Permite todas las máquinas cuyos nombres coincidan o terminen con una cadena determinado.

  • Dirección IP completa — Permite el acceso a una determinada dirección IP.

  • Una subred — Tal como 192.168.1.0/255.255.255.0

  • Una especificación CIDR de red — como por ejemplo 10.3.0.0/16

Configuración de Directorio

Configuración del Directorio

Figura 22.10. Configuración de Directorio

Si marca Permitir que los archivos .htaccess pasen por encima de las opciones del directorio las directivas de configuración en el archivo .htaccess toman precedencia.

22.5. Directrices de configuración en httpd.conf

El archivo de configuración del Servidor HTTP Apache es /etc/httpd/conf/httpd.conf. El archivo httpd.conf está bien comentado y en gran parte es autoexplicativo. Su configuración por defecto funciona para la mayoría de los casos; sin embargo, es una buena idea familiarizarse con algunas de las opciones de configuración más importantes.

Advertencia

Con la versión 2.2 del Servidor HTTP Apache han cambiado muchas de las opciones de configuración. Si necesita migrar de la versión 1.3 a la 2.2 primero lea Sección 22.2.2, “Migración de los Archivos de Configuración del Servidor HTTP Apache de la Versión 1.3 a la 2.0”.

22.5.1. Sugerencias de configuración generales

Si necesita configurar el Servidor HTTP Apache sólo tiene que modificar el archivo /etc/httpd/conf/httpd.conf y después recargar o bien apagar y arrancar el proceso httpd como se describe en Sección 22.3, “Arrancar y detener httpd.

Antes de modificar el archivo httpd.conf, primero haga una copia del archivo original. Al crear una copia de respaldo se hace más fácil recuperarse de posibles errores cometidos mientras se editaba el archivo de configuración.

Si comete un error y su servidor de web no funciona correctamente, lo primero que debe realizar es revisar lo que lo que acaba de modificar en httpd.conf para ver si no hay errores de transcripción.

Después consulte el archivo de registro de errores del servidor web, /var/log/httpd/error_log. Este puede ser difícil de interpretar, todo depende del nivel de experiencia. Sin embargo, las últimas entradas en el registro deberían de ayudarle a saber lo que ha pasado.

Las siguientes subsecciones proporcionan una breve descripción de muchas de las directrices incluidas en httpd.conf. Estas descripciones no son exhaustivas. Para obtener más información consulte la documentación de Apache en línea http://httpd.apache.org/docs/2.2/.

Para obtener mayor información sobre las directrices mod_ssl consulte la documentación en http://httpd.apache.org/docs/2.2/mod/mod_ssl.html.

AccessFileName

AccessFileName denomina el archivo que el servidor utilizará para información de control de acceso en cada directorio. Por defecto, el servidor utilizará .htaccess.

Justo tras AccessFileName, un conjunto de indicadores de Files aplican el control de acceso a cualquier archivo comenzando con un .ht. Estas directrices niegan el acceso Web a cualquier archivo .htaccess (o otros archivos que comiencen con .ht) por razones de seguridad.

Acción

Action especifica parejas tipo contenido MIME y script CGI, para que cuando un archivo de ese tipo de media sea solicitado, se ejecute un script CGI particular.

AddDescription

Cuando utilice FancyIndexing como un parámetro de IndexOptions, la directriz AddDescription se puede usar para mostrar descripciones especificadas por el usuario para ciertos archivos o tipos de archivo en un listado de directorio generado por el servidor. La directriz AddDescription soporta el listado de archivos específicos, expresiones con comodines o extensiones de archivos.

AddEncoding

La directriz AddEncoding nombra las extensiones de archivos que deberían especificar un tipo particular de codificación. También se puede usar AddEncoding para decirle a los navegadores que descompriman ciertos archivos mientras los descargan.

AddHandler

La directriz AddHandler hace corresponder extensiones de archivos a manejadores específicos. Por ejemplo, se puede corresponder el manejador cgi-script con la extensión .cgi para que automáticamente trate a cualquier archivo con un nombre que termine en .cgi como un script CGI. A continuación se presenta un ejemplo de una directriz AddHandler para la extensión .cgi.

AddHandler cgi-script .cgi

Esta directriz habilita a CGIs fuera del cgi-bin para que funcionen en cualquier directorio en el servidor que tenga la opción ExecCGI dentro del contenedor de directorios. Refiérase a la Directory para obtener más información sobre la configuración de la opción ExecCGI para un directorio.

Además de los scripts CGI, la directriz AddHandler es usada para procesar archivos de mapas de imagen y HTML analizados por el servidor.

AddIcon

AddIcon dice al servidor qué icono mostrar en los listados del directorio para ciertos tipos de archivos según la extensión. Por ejemplo, el servidor Web muestra el icono binary.gif para archivos con extensiones .bin o .exe.

AddIconByEncoding

Esta directriz denomina qué iconos se mostrarán con los archivos según su codificación MIME, en los listados de directorio. Por ejemplo, el servidor muestra por defecto el icono compressed.gif junto a archivos con codificación MIME x-compress y x-gzip en los listados de directorio.

AddIconByType

Esta directriz denomina qué iconos se mostrarán con los archivos con codificación MIME, en los listados del directorio. Por ejemplo, por defecto, el servidor muestra el icono text.gif junto a archivos con tipo MIME text en los listados del directorio.

AddLanguage

La directriz AddLanguage asocia extensiones de nombres de archivos a idiomas específicos. Esta directriz es útil para los Servidores HTTP Apache, los cuales devuelven contenidos en diferentes idiomas dependiendo de la configuración del idioma del navegador Web del cliente.

AddType

Utilice la directriz AddType para definir o suprimir por defecto pares tipo MIME y extensiones de archivos. El siguiente ejemplo de directriz le dice al Servidor HTTP Apache que reconozca la extensión de archivos .tgz:

AddType application/x-tar .tgz

Alias

El valor Alias hace accesibles a los directorios fuera del directorio DocumentRoot. Cualquier URL que termine en el alias será automáticamente traducido a la ruta del alias. Por defecto, ya existe un alias configurado para un directorio icons. El servidor web puede acceder al directorio icons, pero el directorio no está en el DocumentRoot.

Allow

Allow especifica cual cliente puede acceder a un directorio dado. El solicitante puede ser all, un nombre de dominio, una dirección IP, una dirección IP parcial, un par de red/máscara de la red, etc. El directorio DocumentRoot está configurado para permitir (Allow) peticiones desde todos (all), es decir, que todos tienen acceso.

AllowOverride

La directriz AllowOverride indica si puede o no ignorar cualquiera de las Options por las declaraciones en un archivo .htaccess. Por defecto, tanto el directorio raíz como DocumentRoot están configurados para no se permita ignorar .htaccess.

BrowserMatch

La directriz BrowserMatch permite al servidor definir variables de entorno y/o tomar acciones según sea el campo de cabecera User-Agent del HTTP, que identifica el tipo de navegador Web del cliente. Por defecto, el servidor usa BrowserMatch para denegar la conexión a navegadores con problemas conocidos y para desactivar "keepalives" y vaciados de cabecera de HTTP para navegadores que se sabe tienen problemas con acciones de ese tipo.

Directrices Cache

El archivo de configuración del Servidor HTTP Apache suministra varias directrices de caché comentadas. En la mayoría de los casos, al quitar el comentario de estas líneas mediante la eliminación de las almohadillas (#) del principio de la línea es suficiente. Sin embargo, lo siguiente es una lista de algunas de las directrices relacionadas con caché más importantes.

  • CacheEnable — Especifica si la caché es un disco, memoria o caché de archivo descriptivo. Por defecto CacheEnable configura un disco caché para las URLs en o por debajo de /.

  • CacheRoot — pone el nombre del directorio que contiene archivos de caché. El valor predeterminado de CacheRoot es el directorio /var/httpd/proxy/.

  • CacheSize — establece cuánto espacio puede usar el caché, en KB. El valor predeterminado de CacheSize es 5 KB.

Lo siguiente es una lista de algunas directrices comunes relacionadas con caché.

  • CacheMaxExpire — Especifica cuanto tiempo se conservan los documentos HTML (sin una recarga desde el servidor Web original) en el caché. El valor por defecto es 24 horas (86400 segundos).

  • CacheLastModifiedFactor — Especifica la creación de una fecha de vencimiento para documentos que no venían con caducidad desde el servidor de origen. El valor predeterminado de CacheLastModifiedFactor está configurado a 0.1, es decir que la fecha de vencimiento para tales documentos es igual a un décimo de la cantidad de tiempo desde la última vez que se modificó el documento.

  • CacheDefaultExpire — Especifica el tiempo de caducidad en horas para un documento que fue recibido usando un protocolo que no soporta fechas de vencimiento. El valor por defecto es configurado a 1 hora (3600 segundos).

  • NoProxy — Especifica una lista separada por espacios de subredes, direcciones IP, dominios o hosts cuyos contenidos no están en caché. Este valor es de gran utilidad para sitios de Intranet.

CacheNegotiatedDocs

Por defecto, el servidor Web requiere a los servidores proxy que no hagan caché de los documentos que se negocian en base al contenido (pueden cambiar en el tiempo o según la entrada de quien los solicita). Si se configura CacheNegotiatedDocs a on, se desactiva la función y se permite acceso a los servidores proxy a tales documentos caché.

CustomLog

CustomLog identifica el archivo de registro y su formato. Por defecto, el registro de acceso es guardado al archivo /var/log/httpd/access_log mientras que los errores se guardan en el archivo /var/log/httpd/error_log.

El formato por defecto CustomLog es combined, como se ilustra a aquí:

remotehost rfc931 user date "request" status bytes referrer user-agent

DefaultIcon

DefaultIcon especifica el icono desplegado en el listado generado por el servidor para archivos que no tienen otro icono especificado. El archivo de imagen por defecto es unknown.gif.

DefaultType

DefaultType establece el tipo de contenido por defecto que el servidor utilizará para documentos cuyos tipos MIME no puedan ser determinados. Por defecto es text/plain.

Deny

Deny funciona igual que Allow, excepto que especifica a quién se le niega el acceso. DocumentRoot no es configurado para negar (Deny) peticiones a ninguno por defecto.

Directory

Las etiquetas <Directory /path/to/directory> y </Directory> se usan para crear un contenedor que se utiliza para cercar un grupo de directrices de configuración que sólo se aplican a un directorio y sus subdirectorios específicos. Cualquier directriz aplicable a un directorio puede usarse en las etiquetas Directory.

Por defecto, se aplican parámetros muy restrictivos al directorio raíz (/) utilizando las directrices Options (consulte la Options) y AllowOverride (vea la AllowOverride). Con esta configuración, cualquier directorio del sistema que necesite valores más permisivos ha de ser configurado explícitamente con esos valores.

En la configuración predeterminada, otro contenedor Directory es configurado para el DocumentRoot, el cual asigna parámetros menos rígidos al árbol del directorio para que el Servidor HTTP Apache pueda acceder a los archivos que residan allí.

El contenedor Directory también se puede utilizar para configurar directorios adicionales cgi-bin para las aplicaciones del servidor fuera del directorio especificado en la directriz ScriptAlias (consulte a la ScriptAlias para obtener más información).

Para lograr esto, el contenedor Directory debe configurar la opción ExecCGI para ese directorio.

Por ejemplo, si los scripts CGI están localizados en /home/my_cgi_directory, añada el contenedor siguiente Directory al archivo httpd.conf:

<Directory /home/my_cgi_directory> Options +ExecCGI </Directory>

Luego, necesitará anular el comentario de la directriz AddHandler para identificar archivos con la extensión .cgi como scripts CGI. Consulte la AddHandler para saber cómo configurar el AddHandler.

Para que esto funcione, los permisos para los scripts CGI y la ruta completa a los scripts, se deben colocar a 0755.

DirectoryIndex

DirectoryIndex es la página por defecto que entrega el servidor cuando hay una petición de índice de un directorio especificado con una barra (/) al final del nombre del directorio.

Cuando un usuario pide la página http://ejemplo/este_directorio/, recibe la página del índice del directorio, DirectoryIndex, si existe, o un listado de directorios generado por el servidor. El valor por defecto para DirectoryIndex es index.html y el tipo de mapa index.html.var. El servidor intentará encontrar cualquiera de estos archivos y entregará el primero que encuentre. Si no encuentra ninguno de estos archivos y Options Indexes esta configurado para ese directorio, el servidor genera y devuelve una lista, en formato HTML, de los subdirectorios y archivos dentro del directorio, a menos que la característica de listar directorios esté desactivada.

DocumentRoot

DocumentRoot es el directorio que contiene la mayoría de los archivos HTML que se entregarán en respuesta a peticiones. El directorio predeterminado DocumentRoot para servidores web seguros y no seguros es /var/www/html. Por ejemplo, el servidor puede recibir una petición para el siguiente documento:

http://example.com/foo.html

El servidor busca por el archivo siguiente en el directorio por defecto:

/var/www/html/foo.html

Si se quiere cambiar DocumentRoot para que no lo compartan los servidores web seguros y los no seguros vea la Sección 22.7, “Hosts virtuales”.

ErrorDocument

La directriz ErrorDocument asocia un código de respuesta HTTP con un mensaje o un URL para que sea devuelto al cliente. Por defecto, el servidor Web produce una salida simple de mensaje de error cuando ocurre alguno. La directriz ErrorDocument obliga a que el servidor Web envie una salida de mensaje personalizado o página.

Importante

Para que el mensaje sea válido, éste se tiene que estar entre un par de comillas dobles ".

ErrorLog

ErrorLog especifica el archivo donde se guardan los errores del servidor . Por defecto, esta directriz es configurada a /var/log/httpd/error_log.

ExtendedStatus

La directriz ExtendedStatus controla si Apache generará información básica del estado del servidor (off) o detallada (on), cuando se invoca el manejador server-status. El manejador server-status se llama utilizando la etiqueta Location. Para obtener más ifnormación sobre cómo realizar llamadas server-status vaya a Location.

Group

Especifica el nombre del grupo de los procesos del Servidor HTTP Apache.

Esta directriz se ha desaprobado para la configuración de hosts virtuales.

Por defecto, Group está configurado a apache.

HeaderName

La directriz HeaderName dicta el archivo (si existe dentro del directorio) que se antepondrá al comienzo de los listados de los directorios. Al igual que con ReadmeName, el servidor intentará incluirlo como documento HTML si es posible, o en caso contrario, como texto.

HostnameLookups

HostnameLookups se puede configurar a on, off o double. Si se configura HostnameLookups a on, el servidor automáticamente resuelve las direcciones IP para cada conexión. Resolver las direcciones IP significa que el servidor hace una o más conexiones a un servidor DNS, añadiendo sobrecarga por procesamiento. Si HostnameLookups es configurado a double, el servidor realiza búsquedas inversa doble del DNS, añadiendo aún más sobrecarga.

Para ahorrar recursos en el servidor, HostnameLookups es configurado a off por defecto.

Si se requieren nombres de host en los archivos de registro, considere ejecutar una de los muchas herramientas de análisis de log que llevan a cabo las búsquedas de DNS de forma mucho más eficiente y por montones cuando se este rotando los archivos de log del servidor Web.

IfDefine

Las etiquetas IfDefine envuelven directrices de configuración que son aplicadas si el "test" establecido en la etiqueta <IfDefine> es verdadero. Las directrices no se tienen en cuenta si el test es falso.

El test en las etiquetas IfDefine es un nombre de parámetro (por ejemplo, HAVE_PERL). Si el parámetro está definido, es decir, si se da como argumento al comando de arranque del servidor, entonces el test es verdadero. En este caso, cuando se arranca el servidor Web, el test es verdadero y se aplican las directrices contenidas en las etiquetas IfDefine.

IfModule

Las etiquetas <IfModule> y </IfModule> crean un contenedor condicional que sólo es activado si el módulo especificado es cargado. Las directrices contenidas entre etiquetas IfModule son procesadas bajo una de dos condiciones. Las directrices son procesadas si se carga el módulo entre la etiqueta de comienzo <IfModule>. O, si un símbolo de exclamación ! aparece antes del nombre del módulo, entonces las directrices son procesadas sólo si el módulo especificado en la etiqueta <IfModule>no es cargado.

Para obtener mayor información sobre los módulos del Servidor HTTP Apache consulte la Sección 22.6, “Añadir módulos”.

Include

Include permite que se incluyan otros archivos de configuración en el tiempo de ejecución.

La ruta a estos archivos de configuración pueden ser absolutas o relativas con respecto al ServerRoot.

Importante

Para que el servidor use módulos de paquetes individuales, como mod_ssl, mod_perl y php, tiene que estar la siguiente directriz en Section 1: Global Environment del httpd.conf:

Include conf.d/*.conf

IndexIgnore

IndexIgnore lista las extensiones de archivo, los nombres de los archivos parciales, las expresiones con comodines o los nombres completos. El servidor Web no incluirá ningún archivo que coincida con estos patrones en los listados de directorios.

IndexOptions

IndexOptions controla la apariencia de los listados generados por el servidor, al añadir iconos, texto descriptivo, etc. Si Options Indexes está configurado (vea la Options) el servidor Web server genera un listado de directorio cuando el servidor Web recibe una petición HTTP para un directorio sin un índice.

Primero el servidor Web busca en el directorio solicitado un archivo que coincida los nombres listados en la directriz DirectoryIndex (usualmente, index.html). Si el servidor no encuentra un archivo index.html el Servidor HTTP Apache genera un listado del directorio en HTML. La apariencia del listado de este directorio es controlada, en parte, por la directriz IndexOptions.

La configuración predeterminada activa FancyIndexing. Esto significa que un usuario puede reordenar un listado de directorio haciendo clic en las cabeceras de columnas. Otro clic en la misma cabecera cambiará del orden ascendente al descendente. FancyIndexing también muestra iconos diferentes para diferentes archivos, basados en las extensiones de archivos.

La opción AddDescription, cuando se utiliza junto con FancyIndexing, presenta una descripción corta para el archivo en los listados de directorios generados por el servidor.

IndexOptions tiene otros parámetros que pueden activarse para controlar la apariencia de los listados generados por los servidores. Los parámetros IconHeight y IconWidth requieren que el servidor incluya etiquetas HTML HEIGHT y WIDTH para los iconos en las páginas generadas por el servidor. El parámetro IconsAreLinks combina el icono con el ancla HTML, la cual contiene el enlace URL objetivo.

KeepAlive

KeepAlive determina si el servidor permitirá más de una petición por conexión y se puede usar para prevenir a un cliente consumir demasiados recursos del servidor.

Por defecto Keepalive está configurado a off. Si Keepalive está en on y el servidor se vuelve muy ocupado, este puede rápidamente generar el máximo número de procesos hijos. En esta situación, el servidor se volverá significativamente lento. Si se activa Keepalive es una buena idea configurar el KeepAliveTimeout a un valor bajo (consulte la KeepAliveTimeout para más información sobre la directriz KeepAliveTimeout) y controle el archivo de registro /var/log/httpd/error_log en el servidor. Este registro informa cuando el servidor se está quedando corto de procesos hijos.

KeepAliveTimeout

La directriz KeepAliveTimeout establece el número de segundos que el servidor esperará tras haber dado servicio a una petición, antes de cerrar la conexión. Una vez que el servidor recibe una petición, se aplica la directriz Timeout en su lugar. KeepAliveTimeout está configurado a 15 segundos por defecto.

LanguagePriority

La directriz LanguagePriority permite dar la prioridad para diferentes idiomas en caso de que el navegador Web no especique la preferencia de idioma.

Listen

El comando Listen identifica los puertos en los que el servidor Web aceptará las peticiones entrantes. Por defecto, el Servidor HTTP Apache está configurado para escuchar en el puerto 80 para comunicaciones Web no seguras y (en el archivo /etc/httpd/conf.d/ssl.conf el cual define cualquier servidor seguro) en el puerto 443 para comunicaciones seguras.

Si el Servidor HTTP Apache está configurado para escuchar en un puerto por debajo del 1024, se necesita al usuario root para iniciarlo. Para los puertos 1024 y superiores, httpd puede ser arrancado por cualquier usuario.

La directriz Listen también se puede usar para especificar direcciones IP particulares sobre las cuales el servidor aceptará conexiones.

LoadModule

LoadModule se utiliza para cargar módulos Dynamic Shared Object (DSO). Se puede encontrar más información sobre el soporte del Servidor HTTP Apache para DSO, incluyendo exáctamente cómo utilizar la directriz LoadModule en la Sección 22.6, “Añadir módulos”. Observe que ya no es importante el orden en que se cargan estos módulos con el Servidor HTTP Apache 2.0. Consulte la Sección 22.2.2.1.3, “Soporte del Dynamic Shared Object (DSO) (Objeto dinámico compartido)” para obtener más información sobre el soporte DSO del Servidor HTTP Apache 2.0 para DSO.

Location

Las etiquetas <Location> y </Location> permiten crear un contenedor en el cual se puede especificar el control de acceso basado en URL.

Por ejemplo, para permitir a personas conectarse desde dentro del dominio del servidor para ver informes de estado, utilice las directrices siguientes:

<Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from <.example.com> </Location>

Reemplace <.example.com> con el nombre de dominio de segundo nivel para el servidor Web.

Para proporcionar informes de configuración del servidor (incluyendo los módulos instalados y las directrices de configuración) a peticiones desde dentro del dominio, utilice las siguientes directrices:

<Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from <.example.com> </Location>

Una vez más, reemplace <.example.com> con el nombre del dominio de segundo nivel para el servidor Web.

LogFormat

La directriz LogFormat configura el formato para los archivos de registro del servidor Web. El comando LogFormat utilizado en realidad depende de la configuración dada en la directriz CustomLog (consulte la CustomLog).

Las siguientes son las opciones de formato si la directriz CustomLog es configurada a combined:

%h (dirección IP del host remoto o nombre de la máquina)

Lista la dirección IP de la máquina remota del cliente solicitante. Si HostnameLookups es configurada a on, el nombre de máquina del cliente es registrado a menos que no este disponible desde el DNS.

%l (rfc931)

No se usa. Un guión - aparece en el campo de registro para este campo.

%u (usuario autenticado)

Si se requiere autenticación, lista el nombre del usuario registrado. Usualmente, esto no se utiliza, por tanto aparece un guión - en el archivo de registro para este campo.

%t (fecha)

Lista la fecha y hora de la solicitud.

%r (cadena de la solicitud)

Lista la cadena de la solicitud exactamente como viene del navegador o cliente.

%s (estado)

Lista el estado de código HTTP el cual fue devuelto al host cliente.

%b (bytes)

Lista el tamaño del documento.

%\"%{Referer}i\" (referencia)

Lista la dirección URL de la página web que refiere el máquina cliente al servidor Web.

%\"%{User-Agent}i\" (agente usuario)

Lista el tipo de navegador Web que está realizando la solicitud.

LogLevel

LogLevel establece la cantidad de detalles que tendrán los registros de mensajes de error. LogLevel se puede configurar (desde el que tiene menos detalles a los más detallados) a emerg, alert, crit, error, warn, notice, info o debug. El valor predeterminado de LogLevel es warn.

MaxKeepAliveRequests

Esta directriz establece el número máximo de peticiones permitidas por cada conexión persistente. El Proyecto Apache recomienda un valor alto, lo que mejoraría el rendimiento del servidor. El valor predeterminado de MaxKeepAliveRequests es de 100 que debería bastar en la mayoría de los casos.

NameVirtualHost

La directriz NameVirtualHost asocia una dirección IP y el número de puerto, si es necesario, para cualquier máquina virtual basada en nombres. El hospedaje virtual basado en nombres permite a un Servidor HTTP Apache servir a dominios diferentes sin utilizar múltiples direcciones IP.

Nota

Los hosts virtuales basados en nombre only funcionan con conexiones HTTP no seguras. Si está usando host virtuales con un servidor seguro, use host virtuales basados en direcciones IP.

Para habilitar el hospedaje basado en nombres, quite los comentarios de la directriz de configuración NameVirtualHost y añada la dirección IP correcta. Luego añada más contenedores VirtualHost para cada host virtual como sea necesario para su configuración.

Options

La directriz Options controla cuáles características del servidor están disponibles en un directorio en particular. Por ejemplo, en los parámetros restrictivos especificados para el directorio raíz, Options sólo permite FollowSymLinks. No hay características activadas, salvo que el servidor puede seguir enlaces simbólicos en el directorio raíz.

Por defecto, en el directorio DocumentRoot, Options se configura para incluir Indexes y FollowSymLinks. Indexes permite al servidor generar un listado de un directorio si no se especifica el DirectoryIndex (por ejemplo, index.html). FollowSymLinks permite al servidor seguir enlaces simbólicos en ese directorio.

Nota

Se tienen que duplicar las declaraciones Options de la sección principal de configuración del servidor para cada contenedor VirtualHost individualmente. Consulte la VirtualHost para obtener mayor información.

Order

La directriz Order controla el orden en el cual las directrices allow y deny son evaluadas. El servidor es configurado para evaluar las directrices Allow antes de las directrices Deny para el directorio DocumentRoot.

PidFile

PidFile nombra el archivo en el que el servidor graba su ID de proceso (pid). Por defecto, el PID es listado en /var/run/httpd.pid.

Proxy

Las etiquetas <Proxy *> y </Proxy> crean un contenedor el cual envuelve un grupo de directrices de configuración solamente para aplicar al servidor proxy. Muchas directrices las cuales son permitidas dentro del contenedor <Directory> pueden también ser usadas dentro del contenedor <Proxy>.

ProxyRequests

Para configurar el Servidor HTTP Apache para que funcione como un servidor proxy, elimine las marcas de almohadillas o numeral (#) del comienzo de la línea <IfModule mod_proxy.c>, las ProxyRequests y cada línea en la estrofa <Proxy>. Configure la directriz ProxyRequests aOn y configure cuáles dominios tienen acceso al servidor en la directriz Allow from de la estrofa <Proxy>.

ReadmeName

La directriz ReadmeName determina el archivo (si existe dentro del directorio) que se adjuntará a los listados de los directorios. El servidor Web intentará primero incluirlo como documento HTML y luego como texto plano. El valor predeterminado de ReadmeName es README.html.

Redirect

Cuando se mueve una página web, se puede utilizar Redirect para crear asignaciones de la ubicación del archivo a un nuevo URL. El formato es como sigue:

Redirect /<old-path>/<file-name> http://<current-domain>/<current-path>/<file-name>

En este ejemplo, sustituya <old-path> con la vieja información de la ruta por <file-name> y <current-domain> y <current-path> con el dominio actual y la información de la ruta para <file-name>.

En este ejemplo, cualquier petición <file-name> en la vieja ubicación será redirigida automáticamente a la nueva ubicación.

Para técnicas de redireccionamiento más avanzadas, utilice el módulo mod_rewrite incluido con el Servidor HTTP Apache. Para obtener más información sobre la configuración del módulo mod_rewrite refiérase a la documentación de la Apache Software Foundation en http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html.

ScriptAlias

La directriz ScriptAlias define donde pueden encontrarse los scripts CGI. Normalmente, no es una buena idea colocar los scripts CGI dentro de DocumentRoot, donde podrían, potencialmente, ser visualizados como documentos de texto. Por esta razón, la directriz ScriptAlias diseña un directorio especial fuera del directorio DocumentRoot para contener ejecutables del servidor y scripts. Este directorio es conocido como un cgi-bin y se configura por defecto a /var/www/cgi-bin/.

Es posible establecer directorios para almacenar ejecutables fuera del directorio cgi-bin/. Para obtener más instrucciones sobre cómo hacer esto refiérase a la AddHandler and Directory.

ServerAdmin

Configure la directriz ServerAdmin a la dirección de correo electrónico del administrador del servidor Web. Esta dirección de correo aparecerá en los mensajes de error en las páginas generadas por el servidor Web, de tal manera que los usuarios pueden comunicar errores enviando correo al administrador.

Por defecto, ServerAdmin es configurado a root@localhost.

Una forma típica de configurar ServerAdmin es configurarlo en a webmaster@ejemplo.com. Una vez configurado, cree un alias del webmaster para la persona responsable del servidor Web en /etc/aliases y ejecute /usr/bin/newaliases.

ServerName

Use la directriz ServerName para configurar un nombre de servidor y un número de puerto (que coincida con la directriz Listen) para el servidor. El ServerName no necesita coincidir con el nombre real de la máquina. Por ejemplo, el servidor Web puede ser www.example.com pero el nombre del servidor es en realidad foo.example.com. El valor especificado en ServerName debe ser un nombre del Servicio de Nombres de Dominio (Domain Name Service, DNS) válido que pueda ser resuelto por el sistema — no invente algo.

Lo siguiente es una directriz ServerName de ejemplo:

ServerName www.example.com:80

Cuando especifique un ServerName, asegúrese de que el par de la dirección IP y el nombre del servidor esten incluidos en el archivo /etc/hosts.

ServerRoot

La directriz ServerRoot especifica el directorio de nivel superior que tiene el contenido web. Por defecto, ServerRoot está configurado a "/etc/httpd" para servidores seguros y no seguros.

ServerSignature

La directriz ServerSignature añade una línea que contiene la versión del Servidor HTTP Apache y el ServerName para cualquier documento generado por el servidor, tales como mensajes de error devueltos a los clientes. Por defecto ServerSignature está configurada a on.

ServerSignature se puede configurar como EMail el cual añade una etiqueta HTML mailto:ServerAdmin a la línea de firma de respuestas auto generadas. También se puede configurar como Off para que Apache pare de enviar su número de versión y la información del módulo. Revise también la configuración de ServerTokens.

ServerTokens

La directriz ServerTokens determina si el encabezamiento de la respuesta del servidor que se devuelve al cliente debe incluir detalles sobre el tipo de Sistema Operativo e información sobre los módulos compilados. Por defecto, ServerTokens se encuentra configurado como Full y por tanto envía información sobre el tipo del Sistema Operativo y lo módulos compilados. Al configurar ServerTokens como Prod envía el nombre del producto sólamente y se recomienda un buen número de hackers revise la información en el encabezamiento del servidor en la búsqueda de vulnerabilidades. También puede configurar ServerTokens como Min (minimal) o como OS (sistema operativo).

SuexecUserGroup

La directriz SuexecUserGroup, que se origina desde el módulo mod_suexec, permite especificar privilegios de ejecución de usuario y grupo para programas CGI. Las solicitudes no CGI también son procesadas con el usuario y el grupo especificado en las directrices User y Group.

Nota

Desde la versión 2.0, la directriz SuexecUserGroup reemplaza la configuración del Servidor HTTP Apache versión 1.3 de utilizar las directrices User y Group dentro de la configuración de las secciones VirtualHosts.

Timeout

Timeout define, en segundos, el tiempo que el servidor esperará por recibir y transmitir durante la comunicación. Timeout está configurado por defecto a 300 segundos, lo cual es apropiado para la mayoría de las situaciones.

TypesConfig

TypesConfig nombra el archivo que configura la lista por defecto de asignaciones tipo MIME (extensiones de nombres de archivo a tipos de contenido). El archivo predeterminado TypesConfig es /etc/mime.types. En vez de modificar el /etc/mime.types, la forma recomendada de añadir asignaciones de tipo MIME es usando la directriz AddType.

Para obtener más información sobre AddType refiérase a la AddType.

UseCanonicalName

Cuando se configure esta directriz como on, se está indicando al Servidor HTTP Apache a que se referencie asímismo utilizando el valor especificado en las directrices ServerName y Port. Cuando UseCanonicalName es configurada como off, el servidor usará el valor usado por el cliente solicitante cuando se refiera a él.

UseCanonicalName está configurada a off por defecto.

User

La directriz User establece el nombre de usuario para el proceso del servidor y determina qué archivos pueden acceder al servidor. Cualquier archivo que no esté accesible a este usuario tampoco estará disponible para los clientes conectándose al Servidor HTTP Apache.

Por defecto User es configurado a apache.

Esta directriz se ha desaprobado para la configuración de hosts virtuales.

Nota

Por razones de seguridad, el Servidor HTTP Apache no se ejecuta como el usuario root.

UserDir

UserDir es el nombre del subdirectorio dentro del directorio principal de cada usuario dónde estarán los archivos HTML personal que serán servidos por el servidor de Web. Esta directriz esta configurada por defecto a disable.

El nombre para el subdirectorio esta configurado a public_html en la configuración por defecto. Por ejemplo, el servidor puede recibir la siguiente petición:

http://example.com/~username/foo.html

El servidor buscará por el archivo:

/home/username/public_html/foo.html

En el ejemplo de arriba, /home/username/ es el directorio principal del usuario (observe que la ruta por defecto al directorio principal del usuario puede variar).

Hay que asegurarse que los permisos de los directorios principales de usuario esten configurados correctamente. El valor de los permisos deben ser de 0711. Los bits de lectura (r) y ejecución (x) deben estar activados en el directorio del usuario public_html (0755 también funcionará). Los archivos servidos en un directorio principal de usuario public_html debe estar configurados, por lo menos, a 0644.

VirtualHost

Las etiquetas <VirtualHost> y </VirtualHost> crean un contenedor mostrando las características de un host virtual. El contenedor VirtualHost acepta la mayoría de las directrices de configuración.

Se proporciona un contenedor VirtualHost en comentarios en httpd.conf, el cual ilustra el conjunto mínimo de directrices de configuración necesarias para cada host virtual. Refiérase a la Sección 22.7, “Hosts virtuales” para obtener más información sobre los host virtuales.

Nota

El contenedor de host virtuales SSL por defecto reside en el archivo /etc/httpd/conf.d/ssl.conf.

22.5.2. Configuración de directrices para SSL

Las directrices en el archivo /etc/httpd/conf.d/ssl.conf se pueden configurar para activar las comunicaciones Web seguras usando SSL y TLS.

SetEnvIf

SetEnvIf configura las variables del entorno basado en las cabeceras de las conexiones entrantes. No es una directriz únicamente de SSL, aunque se presenta en el archivo /etc/httpd/conf.d/ssl.conf. En este contexto, su propósito es desactivar el keepalive del HTTP y permitir a SSL cerrar la conexión sin una alerta de notificación desde el navegador del cliente. Esta configuración es necesaria para ciertos navegadores que no cierran de forma confiable la conexión SSL.

Para más información sobre otras directrices dentro del archivo de configuración SSL, consulte los siguientes URLs:

Nota

En la mayoría de los casos, las directrices SSL son configuradas apropiadamente durante la instalación de Red Hat Enterprise Linux. Tenga cuidado cuando altere las directrices del Servidor Seguro HTTP de Apache pues un error en la configuración puede provocar que el servidor sea vulnerable en términos de seguridad.

22.5.3. Directrices MPM específicas al pool de servidores

Como se explicó en la Sección 22.2.2.1.2, “Regulación del tamaño del pool de servidores” la responsabilidad del manejo de las características del pool de servidores recae sobre un grupo de módulos llamado MPMs bajo el Servidor HTTP Apache versión 2.0. Las características del pool de servidores difieren dependiendo de cual MPM se utiliza. Por esta razón, es necesario un contenedor IfModule para poder definir el pool de servidores del MPM en uso.

Por defecto, el Servidor HTTP Apache 2.0 define el pool de servidores para ambos MPMs: prefork y worker.

La sección siguiente lista las directrices encontradas dentro de los contenedores del pool de servidores específicos al MPM.

MaxClients

La directriz MaxClients establece un límite en el número total de procesos del servidor o clientes conectados simultáneamente que se pueden ejecutar a la vez. El propósito principal de esta directriz es prevenir que un Servidor HTTP Apache descontrolado vuelva inestable el sistema operativo. Para los servidores muy ocupados este valor debería ser un valor alto. El valor por defecto es 150, sin importar el MPM que se utilice. Sin embargo, no se recomienda que el valor del comando MaxClients supere 256 cuando se utilice el MPM prefork.

MaxRequestsPerChild

MaxRequestsPerChild establece el número máximo de peticiones que cada proceso de servidor hijo procesa antes de morir. La principal razón para configurar MaxRequestsPerChild es evitar que procesos de larga vida gasten memoria. El valor predeterminado de MaxRequestsPerChild para el MPM prefork es de 4000 y, para el MPM worker, es 0.

MinSpareServers y MaxSpareServers

Estos valores solamente se utilizan con el MPM prefork. Ellos ajustan como el Servidor HTTP Apache se adapta dinámicamente a la carga percibida manteniendo un número apropiado de procesos de servidor extras o de repuesto basado en el número de peticiones entrantes. El servidor comprueba el número de servidores que esperan peticiones y elimina algunos si el número es más alto que MaxSpareServers o crea algunos si el número de servidores es menor que MinSpareServers.

El valor predeterminado de MinSpareServers es 5 y el de MaxSpareServers es 20. Estos valores predeterminados son suficientes en la mayoría de los casos. Tenga cuidado de no incrementar el número de MinSpareServers a un número muy elevado ya que creará una gran carga de procesamiento, incluso cuando el tráfico fuese bajo.

MinSpareThreads y MaxSpareThreads

Estos valores solamente son utilizado con el MPM worker. Ellos ajustan como el Servidor HTTP Apache se adapta dinámicamente a la carga percibida manteniendo un número apropiado de hilos de servidores extras basado en el número de peticiones entrantes. El servidor comprueba el número de hilos de servidores que esperan peticiones y elimina algunos si el número es más alto que MaxSpareThreads o crea algunos si el número de servidores es menor que MinSpareThreads.

El valor predeterminado de MinSpareThreads es 25 y el de MaxSpareThreads es 75. Estos valores predeterminados son apropiados en la mayoría de los casos. El valor para MaxSpareThreads debe ser mayor o igual que la suma de MinSpareThreads y ThreadsPerChild, de lo contrario el Servidor HTTP Apache lo corregirá automáticamente.

StartServers

La directriz StartServers establece cuántos procesos de servidor serán creados al arrancar. Ya que el servidor Web crea y elimina dinámicamente procesos de servidor según el tráfico, no se necesitará cambiar este parámetro. El servidor web está configurado para arrancar 8 procesos del servidor al arrancar para el MPM prefork y 2 para el MPM worker.

ThreadsPerChild

Este valor solamente es utilizado con el MPM worker. Configura el número de hilos dentro de cada proceso hijo. El valor por defecto para esta directriz es 25.

22.6. Añadir módulos

El Servidor HTTP Apache se distribuye con un número de módulos. Para obtener más información sobre los módulos HTTP Apache diríjase a http://httpd.apache.org/docs/2.2/mod/.

El Servidor HTTP Apache soporta Objetos Compartidos Dinámicamente (Dynamically Shared Objects, DSOs) o módulos, los cuales se pueden cargar fácilmente en el momento de ejecución.

El Proyecto Apache proporciona Documentación DSO completa en línea en http://httpd.apache.org/docs/2.2/dso.html. Si el paquete http-manual está instalado, se puede encontrar documentación sobre DSOs en http://localhost/manual/mod/.

Para que el Servidor HTTP Apache utilice un DSO, debe estar especificado en una directriz LoadModule dentro de /etc/httpd/conf/httpd.conf; si el módulo es proporcionado por un paquete separado, la línea debe aparecer dentro del archivo de configuración de módulos en el directorio /etc/httpd/conf.d/. Refiérase a la LoadModule para obtener más información.

Si está añadiendo o eliminando módulos desde http.conf, debe recargar o volver a iniciar el Servidor HTTP Apache como se explica en la Sección 22.3, “Arrancar y detener httpd.

Si está creando un nuevo módulo, instale primero el paquete httpd-devel pues contiene los archivos include, las cabeceras de archivos así como también la aplicación APache eXtenSion (/usr/sbin/apxs), la cual utiliza los archivos include y las cabeceras para compilar DSOs.

Después de escribir un módulo, utilice /usr/sbin/apxs para compilar las fuentes del módulo fuera del árbol de fuentes Apache. Para obtener más información sobre el uso del comando /usr/sbin/apxs, vea la documentación de Apache en línea en http://httpd.apache.org/docs/2.2/dso.html y en la página man de apxs.

Una vez compilado, coloque el módulo en el directorio /usr/lib/httpd/modules/. Para las plataformas RHEL que utilizan el espacio de usuario de 64 bits predeterminado (x86_64, ia64, ?) esta ruta será /usr/lib64/httpd/modules/. Luego añada una línea LoadModule al archivo httpd.conf usando la siguiente estructura:

LoadModule <module-name> <path/to/module.so>

Donde <module-name> es el nombre del módulo y <path/to/module.so> a la ruta del DSO.

22.7. Hosts virtuales

La característica incorporada del Servidor HTTP Apache de máquinas virtules permite al servidor rpoporcionar diferente información basado en cuál dirección IP, nombre de host o puerto está siendo solicitado. Un manual completo para el uso de hosts virtuales está disponible en http://httpd.apache.org/docs/2.2/vhosts/.

22.7.1. Configuración de máquinas virtuales

Para crear un host virtual basado en nombre, lo mejor es utilizar el contenedor del host virtual proporcionado en httpd.conf como un ejemplo.

El ejemplo de máquina virtual se lee como sigue:

#NameVirtualHost *:80 # #<VirtualHost *:80> # ServerAdmin webmaster@dummy-host.example.com # DocumentRoot /www/docs/dummy-host.example.com # ServerName dummy-host.example.com # ErrorLog logs/dummy-host.example.com-error_log # CustomLog logs/dummy-host.example.com-access_log common #</VirtualHost>

Para activar máquinas virtuales basadas en nombre, quite los comentarios de la línea NameVirtualHost eliminando el símbolo de numeral o almohadilla (#) y reemplazando el asterísco (*) con la dirección IP asignada a la máquina.

Luego, configure un host virtual, quitando los comentarios y personalizando el contenedor <VirtualHost>.

En la línea <VirtualHost>, cámbie el asterísco (*) a la dirección IP del servidor. Cambie el ServerName al nombre DNS válido asignado a la máquina y configure las otras directrices si es necesario.

El contenedor <VirtualHost> es altamente personalizable y acepta casi cada directriz dentro de la configuración del servidor principal.

Sugerencia

Si se está configurando un host virtual para que escuche en un puerto no predeterminado, se debe agregar ese puerto a la directriz Listen en la sección de configuraciones globales del archivo /etc/httpd/conf/http.conf.

Para activar un host virtual creado recientemente, el Servirdor HTTP Apache se debe volver a cargar o a reiniciar. Consulte la Sección 22.3, “Arrancar y detener httpd para ver las instrucciones sobre como hacer esto.

Se proporciona información completa sobre la creación y configuración de máquinas virtuales basadas en nombre y en dirección IP en http://httpd.apache.org/docs/2.2/vhosts/.

22.8. Configuración del Servidor Seguro Apache HTTP

Este capítulo proporciona información básica sobre SErvidor HTTP Apache con el módulo de seguridad mod_ssl activado para utilizar las bibliotecas y el conjunto de herramientas de OpenSSL. La combinación de estos tres componentes se conocen en este capítulo como el servidor Web seguro o simplemente como el servidor seguro.

El módulo mod_ssl es un módulo de seguridad para el Servidor HTTP Apache. El módulo mod_ssl utiliza las herramientas proporcionadas por el Proyecto OpenSSL para añadir una característcia muy importante al Servidor HTTP Apache— la habilidad de encriptar comunicaciones. Por el contrario, las comunicaciones HTTP comunes entre un navegador y un servidor Web se envían en texto plano, el cual lo puede interceptar y leer alguien en la ruta entre el navegador y el servidor.

Este capítulo no está diseñado para ser una guía completa de ninguno de estos programas. Siempre que sea posible, esta guía le indicará los lugares apropiados en donde puede encontrar información más detallada sobre estos temas.

Este capítulo le mostrará como instalar estos programas. También aprenderá los pasos necesarios para generar una clave privada y una petición de certificado, cómo generar su propio certificado firmado, y cómo instalar un certificado para usarlo con su servidor web seguro.

El archivo de configuración mod_ssl se encuentra en /etc/httpd/conf.d/ssl.conf. Para cargar este archivo y hacer que mod_ssl funcione tiene que tener la declaración Include conf.d/*.conf en el archivo /etc/httpd/conf/httpd.conf. Esta declaración esta incluída por defecto en el archivo de configuración predeterminado del Servidor HTTP Apache.

22.8.1. Vista preliminar de los paquetes relacionados con la seguridad

Para habilitar el servidor seguro tiene que tener los siguientes paquetes instalados como mínimo:

httpd

El paquete httpd contiene el demonio httpd y herramientas relacionadas, archivos de configuración, iconos, módulos del Servidor HTTP Apache, páginas man y otros archivos qu el Servidor HTTP apache utiliza.

mod_ssl

El paquete mod_ssl incluye el módulomod_ssl que proporciona criptografía fuerte para el Servidor HTTP Apache a través de los protocolos SSL, Secure Sockets Layer y TLS, Transport Layer Security.

openssl

El paquete openssl contiene el kit de herramientas OpenSSL. Este kit implementa los protocolos SSL y TLS y también incluye una biblioteca criptográfica de uso general.

Adicionalmente, otros paquetes de software pueden proporcionar ciertas funcionalidades de seguridad (pero que no son requeridas para que funcione el servidor seguro):

22.8.2. Vista preliminar de certificados y seguridad

Su servidor seguro proporciona seguridad utilizando una combinación del protocolo SSL (del inglés Secure Sockets Layer) y (en la mayoría de los casos) un certificado digital de una Autoridad de Certificación (AC). SSL aneja la comunicación encriptada así como la autenticación mutua entre los navegadores y su servidor seguro. El certificado digital AC aprobado proporciona autenticación para su servidor seguro (el AC pone su reputación detras de su certificación de la identidad de su organización). Cuando su navegador se comunica utilizando el ncriptamiento SSL, se utiliza el prefijo https:// al comienzo del Localizador Unificado de Recursos (URL por sus siglas en inglés) en la barra de navegación.

La encriptación depende del uso de claves (imagínelas como anillos codificador/decodificador en formato de datos). En criptografía convencional o simétrica, ambas partes de la transacción tienen la misma clave, la cual usan para decodificar la transmisión del otro. En criptografía pública o asimétrica, coexisten dos claves: una pública y una privada. Una persona o una organización guarda su clave privada en secreto, y publica su clave pública. Los datos codificados con la llave pública sólo pueden ser decodificados con la clave privada; y los datos codificados con la clave privada sólo pueden ser decodificados con la llave pública.

Para configurar su servidor seguro, usará criptografía pública para crear un par de claves pública y privada. En muchos casos, enviará su petición de certificado (incluyendo su clave pública), demostrando la identidad de su compañía y pago a la CA. La CA verificará la petición del certificado y su identidad, y entonces mandará un certificado para su servidor seguro.

Un servidor seguro usa un certificado para identificarse a sí mismo a los navegadores web. Puede generar su propio certificado (llamado certificado autofirmado) o puede conseguirlo de una Autoridad de Certificación o CA. Un certificado de una CA con buena reputación garantiza que un sitio web está asociado a una compañía u organización particular.

De otra forma puede crear su propio certificado auto-firmado. Sin embargo, observe que estos certificados auto-firmados no se deben utilizar en la mayoría de los entornos de producción. Los certificados auto-firmados no son aceptados automáticamente por el usuario de un navegador — el navegaodr le pide a los usuarios que acepte el certificado y que cree una conexión segura. Para obtener más información sobre las diferencias entre certificados auto-firmados y los firmados por ACs vaya a Sección 22.8.4, “Tipos de certificados”.

Una vez que haya obtenido un certificado auto-firmado o un certificado firmado del AC que haya escogido, tiene que instalarlo en su servidor seguro.

22.8.3. Uso de claves y certificados preexistentes

Si ya tiene una llave y un certificado (por ejemplo si está instalando el servidor seguro para reemplazar el producto del servidor seguro de otra compañia), probablemente podrá utilizar su llave y cetificado existentes con el servidor seguro. Las siguientes dos situaciones proporcionan ejemplos de cuando ustes no puede utilizar su certificado o llave extistentes:

  • Si está cambiando su dirección IP o su nombre de dominio — No podrá usar su vieja clave y certificado si está cambiando la dirección IP o el nombre de dominio. Los certificados se emiten para un par concreto de dirección IP y nombre de dominio. Necesitará un nuevo certificado si los cambia.

  • Si tiene un certificado de VeriSign y está cambiando el software de su servidor — VeriSign es un CA ampliamente usado. Si ya tiene un certificado VeriSign para otro propósito, puede estar considerando usar su certificado VeriSign existente con su nuevo servidor seguro. Sin embargo, no podrá hacerlo, ya que los certificados VeriSign se emiten para un software servidor determinado y una combinación de dirección IP y nombre de dominio.

    Si cambia uno de estos parámetros (por ejemplo, si previamente ha usado otro producto de servidor web seguro, el certificado VeriSign que obtuvo para usar con la configuración previa, no funcionará con la nueva configuración. Necesitará obtener un nuevo certificado.

Si ya tiene una clave y un certificado existente que quiera usar, no tendrá que generar una nueva clave ni obtener un nuevo certificado. Sin embargo, necesitará mover y renombrar los archivos que contienen su clave y su certificado.

Mueva su archivo de claves existente a:

/etc/pki/tls/private/server.key

Mueva su archivo de certificado existente a:

/etc/pki/tls/certs/server.crt

Si está actualizando desde el Servidor Web Seguro de Red Hat, su vieja clave (httpsd.key) y certificado (httpsd.crt) estarán localizados en /etc/httpd/conf/. Necesitará moverlos y renombrarlos para que el servidor seguro pueda usarlos. Utilize los siguientes dos comandos para hacerlo:

mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/server.key mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/server.crt

Después inicie su servidor seguro con el comando:

/sbin/service httpd start

22.8.4. Tipos de certificados

Si ha instalado su servidor seguro desde el paquete RPM proporcionado por Red Hat se genera una llave aleatoria y un certificado de prueba y son puestos en sus directorios apropiados. Sin embargo, antes de que empiece a usar su servidor seguro necesitará generar su propia llave y obtener un certificado que identifique correctamente su servidor.

Necesita una llave y un certificado para operar su servidor seguro — lo cual significa que puede generar un certificado autofirmado o adquirir uno firmado por una CA. ¿Cuáles son las diferencias entre los dos?

Un certificado firmado por una CA proporciona dos importantes capacidades para su servidor:

  • Los navegadores (normalmente) reconocen automáticamente el certificado y permiten establecer la conexión segura sin preguntar al usuario.

  • Cuando una CA emite un certificado firmado, ellos garantizan la identidad de la organización que está proporcionando las páginas web al navegador.

Si a su servidor seguro está siendo accesado por todo el mundo, necesitará un certificado firmado por una CA, así la gente que acceda a su sitio web sabrá que dicho sitio es propiedad de la organización que proclama ser la dueña. Antes de firmar un certificado, una CA verifica que la organización peticionaria de dicho certificado es realmente quien proclama ser.

Muchos navegadores web que soportan SSL tienen una lista de CAs cuyos certificados admiten automáticamente. Si el navegador encuentra un certificado autorizado por una CA que no está en la lista, el navegador preguntará al usuario si desea aceptar o rechazar la conexión.

Puede generar un certificado auto-firmado para su servidor seguro pero tenga en cuenta de que un certificado auto-firmado no proporciona la misma funcionalidad que un certificado firmado por un AC. Un certificado auto-firmado no es reconocido automáticamente por la mayoría de los navegadores y no proporciona ninguna garantía en realción con la identidad de la organización que proporciona el sitio web. UN certificado firmado por un AC proporciona estas dos habilidades tan importantes para un servidor seguro. Si va a utilizar su servidor seguro en un entorno de producción se recomienda que tenga un certificado firmado por AC.

El proceso para conseguir un certificado de una CA es bastante sencillo. A continuación un vistazo rápido a dicho proceso:

  1. Crear un par de claves encriptadas, pública y privada.

  2. Crear una petición de certificado basada en la clave pública. La petición contiene información sobre su servidor y la compañía que lo hospeda.

  3. Envíe el pedido de certificado junto con los documentos que prueban su identidad a AC. Red Hat no hace recomendaciones sobre el tipo de autoridad de certificado que debe escoger. Su decisión debe estar basada en experiencias previas, experiencias de amigos o colegas o incluso en factores monetarios.

    Una vez que haya decidido por un CA, necesitará seguir las instrucciones que se le indiquen para obtener un certificado de ellos.

  4. Cuando la AC se encuentra satisfecha con su presumible identidad ellos le proporcionarán un certificado digital.

  5. Instale este certificado en su servidor seguro y comience a manejar transacciones seguras.

Ya sea que usted vaya a adquirir un certificado de una AC o vaya a generar su propio certificado auto-firmado, el primer paso es generar una llave. Refiérase a Sección 22.8.5, “Generar una clave” para obtener las instrucciones.

22.8.5. Generar una clave

Tiene que ser root para generar una clave.

Primero, utilice el comando cd para cambiar al directorio /etc/httpd/conf/. Con los siguientes comandos elimine la llave y el certificado falso que se generaron durante la instalación:

rm ssl.key/server.keyrm ssl.crt/server.crt

El paquete crypto-utils contiene la herramienta genkey, la cual se puede utilizar para generar llaves, así como lo implica su nombre. Para crear su propia llave privada asegúrese de que el paquete crypto-utils se encuentre instalado. Puede encontrar más opciones si escribe man genkey en su terminal. Asumiendo de que usted quiere generar llaves para www.example.com utilizando la herramienta genkey escriba el siguiente comando en su terminal:

genkey www.example.com

Observe que el proceso basado en make ya no se incluye junto con RHEL 5. Esto iniciará la interfaz gráfica de usuario genkey. La figura que se encuentra a continuación ilustra la primera pantalla. Para navegar utilice las flechas y tab. Estas ventanas indican en donde se almacenará su llave y le preguntará si desea continuar o cancelar la operación. Para proceder al siguiente paso seleccione Siguiente y oprima la tecla Intro.

Generación del Keypair

Generación del Keypair

Figura 22.11. Generación del Keypair

La siguiente pantalla le pedirá que seleccione el tamaño de su llave. Como se indicó anteriormente entre más pequeña sea su llave recibirá más rápido respuesta de su servidor y su nivel de seguridad será menor. Utilice las flechas para seleccionar el tamaño de la llave y haga clic en Siguiente para proceder al siguiente paso. La figura a continuación ilustra la pantalla de selección del tamaño de la llave.

Selección del tamaño de la llave

Seleccione el tamaño de la llave

Figura 22.12. Selección del tamaño de la llave

Al seleccionar el siguiente paso se iniciará el proceso de generación de bits que puede llegar a tomar un poco de tiempo dependiendo del tamaño de la llave que seleccionó. Entre más grande sea su llave más tiempo se tomará en generarla.

Generación de bits aleatorios

Generación de bits aleatorios

Figura 22.13. Generación de bits aleatorios

Al generar su llave se le pedirá que envie un Pedido de Certificado a una Autoridad de Certificación (AC).

Generar CSR

Generar CSR

Figura 22.14. Generar CSR

Al seleccionar le pedirá que seleccione la Autoridad de Certificación a la cual usted le desea enviar la petición. Al seleccionar No le permitirá generar un certificado auto-firmado. El siguiente paso se encuentra ilustrado en Figura 22.17, “Generación de un certificado auto-firmado para su servidor”.

Seleccionar una Autoridad de Certificación (AC)

Seleccione una Autoridad de Certificación (AC)

Figura 22.15. Seleccionar una Autoridad de Certificación (AC)

En Selección de su opción preferida escoja Siguiente para proceder al siguiente paso. La siguiente pantalla le permititrá ingresar los detalles de su certificado.

Ingrese los detalles para su certificado

Ingrese los detalles para su certificado

Figura 22.16. Ingrese los detalles para su certificado

Si prefiere generar un par de claves con un certificado de auto-firma no debe generar un CSR. Para hacer esto, selccione No como su opción prefeerida en la pantalla para Generación de CSR. Esto le presentará la siguiente figura desde la cual usted puede ingresar los detalles de su certificado. Al ingresar estos detalles y al oprimir la tecla intro verá la Figura 22.19, “Protección de su llave privada” desde donde puede escoger el encriptar o no su llave privada.

Generación de un certificado auto-firmado para su servidor

Generación de un certificado auto-firmado para su servidor

Figura 22.17. Generación de un certificado auto-firmado para su servidor

Al ingresar los detalles de su certificado seleccione Siguiente para continuar. La figura que se encuentra a continuación ilustra un ejemplo de la pantalla siguiente que aparecerá después de completar los detalles para un certificado que se va a enviar a Equifax. Observe que esta pantalla no aparecerá si se encuentra generando una llave auto-firmada para su servidor.

Inicie pedido de certificado

Inicie pedido de certificado

Figura 22.18. Inicie pedido de certificado

Al oprimir la tecla intro aparecerá la siguiente pantalla desde la cual puede habilitar o deshabilitar la opción de encriptar la llave privada. Utilice la barra espaciadora para escoger. Cuando se encuentra habilitada aparecerá un caracter [*]. Al seleccionar su opción preferida seleccione Siguiente para continuar al siguiente paso.

Protección de su llave privada

Protección de su llave privada

Figura 22.19. Protección de su llave privada

La siguiente pantalla le permitirá configurar la contraseña de la llave.

Configurar contraseña

Configurar contraseña

Figura 22.20. Configurar contraseña

Si trata de ejecutar genkey makeca en un servidor que ya tiene una pareja de llaves existentes aparecerá un mensaje de error como se ilustra a continuación. Necesita borrar su archivo de llave existente como se indica para poder generar un nuevo par de llaves.

genkey error

genkey error

Figura 22.21. genkey error

22.8.6. Cómo configurar el servidor para utilizar la nueva clave

Los pasos para configurar el Servidor HTTP Apache para poder utilizar la nueva llave son los siguientes:

  • Obtenga el certificado firmado del AC después de enviar el CSR.

  • Copie el certificado a la ruta, por ejemplo /etc/pki/tls/certs/www.example.com.crt

  • Modifique /etc/httpd/conf.d/ssl.conf. Cambie las líneas del SSLCertificateFile y SSLCertificateKey para que reflejen:

    SSLCertificateFile /etc/pki/tls/certs/www.example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/www.example.com.key
    

    en donde la parte "www.example.com" debe concordar con el argumento pasado en el comando genkey.

22.9. Recursos adicionales

Para mayor información sobre el Servidor HTTP Apache consulte los siguientes recursos:

22.9.1. Sitios Web de utilidad

Capítulo 23. FTP

El Protocolo de transferencia de archivos (FTP) es uno de los protocolos más viejos y populares que se encuentran en la Internet hoy día. Su objetivo es el de transmitir archivos exitósamente entre máquinas en una red sin que el usuario tenga que iniciar una sesión en el host remoto o que requiera tener conocimientos sobre cómo utilizar el sistema remoto. FTP permite a los usuarios acceder a archivos en sistemas remotos usando un conjunto de comandos estándar muy simples.

Este capítulo describe los elementos básicos de este protocolo, así como también las opciones de configuración para el servidor FTP primario que se entrega con Red Hat Enterprise Linux, vsftpd.

23.1. El Protocolo de Transferencia de Archivos

Sin embargo, puesto que FTP está tan extendido en la Internet, se requiere a menudo para compartir archivos con el público. Por lo tanto, los administradores de sistemas deberían estar conscientes de las características únicas del protocolo FTP.

23.1.1. Puertos múltiples, modos múltiples

A diferencia de la mayoría de los protocolos utilizados en Internet, FTP requiere de múltiples puertos de red para funcionar correctamente. Cuando una aplicación cliente FTP inicia una conexión a un servidor FTP, abre el puerto 21 en el servidor — conocido como el puerto de comandos. Se utiliza este puerto para arrojar todos los comandos al servidor. Cualquier petición de datos desde el servidor se devuelve al cliente a través del puerto de datos. El número de puerto para las conexiones de datos y la forma en la que las conexiones son inicializadas varía dependiendo de si el cliente solicita los datos en modo activo o en modo pasivo.

A continuación se describen estos modos:

modo activo

El modo activo es el método original utilizado por el protocolo FTP para la transferencia de datos a la aplicación cliente. Cuando el cliente FTP inicia una transferencia de datos, el servidor abre una conexión desde el puerto 20 en el servidor para la dirección IP y un puerto aleatorio sin privilegios (mayor que 1024) especificado por el cliente. Este arreglo implica que la máquina cliente debe poder aceptar conexiones en cualquier puerto superior al 1024. Con el crecimiento de las redes inseguras, tales como Internet, es muy común el uso de cortafuegos para proteger las máquinas cliente. Debido a que estos cortafuegos en el lado del cliente normalmente rechazan las conexiones entrantes desde servidores FTP en modo activo, se creó el modo pasivo.

modo pasivo

La aplicación FTP cliente es la que inicia el modo pasivo, de la misma forma que el modo activo. El cliente FTP indica que desea acceder a los datos en modo pasivo y el servidor proporciona la dirección IP y el puerto aleatorio, sin privilegios (mayor que 1024) en el servidor. Luego, el cliente se conecta al puerto en el servidor y descarga la información requerida.

Mientras que el modo pasivo resuelve el problema de la interferencia del cortafuegos en el lado del cliente con las conexiones de datos, también puede complicar la administración del cortafuegos del lado del servidor. Una de las formas de limitar el número de puertos abiertos en el servidor es limitando el rango de puertos sin privilegios en el servidor FTP. Esta acción también simplificará la tarea de crear reglas para el cortafuegos del servidor. Consulte la Sección 23.5.8, “Opciones de red” para más detalles sobre cómo limitar puertos pasivos.

23.2. Servidores FTP

Red Hat Enterprise Linux se entrega con dos servidores FTP diferentes:

  • Acelerador de Contenidos Red Hat — Un servidor Web basado en el kernel que ofrece un servidor web y servicios FTP de alto rendimiento. Puesto que la velocidad es su objetivo principal de diseño, su funcionalidad es limitada y solamente se ejecuta como FTP anónimo. Para más información sobre la configuración y administración del Acelerador de Contenidos Red Hat, consulte la documentación disponible en línea en http://www.redhat.com/docs/manuals/tux/.

  • vsftpd — un demonio FTP rápido y seguro. Este es el preferido en Red Hat Enterprise Linux. El resto de este capítulo se enfoca en vsftpd.

23.2.1. vsftpd

El demonio FTP vsftpd (o Very Secure FTP Daemon) está diseñado desde sus fundamentos para ser rápido, estable y lo más importante, seguro. Su habilidad para manejar grandes números de conexiones de forma eficiente y segura es lo que hace que vsftpd sea el único FTP independiente distribuido con Red Hat Enterprise Linux.

El modelo de seguridad utilizado por vsftpd tiene tres aspectos principales:

  • Clara separación de procesos privilegiados y sin privilegios — Procesos separados manejan tareas diferentes y cada uno de estos procesos se ejecuta con los privilegios mínimos requeridos para la tarea.

  • Las tareas que requieren altos privilegios son manejadas por procesos con los mínimos privilegios necesarios — Influenciando las compatibilidades encontradas en la biblioteca libcap, las tareas que usualmente requieren privilegios de superusuario se pueden ejecutar de forma más segura desde un proceso menos privilegiado.

  • La mayoría de los procesos se ejecutan enjaulados en un ambiente chroot — Siempre que sea posible, se cambia la raíz de los procesos al directorio compartido; este directorio se considera luego como la jaula chroot. Por ejemplo, si el directorio /var/ftp/ es el directorio compartido principal, vsftpd reasigna /var/ftp/ al nuevo directorio raíz, conocido como /. Esto previene actividades maliciosas de cualquier hacker potencial en algún directorio que no estén por debajo del nuevo directorio root.

El uso de estas prácticas de seguridad tiene el efecto siguiente en cómo vsftpd trata con las peticiones:

  • El proceso padre se ejecuta con el mínimo de privilegios requerido — El proceso padre calcula dinámicamente el nivel de privilegios requerido para minimizar el nivel de riesgos. Los procesos hijo manejan la interacción directa con los clientes FTP y se ejecutan casi sin ningún privilegio.

  • Todas las operaciones que requieren altos privilegios son manejadas por un pequeño proceso padre — Similar a Servidor HTTP Apache, vsftpd lanza procesos hijos sin privilegios para manejar las conexiones entrantes. Esto permite al proceso padre privilegiado, ser tan pequeño como sea posible y manejar relativamente pocas tareas.

  • El proceso padre no confia en ninguna de las peticiones desde procesos hijos sin privilegios — Las comunicaciones con procesos hijos se reciben sobre un socket y la validez de cualquier información desde un proceso hijo es verificada antes de proceder.

  • La mayor parte de la interacción con clientes FTP la manejan procesos hijo sin privilegios en una jaula chroot. — Debido a que estos procesos hijo no tienen privilegios y solamente tienen acceso al directorio que está siendo compartido, cualquier proceso fallido solamente permitirá al atacante acceder a los archivos compartidos.

23.3. Archivos instalados con vsftpd

El RPM vsftpd instala el demonio (/usr/sbin/vsftpd), su archivo de configuración y otros archivos relacionados, así como también los directorios FTP en el sistema. La siguiente es una lista de los archivos y directorios considerados más a menudo cuando se configura vsftpd:

  • /etc/rc.d/init.d/vsftpd — El script de inicialización (initscript) utilizado por el comando /sbin/service para iniciar, detener o volver a cargar vsftpd. Consulte la Sección 23.4, “Iniciar y detener vsftpd para obtener mayor información sobre el uso de este script.

  • /etc/vsftpd/vsftpd.conf — El archivo de configuración para vsftpd. Consulte la Sección 23.5, “Opciones de configuración vsftpd para una lista de las opciones importantes que se encuentran en este archivo.

  • /etc/vsftpd.ftpusers — Una lista de los usuarios que no tienen permitido conectarse a vsftpd. Por defecto esta lista incluye a los usuarios root, bin y daemon, entre otros.

  • /etc/vsftpd.user_list — Este archivo se puede configurar para negar o permitir el acceso a los usuarios listados, dependiendo de si la directriz userlist_deny está configurada a YES (por defecto) o a NO en /etc/vsftpd/vsftpd.conf. Si se utiliza /etc/vsftpd.user_list para permitir acceso a los usuarios, los nombres de usuarios listados no deben aparecer en /etc/vsftpd.ftpusers.

  • El directorio /var/ftp/ — El directorio que contiene los archivos servidos por vsftpd. También contiene el directorio /var/ftp/pub/ para los usuarios anónimos. Ambos directorios están disponibles para la lectura de todos, pero sólo el superusuario o root puede escribir en el.

23.4. Iniciar y detener vsftpd

El RPM vsftpd instala el script /etc/rc.d/init.d/vsftpd, al cual se puede acceder usando el comando /sbin/service.

Para iniciar el servidor, escriba como usuario root, lo siguiente:

/sbin/service vsftpd start

Para detener el servidor, como root escriba:

/sbin/service vsftpd stop

La opción restart es un atajo para detener y volver a iniciar vsftpd. Esta es la forma más efectiva para que los cambios de configuración tomen efecto luego de modificar el archivo de configuración para vsftpd.

Para reiniciar el servidor, escriba como root:

/sbin/service vsftpd restart

La opción condrestart (reinicio condicional) solamente arranca vsftpd si está ejecutándose en ese momento. Esta opción es muy útil para scripts, puesto que no arranca el demonio si este no se está ejecutando.

Para reiniciar el servidor de forma condicional, escriba como usuario root:

/sbin/service vsftpd condrestart

23.4.1. Iniciar múltiples copias de vsftpd

En ocasiones, se utiliza un computador para servir varios dominios FTP. Esta es una técnica que se conoce como multihoming (multi-anfitrión). Una forma de hacer multihome usando vsftpd es ejecutando múltiples copias del demonio, cada uno con su propio archivo de configuración.

Para hacerlo, primero asigne todas las direcciones IP relevantes a los dispositivos de red o a los alias de dispositivos en el sistema. Consulte el Capítulo 15, Configuración de la red para obtener mayor información sobre la configuración de dispositivos de red y aliases. Se puede encontrar información adicional sobre los scripts de configuración de red en el Capítulo 14, Interfaces de red.

Luego, el servidor DNS para los dominios FTP debe ser configurados para hacer referencia a la máquina correcta. Para obtener mayor información sobre BIND y sus archivos de configuración, consulte el Capítulo 17, Berkeley Internet Name Domain (BIND).

Para que vsftpd responda a las peticiones en diferentes direcciones IP, deben estar ejecutándose múltiples copias del demonio. La primera copia se debe ejecutar usando el initiscript vsftpd, como se describe en la Sección 23.4, “Iniciar y detener vsftpd. Esta copia utiliza el archivo de configuración estándar, /etc/vsftpd/vsftpd.conf.

Cada sitio FTP adicional debe tener un archivo de configuración con un nombre único en el directorio /etc/vsftpd/, tal como /etc/vsftpd/vsftpd-site-2.conf. Cada archivo de configuración sólo debería de ser legído y escrito por root. Dentro de cada archivo de configuración para cada servidor FTP que se encuentre escuchando en la red IPv4, la siguiente directriz debe ser única:

listen_address=N.N.N.N

Reemplace N.N.N.N con la única dirección IP para el sitio FTP que está siendo servido. Si el sitio en cuestión está utilizando IPv6, utilice la directriz listen_address6.

Una vez que cada servidor adicional tenga su archivo de configuración, el demonio vsftpd se debe lanzar desde un indicador de comandos shell usando el comando siguiente:

vsftpd /etc/vsftpd/<configuration-file> [amp   ]

En el comando de arriba, reemplace <configuration-file> con el nombre único para el archivo de configuración, tal como /etc/vsftpd/vsftpd-site-2.conf.

Otras directrices que podría considerar modificar en una base de por servidor son:

  • anon_root

  • local_root

  • vsftpd_log_file

  • xferlog_file

Para una lista detallada de las directrices disponibles dentro del archivo de configuración vsftpd, consulte el Sección 23.5, “Opciones de configuración vsftpd.

Para configurar servidores adicionales para que se inicien de forma automática al momento del arranque, añada el comando que se muestra arriba al final del archivo /etc/rc.local.

23.5. Opciones de configuración vsftpd

Aún cuando vsftpd quizás no ofrezca el nivel de personalización que otros servidores FTP disponible globalmente tienen, vsftpd ofrece suficientes opciones para satisfacer la mayoría de las necesidades de un administrador. El hecho de que no está sobrecargado de funcionalidades limita los errores de configuración y de programación.

Toda la configuración de vsftpd es manejada por su archivo de configuración, /etc/vsftpd/vsftpd.conf. Cada directriz está en su propia línea dentro del archivo y sigue el formato siguiente:

<directive>=<value>

Para cada directriz, reemplace <directive> con una directriz válida y <value> con un valor válido.

Importante

No deben existir espacios entre la <directive>, el símbolo de igualdad y el <value> en una directriz.

Se debe colocar el símbolo de almohadilla (#) antes de una línea en comentarios. El demonio ignorará cualquier línea en comentarios.

Para una lista completa de las directrices disponibles, consulte las páginas man para vsftpd.conf.

A continuación se presenta una lista de las directrices más importantes dentro de /etc/vsftpd/vsftpd.conf. Todas las directrices que no se encuentren explícitamente dentro del archivo de configuración de vsftpd se colocan a sus valores por defecto.

23.5.1. Opciones de demonios

La lista siguiente presenta las directrices que controlan el comportamiento general del demonio vsftpd.

  • listen — Cuando esta directriz está activada vsftpd se ejecuta en modo independiente. Red Hat Enterprise Linux establece este valor a YES. Esta directriz no se puede utilizar junto con la directriz listen_ipv6.

    El valor predeterminado es NO.

  • listen_ipv6 — Cuando esta directriz está activada vsftpd se ejecuta en modo independiente, pero solamente escucha a los sockets IPv6. Esta directriz no se puede utilizar junto con la directriz listen.

    El valor predeterminado es NO.

23.5.2. Opciones de conexión y control de acceso

La siguiente es una lista de las directrices que controlan el comportamiento de los inicios de sesión y los mecanismos de control de acceso.

  • anonymous_enable — Al estar activada, se permite que los usuarios anónimos se conecten. Se aceptan los nombres de usuario anonymous y ftp.

    El valor por defecto es YES.

    Consulte la Sección 23.5.3, “Opciones de usuario anónimo” para una lista de las directrices que afectan a los usuarios anónimos.

  • banned_email_file — Si la directriz deny_email_enable tiene el valor de YES, entonces esta directriz especifica el archivo que contiene una lista de contraseñas de correo anónimas que no tienen permitido acceder al servidor.

    El valor predeterminado es /etc/vsftpd.banned_emails.

  • banner_file — Especifica un archivo que contiene el texto que se mostrará cuando se establece una conexión con el servidor. Esta opción supersede cualquier texto especificado en la directriz ftpd_banner.

    Esta directriz no tiene un valor predeterminado.

  • cmds_allowed — Especifica una lista delimitada por comas de los comandos FTP que permite el servidor. Se rechaza el resto de los comandos.

    Esta directriz no tiene un valor predeterminado.

  • deny_email_enable — Si está activada, se le niega el acceso al servidor a cualquier usuario anónimo que utilice contraseñas de correo especificadas en /etc/vsftpd.banned_emails. Se puede especificar el nombre del archivo al que esta directriz hace referencia usando la directriz banned_email_file.

    El valor predeterminado es NO.

  • ftpd_banner — Si está activada, se muestra la cadena de caracteres especificada en esta directriz cuando se establece una conexión con el servidor. banner_file puede sobreescribir esta opción.

    Por defecto, vsftpd muestra su pancarta estándar.

  • local_enable — Al estar activada, los usuarios locales pueden conectarse al sistema.

    El valor por defecto es YES.

    Consulte la Sección 23.5.4, “Opciones del usuario local” para una lista de las directrices que afectan a los usuarios locales.

  • pam_service_name — Especifica el nombre de servicio PAM para vsftpd.

    El valor predeterminado es ftp, sin embargo, bajo Red Hat Enterprise Linux, el valor es vsftpd.

  • El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux, el valor está configurado a YES.

  • userlist_deny — Cuando se utiliza en combinación con la directriz userlist_enable y con el valor de NO, se les niega el acceso a todos los usuarios locales a menos que sus nombres esten listados en el archivo especificado por la directriz userlist_file. Puesto que se niega el acceso antes de que se le pida la contraseña al cliente, al configurar esta directriz a NO previene a los usuarios locales a proporcionar contraseñas sin encriptar sobre la red.

    El valor por defecto es YES.

  • userlist_enable — Cuando está activada, se les niega el acceso a los usuarios listados en el archivo especificado por la directriz userlist_file. Puesto que se niega el acceso al cliente antes de solicitar la contraseña, se previene que los usuarios suministren contraseñas sin encriptar sobre la red.

    El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux el valor está configurado a YES.

  • userlist_file — Especifica el archivo al que vsftpd hace referencia cuando la directriz userlist_enable está activada.

    El valor predeterminado es /etc/vsftpd.user_list y es creado durante la instalación.

  • cmds_allowed — Especifica una lista separada por comas de los comandos FTP que permite el servidor. Cualquier otro comando es rechazado.

    Esta directriz no tiene un valor predeterminado.

23.5.3. Opciones de usuario anónimo

A continuación, se presenta una lista de las directrices que controlan el acceso de usuarios anónimos al servidor. Para utilizar estas opciones, la directriz anonymous_enable debe tener el valor de YES.

  • anon_mkdir_write_enable — Cuando se activa en combinación con la directriz write_enable, los usuarios anónimos pueden crear nuevos directorios dentro de un directorio que tiene permisos de escritura.

    El valor predeterminado es NO.

  • anon_root — Especifica el directorio al cual vsftpd cambia luego que el usuario anónimo se conecta.

    Esta directriz no tiene un valor predeterminado.

  • anon_upload_enable — Cuando se usa con la directriz write_enable, los usuarios anónimos pueden cargar archivos al directorio padre que tiene permisos de escritura.

    El valor predeterminado es NO.

  • anon_world_readable_only — Si está activada, los usuarios anónimos solamente pueden descargar archivos legibles por todo el mundo.

    El valor por defecto es YES.

  • ftp_username — Especifica la cuenta del usuario local (listada en /etc/passwd) utilizada por el usuario FTP anónimo. El directorio principal especificado en /etc/passwd para el usuario es el directorio raíz del usuario FTP anónimo.

    El valor por defecto es ftp.

  • no_anon_password — Cuando está activada, no se le pide una contraseña al usuario anónimo.

    El valor predeterminado es NO.

  • secure_email_list_enable — Cuando está activada, solamente se aceptan una lista de contraseñas especificadas para las conexiones anónimas. Esto es una forma conveniente de ofrecer seguridad limitada al contenido público sin la necesidad de usuarios virtuales.

    Se previenen las conexiones anónimas a menos que la contraseña suministrada esté listada en /etc/vsftpd.email_passwords. El formato del archivo es una contraseña por línea, sin espacios al comienzo.

    El valor predeterminado es NO.

23.5.4. Opciones del usuario local

La siguiente es una lista de las directrices que caracterizan la forma en que los usuarios locales acceden al servidor. Para utilizar estas opciones, la directriz local_enable debe estar a YES.

  • chmod_enable — Cuando está activada, se permite el comando FTP SITE CHMOD para los usuarios locales. Este comando permite que los usuarios cambien los permisos en los archivos.

    El valor por defecto es YES.

  • chroot_list_enable — Cuando está activada, se coloca en una prisión de chroot a los usuarios locales listados en el archivo especificado en la directriz chroot_list_file.

    Si se utiliza en combinación con la directriz chroot_local_user, los usuarios locales listados en el archivo especificado en la directriz chroot_list_file, no se colocan en una prisión chroot luego de conectarse.

    El valor predeterminado es NO.

  • chroot_list_file — Especifica el archivo que contiene una lista de los usuarios locales a los que se hace referencia cuando la directriz chroot_list_enable está en YES.

    El valor por defecto es /etc/vsftpd.chroot_list.

  • chroot_local_user — Si está activada, a los usuarios locales se les cambia el directorio raíz (se hace un chroot) a su directorio principal luego de la conexión.

    El valor predeterminado es NO.

    Aviso

    Al activar chroot_local_user se abren varios problemas de seguridad, especialmente para los usuarios con privilegios para hacer cargas. Por este motivo, no se recomienda su uso.

  • guest_enable — Al estar activada, todos los usuarios anónimos se conectan como guest, el cual es el usuario local especificado en la directriz guest_username.

    El valor predeterminado es NO.

  • guest_username — Especifica el nombre de usuario al cual guest está asignado.

    El valor por defecto es ftp.

  • local_root — Especifica el directorio al cual vsftpd se cambia después de que el usuario se conecta.

    Esta directriz no tiene un valor predeterminado.

  • local_umask — Especifica el valor de umask para la creación de archivos. Observe que el valor por defecto está en forma octal (un sistema numérico con base ocho), que incluye un prefijo de "0". De lo contrario el valor es tratado como un valor entero de base 10.

    El valor por defecto 022.

  • passwd_chroot_enable — Cuando se activa junto con la directriz chroot_local_user, vsftpd cambia la raiz de los usuarios locales basado en la ocurrencia de /./ en el campo del directorio principal dentro de /etc/passwd.

    El valor predeterminado es NO.

  • user_config_dir — Especifica la ruta a un directorio que contiene los archivos de configuración con los nombres de los usuarios locales. Contiene información específica sobre ese usuario. Cualquier directriz en el archivo de configuración del usuario ignora aquellas encontradas en /etc/vsftpd/vsftpd.conf.

    Esta directriz no tiene un valor predeterminado.

23.5.5. Opciones de directorio

La siguiente es una lista de directrices que afectan a los directorios.

  • dirlist_enable — Al estar activada, los usuarios pueden ver los listados de directorios.

    El valor por defecto es YES.

  • dirmessage_enable — Al estar activada, se mostrará un mensaje cada vez que un usuario entra en un directorio con un archivo de mensaje. Este mensaje se encuentra dentro del directorio al que se entra. El nombre de este archivo se especifica en la directriz message_file y por defecto es .message.

    El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux, el valor está configurado a YES.

  • force_dot_files — Al estar activada, se listan en los listados de directorios los mensajes que comienzan con un punto (.), a excepción de los archivos . y ...

    El valor predeterminado es NO.

  • hide_ids — Cuando está activada, todos los listados de directorios muestran ftp como el usuario y grupo para cada archivo.

    El valor predeterminado es NO.

  • message_file — Especifica el nombre del archivo de mensaje cuando se utiliza la directriz dirmessage_enable.

    El valor predeterminado es .message.

  • text_userdb_names — Cuando está activado, se utilizan los nombres de usuarios y grupos en lugar de sus entradas UID o GID. Al activar esta opción puede que reduzca el rendimiento del servidor.

    El valor predeterminado es NO.

  • use_localtime — Al estar activada, los listados de directorios revelan la hora local para el computador en vez de GMT.

    El valor predeterminado es NO.

23.5.6. Opciones de transferencia de archivos

La siguiente es una lista de directrices que afectan a los directorios.

  • download_enable — Cuando está activada, se permiten las descargas de archivos.

    El valor por defecto es YES.

  • chown_uploads — Si está activada, todos los archivos cargados por los usuarios anónimos pertenecen al usuario especificado en la directriz chown_username.

    El valor predeterminado es NO.

  • chown_username — Especifica la propiedad de los archivos cargados anónimamente si está activada la directriz chown_uploads.

    El valor predeterminado es root.

  • write_enable — Cuando está activada, se permiten los comandos FTP que pueden modificar el sistema de archivos, tales como DELE, RNFR y STOR.

    El valor por defecto es YES.

23.5.7. Opciones de conexión

A continuación se presenta una lista con las directrices que afectan el comportamiento de conexión de vsftpd.

  • dual_log_enable — Cuando se activa en conjunto con xferlog_enable, vsftpd escribe simultáneamente dos archivos: un registro compatible con wu-ftpd al archivo especificado en la directriz xferlog_file (por defecto /var/log/xferlog) y un archivo de registro estándar vsftpd especificado en la directriz vsftpd_log_file (por defecto /var/log/vsftpd.log).

    El valor predeterminado es NO.

  • log_ftp_protocol — Cuando está activado en conjunto con xferlog_enable y con xferlog_std_format configurada a NO, se registran todos los comandos y respuestas. Esta directriz es muy útil para propósitos de depuración.

    El valor predeterminado es NO.

  • syslog_enable — Cuando se activa en conjunto con xferlog_enable, todos los registros que normalmente se escriben al archivo estándar vsftpd especificado en la directriz vsftpd_log_file, se envían al registro del sistema bajo la facilidad FTPD.

    El valor predeterminado es NO.

  • vsftpd_log_file — Especifica el archivo de registro de vsftpd. Para que se utilice este archivo, xferlog_enable debe estar activado y xferlog_std_format debe ser bien sea NO o, si está en YES, entonces dual_log_enable debe estar activado. Es importante resaltar que si syslog_enable está en YES, se utiliza el registro del sistema en lugar del archivo especificado en esta directriz.

    El valor por defecto es /var/log/vsftpd.log.

  • xferlog_enable — Cuando se activa, vsftpd registra las conexiones (solamente formato vsftpd) y la información de transferencia, al archivo de registro especificado en la directriz vsftpd_log_file (por defecto es /var/log/vsftpd.log). Si xferlog_std_format está configurada a YES, se registra la información de transferencia de archivo pero no las conexiones y en su lugar se utiliza el archivo de registro especificado en xferlog_file (por defecto /var/log/xferlog). Es importante observar que se utilizan ambos archivos y formatos de registro si dual_log_enable tiene el valor de YES.

    El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux, el valor está configurado a YES.

  • xferlog_file — Especifica el archivo de registro compatible con wu-ftpd. Para que se utilice este archivo, xferlog_enable debe estar activado y xferlog_std_format debe tener el valor de YES. También se utiliza si dual_log_enable tiene el valor de YES.

    El valor por defecto es /var/log/xferlog.

  • xferlog_std_format — Cuando se activa en combinación con xferlog_enable, sólo se escribe un archivo de registro compatible con wu-ftpd al archivo especificado en la directriz xferlog_file (por defecto /var/log/xferlog). Es importante resaltar que este archivo solamente registra transferencias de archivos y no las conexiones al servidor.

    El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux, el valor está configurado a YES.

Importante

Para mantener la compatibilidad con los archivos de registro escritos por el servidor FTP más antiguo wu-ftpd, se configura la directriz xferlog_std_format a YES bajo Red Hat Enterprise Linux. Sin embargo, esta configuración implica que las conexiones al servidor no son registradas.

Para registrar ambas conexiones en formato vsftpd y mantener un archivo de registro de transferencia compatible con wu-ftpd, configure dual_log_enable a YES.

Si no es de importancia mantener un archivo de registro de transferencias compatible con wu-ftpd, entonces configure xferlog_std_format a NO, comente la línea con un carácter de almohadilla (#) o borre completamente la línea.

23.5.8. Opciones de red

Lo siguiente lista las directrices que afectan cómo vsftpd interactua con la red.

  • accept_timeout — Especifica la cantidad de tiempo para un cliente usando el modo pasivo para establecer una conexión.

    El valor por defecto 60.

  • anon_max_rate — Especifica la cantidad máxima de datos transmitidos por usuarios anónimos en bytes por segundo.

    El valor por defecto es 0, lo que no limita el ratio de transferencia.

  • connect_from_port_20 — Cuando está activada, vsftpd se ejecuta con privilegios suficientes para abrir el puerto 20 en el servidor durante las transferencias de datos en modo activo. Al desactivar esta opción, se permite que vsftpd se ejecute con menos privilegios, pero puede ser incompatible con algunos clientes FTP.

    El valor predeterminado es NO, sin embargo, bajo Red Hat Enterprise Linux, el valor está configurado a YES.

  • connect_timeout — Especifica la cantidad máxima de tiempo que un cliente usando el modo activo tiene para responder a una conexión de datos, en segundos.

    El valor por defecto 60.

  • data_connection_timeout — Especifica la cantidad máxima de tiempo que las conexiones se pueden aplazar en segundos. Una vez lanzado, se cierra la conexión con el cliente remoto.

    El valor predeterminado es 300.

  • ftp_data_port — Especifica el puerto utilizado por las conexiones de datos activas cuando connect_from_port_20 está configurado a YES.

    El valor predeterminado es 20.

  • idle_session_timeout — Especifica la cantidad máxima de tiempo entre comandos desde un cliente remoto. Una vez disparado, se cierra la conexión al cliente remoto.

    El valor predeterminado es 300.

  • listen_address — Especifica la dirección IP en la cual vsftpd escucha por las conexiones de red.

    Esta directriz no tiene un valor predeterminado.

    Sugerencia

    Si se están ejecutando varias copias de vsftpd sirviendo diferentes direcciones IP, el archivo de configuración para cada copia del demonio vsftpd debe tener un valor diferente para esta directriz. Consulte la Sección 23.4.1, “Iniciar múltiples copias de vsftpd para más información sobre servidores FTP multihome.

  • listen_address6 — Especifica la dirección IPv6 en la cual vsftpd escucha por conexiones de red cuando listen_ipv6 está configurada a YES.

    Esta directriz no tiene un valor predeterminado.

    Sugerencia

    Si se están ejecutando varias copias de vsftpd sirviendo diferentes direcciones IP, el archivo de configuración para cada copia del demonio vsftpd debe tener un valor diferente para esta directriz. Consulte la Sección 23.4.1, “Iniciar múltiples copias de vsftpd para más información sobre servidores FTP multihome.

  • listen_port — Especifica el puerto en el cual vsftpd escucha por conexiones de red.

    El valor predeterminado es 21.

  • local_max_rate — Especifica la taza máxima de transferencia de datos para los usuarios locales conectados en el servidor en bytes de segundo.

    El valor por defecto es 0, lo que no limita el ratio de transferencia.

  • max_clients — Especifica el número máximo de clientes simultáneos que tienen permitido conectarse al servidor cuando se ejecuta en modo independiente. Cualquier conexión adicional resultará en un mensaje de error.

    El valor predeterminado es 0, lo que no limita las conexiones.

  • max_per_ip — Especifica el máximo número de clientes que tienen permitido conectarse desde la misma dirección IP fuente.

    El valor predeterminado es 0, lo que no limita las conexiones.

  • pasv_address — Especifica la dirección IP para la IP del lado público del servidor para los servidores detrás de cortafuegos Network Address Translation (NAT). Esto permite que vsftpd entregue la dirección correcta de retorno para las conexiones pasivas.

    Esta directriz no tiene un valor predeterminado.

  • pasv_enable — Cuando está activa, se permiten conexiones en modo pasivo.

    El valor por defecto es YES.

  • pasv_max_port — Especifica el puerto más alto posible enviado a los clientes FTP para las conexiones en modo pasivo. Esta configuración es utilizada para limitar el intervalo de puertos para que las reglas del cortafuegos sean más fáciles de crear.

    El valor predeterminado es 0, lo que no limita el rango de puertos pasivos más alto. El valor no puede exceder de 65535.

  • pasv_min_port — Especifica el puerto más bajo posible para los clientes FTP para las conexiones en modo pasivo. Esta configuración es utilizada para limitar el intervalo de puertos para que las reglas del cortafuego sean más fáciles de implementar.

    El valor predeterminado es 0, lo que no limita el intervalo de puertos pasivos más bajo. El valor no debe ser menor que 1024.

  • pasv_promiscuous — Cuando está activada, las conexiones de datos no son verificadas para asegurarse de que se originan desde la misma dirección IP. Este valor solamente es útil para ciertos tipos de tunneling.

    Atención

    No active esta opción a menos que sea absolutamente necesario ya que desactiva una funcionalidad de seguridad muy importante la cual verifica que las conexiones en modo pasivo partan desde la misma dirección IP que la conexión de control que inicia la transferencia de datos.

    El valor predeterminado es NO.

  • port_enable — Cuando está activada, se permiten las conexiones en modo activo.

    El valor por defecto es YES.

23.6. Recursos adicionales

Para más información sobre vsftpd, consulte los recursos siguientes.

23.6.1. Documentación instalada

  • El directorio /usr/share/doc/vsftpd-<version-number>/ — Reemplace <version-number> con la versión instalada del paquete vsftpd. Este directorio contiene un archivo LEAME con información básica sobre el software. El archivo TUNING contiene sugerencias básicas para refinar el rendimiento y el directorio SECURITY/ contiene información sobre el modelo de seguridad empleado por vsftpd.

  • Páginas man relacionadas con vsftpd — Hay varias páginas man para este demonio y los archivos de configuración. Lo siguiente lista algunas de las más importantes.

    Aplicaciones de servidor
    • man vsftpd — Describe las opciones de línea de comandos disponibles para vsftpd.

    Archivos de configuración
    • man vsftpd.conf — Contiene una lista detallada de las opciones disponibles dentro del archivo de configuración para vsftpd.

    • man 5 hosts_access — Describe el formato y las opciones disponibles dentro de los archivos de configuración de TCP wrappers: hosts.allow and hosts.deny.

23.6.2. Sitios web de utilidad

Capítulo 24. Correo electrónico

El nacimiento del correo electrónico (email) ocurrió a principios de los años 60. El buzón era un archivo en el directorio principal de un usuario al cual sólo el mismo podía acceder. Las aplicaciones de correo primitivas anexaban nuevos mensajes de texto a la parte inferior de un archivo, y el usuario tenía que buscar a lo largo del archivo en constante crecimiento para encontrar un mensaje particular. Este sistema sólo era capaz de enviar mensajes a usuarios en el mismo sistema.

La primera transferencia verdadera de correo electrónico en la red se llevó a cabo en 1971 cuando un ingeniero de computación llamado Ray Tomlinson envió un mensaje de prueba entre dos máquinas a través de ARPANET — el precursor de Internet. La comunicación a través de correo electrónico rápidamente se volvió muy popular, pasando a formar el 75 por ciento del tráfico de ARPANET en menos de dos años.

Hoy día los sistemas de correo electrónico basados en protocolos de red se han convertido en uno de los servicios más usados de la Internet. Red Hat Enterprise Linux ofrece muchas aplicaciones avanzadas para servir y acceder a correo electrónico.

En este capítulo se analizan los protocolos de correo electrónico modernos conocidos actualmente, así como algunos programas diseñados para recibir y enviar correo electrónico.

24.1. Protocolos de correo electrónico

Hoy día, el correo electrónico es entregado usando una arquitectura cliente/servidor. Un mensaje de correo electrónico es creado usando un programa de correo cliente. Este programa luego envía el mensaje a un servidor. El servidor luego lo redirige al servidor de correo del recipiente y allí se le suministra al cliente de correo del recipiente.

Para permitir todo este proceso, existe una variedad de protocolos de red estándar que permiten que diferentes máquinas, a menudo ejecutando sistemas operativos diferentes y usando diferentes programas de correo, envíen y reciban correo electrónico o email.

Los protocolos que se indican a continuación son los que más se utilizan para transferir correo electrónico.

24.1.1. Protocolos de transporte de correo

La entrega de correo desde una aplicación cliente a un servidor, y desde un servidor origen al servidor destino es manejada por el Protocolo simple de transferencia de correo (Simple Mail Transfer Protocol o SMTP).

24.1.1.1. SMTP

El objetivo principal del protocolo simple de transferencia de correo, SMTP, es transmitir correo entre servidores de correo. Sin embargo, es crítico para los clientes de correo también. Para poder enviar correo, el cliente envia el mensaje a un servidor de correo saliente, el cual luego contacta al servidor de correo de destino para la entrega. Por esta razón, es necesario especificar un servidor SMTP cuando se esté configurando un cliente de correo.

Bajo Red Hat Enterprise Linux, un usuario puede configurar un servidor SMTP en la máquina local para manejar la entrega de correo. Sin embargo, también es posible configurar servidores remotos SMTP para el correo saliente.

Un punto importante sobre el protocolo SMTP es que no requiere autenticación. Esto permite que cualquiera en Internet puede enviar correo a cualquier otra persona o inclusive a grandes grupos de personas. Esta característica de SMTP es lo que hace posible el correo basura o spam. Los servidores SMTP modernos intentan minimizar este comportamiento permitiendo que sólo los hosts conocidos accedan al servidor SMTP. Los servidores que no ponen tales restricciones son llamados servidores open relay.

Por defecto se utiliza Sendmail (/usr/sbin/sendmail) como su programa SMTP bajo Red Hat Enterprise Linux. Sin embargo, también está disponible una aplicación más simple de servidor de correo llamada Postfix (/usr/sbin/postfix).

24.1.2. Protocolos de acceso a correo

Hay dos protocolos principales usados por las aplicaciones de correo cliente para recuperar correo desde los servidores de correo: el Post Office Protocol (POP) y el Internet Message Access Protocol (IMAP).

24.1.2.1. POP

El servidor por defecto POP bajo Red Hat Enterprise Linux es /usr/lib/cyrus-imapd/pop3d y es proporcionado por el paquete cyrus-imapd. Cuando utilice un servidor POP, los mensajes de correo son descargados a través de las aplicaciones de correo del cliente. Por defecto, la mayoría de los clientes de correo POP son configurados automáticamente para borrar el mensaje en el servidor de correo después que éste ha sido transferido exitósamente, sin embargo esta configuración se puede cambiar.

POP es completamente compatible con estándares importantes de mensajería de Internet, tales como Multipurpose Internet Mail Extensions (MIME), el cual permite los anexos de correo.

POP funciona mejor para usuarios que tienen un sistema en el cual leer correo. También funciona bien para usuarios que no tienen una conexión permanente a la Internet o a la red que contiene el servidor de correo. Desafortunadamente para aquellos con conexiones lentas, POP requiere que luego de la autenticación los programas cliente descarguen el contenido completo de cada mensaje. Esto puede tomar un buen tiempo si algún mensaje tiene anexos grandes.

La versión más reciente del protocolo estándar POP es POP3.

Sin embargo, también existen una variedad de variantes del protocolo POP que no son tan populares:

  • APOP — POP3 con autenticación MDS. En este protocolo, el cliente de correo envía un hash codificado de la contraseña al servidor en lugar de enviar una contraseña encriptada.

  • RPOP — POP3 con autenticación RPOP, que utiliza un identificador de usuario similar a una contraseña para autenticar las peticiones POP. No obstante, este ID no esta encriptado por tanto RPOP no es más seguro que el estándar POP.

Para añadir seguridad, es posible utilizar la encriptación Secure Socket Layer (SSL) para la autenticación del cliente y las sesiones de transferencias de datos. Esto se puede activar usando el servicio ipop3s o mediante el uso del programa /usr/sbin/stunnel. Refiérase a la Sección 24.6.1, “Comunicación segura” para obtener mayor información.

24.1.2.2. IMAP

El servidor por defecto IMAP bajo Red Hat Enterprise Linux es /usr/lib/cyrus-imapd/imapd y es proporcionado por el paquete cyrus-imapd. Cuando utilice un servidor de correo IMAP, los mensajes de correo se mantienen en el servidor donde los usuarios los pueden leer y borrarlos. IMAP también permite a las aplicaciones cliente crear, renombrar o borrar directorios en el servidor para organizar y almacenar correo.

IMAP lo utilizan principalmente los usuarios que acceden a su correo desde varias máquinas. El protocolo es conveniente también para usuarios que se estén conectando al servidor de correo a través de una conexión lenta, porque sólo la información de la cabecera del correo es descargada para los mensajes, hasta que son abiertos, ahorrando de esta forma ancho de banda. El usuario también tiene la habilidad de eliminar mensajes sin verlos o descargarlos.

Por conveniencia, las aplicaciones cliente IMAP son capaces de hacer caché de los mensajes localmente, para que el usuario pueda hojear los mensajes previamente leídos cuando no se esté conectado directamente al servidor IMAP.

IMAP, como POP, es completamente compatible con estándares de mensajería de Internet, tales como MIME, que permite los anexos de correo.

Para seguridad adicional, es posible utilizar la encriptación SSL para la autenticación de clientes y para las sesiones de transferencia de datos. Esto se puede activar usando el servicio imaps o mediante el uso del programa /usr/sbin/stunnel. Refiérase a la Sección 24.6.1, “Comunicación segura” para obtener mayor información.

También están disponibles otros clientes y servidores de correo IMAP gratuítos así como también comerciales, muchos de los cuales extienden el protocolo IMAP y proporcionan funcionalidades adicionales. Una lista completa sobre esto se puede encontrar en http://www.imap.org/products/longlist.htm.

24.1.2.3. Dovecot

Los demonios imap-login y pop3-login, los cuales implementan los protocolos IMAP y POP3 se encuentran incluidos en el paquete dovecot. El uso de IMAP y POP se configura a través de dovecot; por defecto, dovecot ejecuta sólamente IMAP. Para configurar dovecot para que utilice POP:

  1. Modifique /etc/dovecot.conf para que tenga la siguiente línea:

    protocols = imap imaps pop3 pop3s
    
  2. Para hacer ese cambio operacional para la sesión actual ejecute el comando:

    /sbin/service dovecot restart
    
  3. Haga que ese cambio sea operacional después del siguiente reinicio ejecutando el comando:

    chkconfig dovecot on
    

    Observe que dovecot sólamente reporta que inició el servidor IMAP pero también inicia el servidor POP3.

A diferencia de SMTP, estos protocolos requieren autenticación de los clientes usando un nombre de usuario y una contraseña. Por defecto, las contraseñas para ambos protocolos son pasadas a través de la red sin encriptar.

Para configurar SSL en dovecot:

  • Modifique el archivo de configuración dovecot/etc/pki/dovecot/dovecot-openssl.conf como desee. Sin embargo, en una instalación típica este archivo no necesita modificación.

  • Renombra, mueve o borra los archivos /etc/pki/dovecot/certs/dovecot.pem y /etc/pki/dovecot/private/dovecot.pem.

  • Ejecute el script /usr/share/doc/dovecot-1.0/examples/mkcert.sh, el cual crea certificados auto-firmados dovecot. Estos certificados se copian en los directorios /etc/pki/dovecot/certs y /etc/pki/dovecot/private. Para implementar los cambios reinicie dovecot (/sbin/service dovecot restart).

Encontrará más información sobre dovecot en http://www.dovecot.org.

24.2. Clasificaciones de los programas de correo

En general, todas las aplicaciones de email caen en al menos una de tres clasificaciones. Cada clasificación juega un papel específico en el proceso de mover y administrar los mensajes de correo. Mientras que la mayoría de los usuarios sólo están al tanto del programa de correo específico que usan para recibir o enviar mensajes, cada uno es importante para asegurar que el mensaje llegue a su destino correcto.

24.2.1. Agente de Transporte de Correo

Un Agente de Transporte de Correo (MTA) transfiere mensajes de correo electrónico entre hosts usando SMTP. Un mensaje puede involucrar varios MTAs a medida que este se mueve hasta llegar a su destino.

Aunque la entrega de mensajes entre máquinas puede parecer bien simple, el proceso completo de decidir si un MTA particular puede o debería aceptar un mensaje para ser repartido, es más bien complicado. Además, debido a los problemas de spam, el uso de un MTA particular está usualmente restringido por la configuración del MTA o por la configuración de acceso a la red en la que reside el MTA.

Muchos programas clientes de correo modernos pueden actuar como un MTA cuando estén enviando correo. Sin embargo, no se debería confundir esta acción con el papel de un verdadero MTA. La única razón por la que los programas de correo cliente son capaces de enviar mensajes como un MTA es porque el host ejecutando la aplicación no tiene su propio MTA. Esto es particularmente cierto para programas de correo cliente o para sistemas que no están basados en el sistema operativo UNIX. Sin embargo, estos programas clientes sólo envían mensajes salientes a un MTA para el cual estan autorizados a utilizar y no entregan el mensaje directamente al servidor de correos del recipiente.

Puesto que Red Hat Enterprise Linux instala dos MTAs, Sendmail y Postfix, los programas cliente de correo electrónico no son comúnmente requeridos que actúen como un MTA. Red Hat Enterprise Linux también incluye un MTA de propósitos especiales llamado Fetchmail.

Para obtener mayor información sobre Sendmail, Postfix y Fetchmail consulte la Sección 24.3, “Agentes de transporte de correo”.

24.2.2. Agente de entrega de correos

Un MTA invoca a un Agente de entrega de correos (MDA) para archivar el correo entrante en el buzón de correo del usuario. En muchos casos, el MDA es en realidad un Agente de entregas local (LDA), tal como mail o Procmail.

Cualquier programa que maneje la entrega de mensajes hasta el punto en que puede ser leído por una aplicación cliente de correos se puede considerar un MDA. Por esta razón, algunos MTAs (tales como Sendmail y Postfix) pueden tener el papel de un MDA cuando ellos anexan nuevos mensajes de correo al archivo spool de correo del usuario. En general, los MDAs no transportan mensajes entre sistemas tampoco proporcionan una interfaz de usuario; los MDAs distribuyen y clasifican mensajes en la máquina local para que lo accese una aplicación cliente de correo.

24.2.3. Agente de usuario de correo

Un agente de usuario de correo (MUA) es sinónimo con una aplicación cliente de correo. Un MUA es un programa que, al menos, le permite a los usuarios leer y redactar mensajes de correo. Muchos MUAs son capaces de recuperar mensajes a través de los protocolos POP o IMAP, configurando los buzones de correo para almacenar mensajes y enviando los mensajes salientes a un MTA.

Los MUAs pueden ser de interfaz gráfica tal como Evolution o tener una interfaz basada en texto muy sencilla tal como mutt.

24.3. Agentes de transporte de correo

Red Hat Enterprise Linux incluye dos tipos primarios de MTAs, Sendmail y Postfix. Sendmail es configurado como el MTA predetermiando aún cuando es fácil cambiar el MTA predeterminado a Postfix.

24.3.1. Sendmail

El propósito principal de Sendmail, como cualquier otro MTA, es el de transferir correo de forma segura entre hosts, usualmente usando el protocolo SMTP. Sin embargo, Sendmail es altamente configurable, permitiendo el control sobre casi cada aspecto del manejo de correos, incluyendo el protocolo utilizado. Muchos administradores de sistemas seleccionan Sendmail como su MTA debido a su poder y escalabilidad.

24.3.1.1. Propósitos y limitaciones

Es importante estar conscientes de qué es Sendmail y de lo que puede hacer al contrario de lo que no es. En estos tiempos de aplicaciones monolíticas que cubren varios papeles, Sendmail puede parecer la única aplicación necesitada para ejecutar un servidor de correo en una organización. Esto técnicamente es verdad, puesto que Sendmail puede colocar correo en los directorios de cada usuario y entregar el correo saliente para los usuarios. Sin embargo, la mayoría de los usuarios requieren normalmente mucho más que la entrega de correos. Ellos usualmente quieren interactuar con su correo usando un MUA, que utiliza POP o IMAP, para descargar sus mensajes a sus máquinas locales. O prefieren una interfaz tipo web para ganar acceso a sus buzones. Estas otras aplicaciones pueden funcionar en conjunto con Sendmail, pero ellas existen en realidad por otras razones y pueden operar separadamente una de la otra.

Está más allá del ámbito de esta sección explicar todo lo que Sendmail debería o podría hacer. Literalmente hay cientos de opciones diferentes y reglas para configurar, existen libros dedicados completamente a explicar todo lo que se puede hacer y como solucionar problemas cuando las cosas salen mal. Consulte la Sección 24.7, “Recursos adicionales” para obtener una lista de los recursos de Sendmail.

Esta sección revisa los archivos instalados con Sendmail por defecto y revisa los cambios básicos a la configuración, incluyendo cómo detener correo no deseado (spam) y también cómo extender Sendmail con el Lightweight Directory Access Protocol (LDAP).

24.3.1.2. La instalación de Sendmail por defecto

El ejecutable de Sendmail es /usr/sbin/sendmail.

El largo y detallado archivo de configuración de Sendmail es /etc/mail/sendmail.cf. Evite modificar el archivo sendmail.cf directamente. Para realizar cambios de configuración en Sendmail modifique el archivo /etc/mail/sendmail.mc, haga una copia de seguridad del /etc/mail/sendmail.cf original y utilice las siguientes alternativas para generar un nuevo archivo de configuración:

  • Utilice el makefile en /etc/mail (make all -C /etc/mail) para crear un nuevo archivo de configuración /etc/mail/sendmail.cf. Todos los otros archivos generados en /etc/mail (archivos db) serán regenerados si es necesario. Los viejos comandos makemap todavía se pueden utilizar. service sendmail start | restart | reload utilizará automáticamente el comando make si el paquete make es instalado.

  • Alternativamente puede utilizar el procesador de macros m4 incluído para crear un nuevo /etc/mail/sendmail.cf.

Para obtener más información sobre como configurar Sendmail visite Sección 24.3.1.3, “Cambios comunes de configuración de Sendmail”.

Varios archivos de configuración de Sendmail son instalados en el directorio /etc/mail/ incluyendo:

  • access — Especifica los sistemas que pueden utilizar Sendmail para enviar correo saliente.

  • domaintable — Le permite crear asignaciones de nombres de dominio.

  • local-host-names — Especifica aliases para el host.

  • mailertable — Especifica instrucciones para ignorar la ruta de determinados dominios.

  • virtusertable — Le permite especificar una forma de alias para dominios específicos, permitiendo a múltiples dominios virtuales ser hospedados en una misma máquina.

Several of the configuration files in /etc/mail/, such as access, domaintable, mailertable and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following command:

makemap hash /etc/mail/<name> < /etc/mail/<name>

donde <name> es reemplazado con el nombre del archivo de configuración a convertir.

Por ejemplo, para tener todos los correos direccionados al dominio example.com entregados a , añada la línea siguiente al archivo virtusertable:

@example.com bob@other-example.com

Para finalizar el cambio, se debe actualizar el archivo virtusertable.db usando el comando siguiente como root:

makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable

Esto crea un archivo virtusertable.db actualizado conteniendo la nueva configuración.

24.3.1.3. Cambios comunes de configuración de Sendmail

Cuando se esté modificando el archivo de configuración de Sendmail, es mejor generar un archivo completamete nuevo /etc/mail/sendmail.cf en vez de modificar el existente.

Atención

Es una muy buena idea hacer una copia de respaldo del archivo sendmail.cf antes de cambiarlo.

Para añadir funcionalidad a Sendmail, modifique el archivo /etc/mail/sendmail.mc como usuario root. Cuando termine, utilice el procesador de macros m4 para generar un nuevo sendmail.cf ejecutando el comando siguiente:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Por defecto, el procesador de macros m4 es instalado con Sendmail pero es parte del paquete m4.

Después de crear un archivo /etc/mail/sendmail.cf nuevo, reinicie Sedmail para que los cambios tomen efecto. La forma más fácil de hacer esto es ejecutando el comando siguiente:

/sbin/service sendmail restart

Importante

El archivo por defecto sendmail.cf no permite que Sendmail acepte conexiones de red desde ningún host mas que la máquina local. Para configurar Sendmail como un servidor para otros clientes, modifique /etc/mail/sendmail.mc y cambie la dirección especificada en la opción Addr= de la directriz DAEMON_OPTIONS a la dirección IP de un dispositivo de red activo o coloque en comentarios toda esta opción colocando dnl al comienzo de la línea. Luego, vuelva a generar /etc/mail/sendmail.cf ejecutando el comando siguiente:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

La configuración predetermianda que viene con Red Hat Enterprise Linux funciona para la mayoría de los sitios puramente SMTP. Sin embargo, no funciona con sitios UUCP (Copia UNIX a UNIX). Si está utilizando transferencias de correo UUCP, se debe reconfigurar el archivo /etc/mail/sendmail.mc y se debe generar un nuevo /etc/mail/sendmail.cf.

Consulte el archivo /usr/share/sendmail-cf/README antes de modificar cualquier archivo en los directorios bajo el directorio /usr/share/sendmail-cf, pues ellos pueden afectar la futura configuración de los archivos /etc/mail/sendmail.cf.

24.3.1.4. Creación de máscaras

Una configuración común de Sendmail es tener una sola máquina actuando como el gateway de correo para todas las máquinas en la red. Por ejemplo, una compañía puede querer tener una máquina llamada mail.example.com que maneja todo su correo y asigna una dirección de retorno consistente para todo el correo saliente.

En esta situación, el servidor Sendmail debe enmascarar los nombres de las máquinas en la red de la compañía para que la dirección de retorno sea user@example.com en vez de user@host.example.com.

Para hacer esto, añada las líneas siguientes /etc/mail/sendmail.mc:

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')dnl
FEATURE(`masquerade_envelope')dnl
FEATURE(`allmasquerade')dnl
MASQUERADE_AS(`bigcorp.com.')dnl
MASQUERADE_DOMAIN(`bigcorp.com.')dnl 
MASQUERADE_AS(bigcorp.com)dnl

Después de generar un nuevo sendmail.cf usando m4, esta configuración hará que todo el correo dentro de la red aparezca como que si se hubiese enviado desde bigcorp.com.

24.3.1.5. Detener el correo basura

El correo basura se puede definir como correo no deseado e innecesario recibido por un usuario que nunca solicitó tal comunicación. Es un abuso costoso y molesto de las comunicaciones de Internet estándar.

Sendmail hace relativamente fácil bloquear nuevas técnicas de difusión de correo basura. Hasta bloquea por defecto muchos de los métodos comunes de difusión de correo basura. Las principales características anti-spam disponibles en sendmail son verificación de cabeceras, retransmisión de rechazo (por defecto desde la versión 8.9), acceso a bases de datos y verificación de la información del remitente.

Por ejemplo, el reenvío de mensajes SMTP, también conocido como relaying, está por defecto desactivado en Sendmail desde la versión 8.9. Antes de que se produjese este cambio, Sendmail indicaba al host (x.edu) que aceptara mensajes desde un ente (y.com) y que los enviara a un ente diferente (z.net). Ahora, sin embargo, se debe configurar Sendmail para permitir que cualquier dominio transmita correo a través del servidor. Para configurar dominios de transmisión, modifique el archivo /etc/mail/relay-domains y reinicie Sendmail.

Sin embargo, en muchas ocasiones, los usuarios reciben bombardeos de correo basura de otros servidores a través de Internet. En estos casos, puede utilizar las funciones de control de acceso de Sendmail que están disponibles en el archivo /etc/mail/access para prevenir conexiones desde host indeseados. El ejemplo siguiente ilustra como este archivo puede ser usado para bloquear y también para permitir el acceso al servidor Sendmail:

badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY

Este ejemplo indica que cualquier correo que se envia desde badspammer.com se bloqueará con un código de error 550 RFC-821, con un mensaje para el emisor. Los correos enviados desde el sub-dominio tux.badspammer.com, seran aceptados. La última línea muestra que cualquier correo enviado desde la red 10.0.*.* se puede transmitir a través del servidor de correo.

Debido a que /etc/mail/access.db es una base de datos, use makemap para activar los cambios. Haga esto usando el comando siguiente como root:

makemap hash /etc/mail/access < /etc/mail/access

El análisis de la cabecera del mensaje le permite rechazar correo con base en el contenido de este. Los servidores SMTP almacenan información sobre el recorrido de un correo electrónico en la cabecera del mensaje. Mientras que el mensaje va de una MTA a otra cada una de estas pone una cabecera que dice "Recibido" encima de las otras cabeceras que dicen lo mismo. Sin embargo, es importante observar que los que envían estos correos no deseados pueden alterar esta información.

Este ejemplo sólo muestra una mínima parte de lo que Sendmail puede hacer en cuanto a permitir o bloquear el acceso. Para obtener más información y ejemplos consulte /usr/share/sendmail-cf/README.

Puesto que Sendmail llama a Procmail MDA cuando está entregando correo también es posible utilizar un programa de filtrado de correo basura, tal como SpamAssassin para identificar y archivar correo basura por los usuarios. Consulte la Sección 24.5.2.6, “Filtros de correo basura” obtener para más detalles sobre SpamAssassin.

24.3.1.6. Uso de Sendmail con LDAP

Usando el Lightweight Directory Access Protocol (LDAP) es una forma rápida y poderosa de encontrar información específica sobre un usuario particular desde un grupo mucho más grande. Por ejemplo, un servidor LDAP puede ser usado para buscar una dirección de correo particular desde un directorio corporativo usando el apellido del usuario. En este tipo de implementación, LDAP esta bastante separado de Sendmail, con LDAP la información de usuario de forma jerárquica y Sendmail sólo recibiendo el resultado de las consultas de LDAP en mensajes de correo pre-direccionados.

Sin embargo, Sendmail admite mucha más integración con LDAP y utiliza este protocolo para sustituir archivos mantenidos independientemente, como aliases y virtusertables, que se ubican en servidores de correo diferentes que funcionan juntos para soportar una organización de nivel medio a corporativo. A modo de resumen, puede usar LDAP para separar el nivel de enrutamiento desde Sendmail y sus archivos de configuración separados a un cluster LDAP poderoso que pueden utilizar distintas aplicaciones.

La versión actual de Sendmail es compatible con LDAP. Para ampliar el servidor de Sendmail y usar LDAP, primero debe obtener un servidor LDAP, como OpenLDAP, ejecutarlo y configurarlo correctamente. A continuación, modifique /etc/mail/sendmail.mc para incluir lo siguiente:

LDAPROUTE_DOMAIN('yourdomain.com')dnl 
FEATURE('ldap_routing')dnl

Nota

Esta es sólo una configuración muy básica de Sendmail con LDAP. Su configuración puede ser muy diferente de la indicada según la implementación específica de LDAP, especialmente si configura varias máquinas de Sendmail para que utilicen un servidor LDAP común.

Consulte /usr/share/sendmail-cf/README para obtener instrucciones y ejemplos detallados de configuración de enrutamiento de LDAP.

Luego vuelva a crear el archivo /etc/mail/sendmail.cf ejecutando m4 y reiniciando Sendmail. Consulte la Sección 24.3.1.3, “Cambios comunes de configuración de Sendmail” para obtener detalles sobre cómo hacer esto.

Para obtener mayor información sobe LDAP vea el Capítulo 25, Protocolo Ligero de Acceso a Directorios (LDAP).

24.3.2. Postfix

Postfix, originalmente desarrollado en IBM por el experto de seguridad y programador Wietse Venema, es un MTA compatible con Sendmail diseñado para ser seguro, rápido y fácil de configurar.

Postfix utiliza un diseño modular para mejorar la seguridad, en el que los procesos pequeños con privilegios limitados son lanzados por un demonio master. Los procesos más pequeños, con menos privilegios, realizan tareas muy específicas relacionada con las diferentes etapas de la entrega de correos y se ejecutan en un ambiente de cambio de root para limitar los efectos de ataques.

Configurar Postfix para que acepte conexiones de red desde otros hosts además de la computadora local sólo toma unos pequeños cambios en su archivo de configuración. Para aquellos con necesidades más complejas, Postfix ofrece una variedad de opciones de configuración, así como también complementos de terceros que lo hacen un MTA rico en funcionalidades.

Los archivos de configuración de Postfix son legibles y aceptan hasta 250 directrices. A diferencia de Sendmail, no se requiere procesar ninguna macro para que los cambios tomen efecto y la mayoría de las opciones usadas frecuentemente se describen en archivos muy bien comentados.

Importante

Antes de utilizar Postfix, se debe cambiar la MTA prederminada de Sendmail a Postfix.

24.3.2.1. La instalación predeterminada de Postfix

El ejecutable de Postfix es /usr/sbin/postfix. Este demonio lanza todos los procesos relacionados necesarios para manejar la entrega de correos.

Postfix almacena sus archivos de configuración en el directorio /etc/postfix/. A continuación se muestra una lista de los archivos usados más a menudo:

  • access — Utilizado para el control de acceso, este archivo especifica los sistemas que pueden conectarse a Postfix.

  • aliases — Una lista configurable que el protocolo de correo requiere.

  • main.cf — El archivo global de configuración de Postfix. La mayoría de las opciones de configuración se especifican en este archivo.

  • master.cf — Especifica la forma en que Postfix interactua con diferentes procesos para lograr la entrega de correo.

  • transport — Hace las correspondencias entre direcciones de correo electrónico y los hosts de transmisiones.

Importante

El archivo predeterminado /etc/postfix/main.cf no permite que Postfix acepte conexiones de red desde ningún otro host que no sea la máquina local. Consulte la Sección 24.3.2.2, “Configuración básica de Postfix” para ver las instrucciones sobre cómo configurar Postfix como un servidor para otros clientes.

A veces, puede ser necesario reiniciar el servicio postfix cuando se cambien algunas opciones dentro de archivos en el directorio /etc/postfix/ para que se apliquen los cambios. La forma más fácil de lograr esto es a través del comando:

/sbin/service postfix restart

24.3.2.2. Configuración básica de Postfix

Por defecto, no acepta conexiones de red desde ningún otro host excepto la máquina local. Ejecute los pasos siguientes como superusuario para activar la entrega de correo desde otros hosts en la red:

  • Modifique el archivo /etc/postfix/main.cf con un editor de texto, tal como vi.

  • Quite el comentario de la línea mydomain removiendo la almohadilla (#) y reemplace domain.tld con el dominio que está sirviendo el servidor de correo, tal como example.com.

  • Quite el comentario de la línea myorigin = $mydomain.

  • Elimine el comentario de la línea myhostname y reemplace host.domain.tld con el nombre de host para la máquina.

  • Elimine el comentario de la línea mydestination = $myhostname, localhost.$mydomain.

  • Elimine el comentario de la línea mynetworks y sustituya 168.100.189.0/28 con un valor de red válido para que los hosts se puedan conectar al servidor.

  • Remueva el comentario de la línea inet_interfaces = all.

  • Reinicie el servicio postfix.

Luego de completar estos pasos, el host acepta correos externos.

Postfix tiene una gran variedad de opciones de configuración. Una de las mejores formas de aprender cómo configurar Postfix es leer los comentarios dentro de /etc/postfix/main.cf. En http://www.postfix.org/ puede encontrar recursos adicionales incluyendo información sobre la integración de LDAP y SpamAssassin.

24.3.3. Fetchmail

Fetchmail es un MTA que recupera el correo desde servidores remotos y los entrega al MTA local. Muchos usuarios aprecian la capacidad de separar el proceso de descarga de mensajes ubicados en un servidor remoto del proceso de lectura y organización de correo en un MUA. Se ha diseñado teniendo presente las necesidades de los usuarios de acceso telefónico a redes. Fetchmail se conecta y descarga rápidamente todos los mensajes al archivo spool de correo mediante el uso de diversos protocolos, entre los que se incluyen POP3 e IMAP. Incluso permite reenviar los mensajes de correo a un servidor SMTP si es necesario.

Fetchmail es configurado para cada usuario a través del uso de un archivo .fetchmailrc en el directorio principal del usuario.

Mediante el uso de preferencias en el archivo .fetchmailrc, Fetchmail comprobará si hay correo en un servidor remoto e intentará descargarlo. Luego lo entrega al puerto 25 de la máquina local utilizando el agente MTA local para dirigir el correo al archivo de spool del usuario correcto. Si Procmail está disponible, se ejecuta para filtrar el correo y colocarlo en un buzón para que lo pueda leer un MUA.

24.3.3.1. Opciones de configuración de Fetchmail

Aunque se pueden pasar todas las opciones necesarias en la línea de comandos para comprobar si hay correo en un servidor remoto al ejecutar Fetchmail, el uso de .fetchmailrc proporciona un método más sencillo. Coloque todas las opciones de configuración deseadas en el archivo .fetchmailrc y estas se utilizarán cada vez que se ejecute el comando fetchmail. Es posible ignorar estas opciones en tiempo de ejecución especificando alguna opción en la línea de comandos.

Un archivo .fetchmailrc de usuario contiene tres clases de opciones de configuración:

  • opciones globales — Indican a Fetchmail las instrucciones que controlan el funcionamiento del programa o proporcionan las configuraciones para cada conexión que verifica por correo.

  • opciones de servidor — Especifican información necesaria sobre el servidor, como nombre de host, así como las preferencias para un servidor de correo particular, tal como el puerto a verificar o el número de segundos a esperar antes de un timeout. Estas opciones afectan a cada opción de usuario usado con ese servidor.

  • opciones de usuario — Contienen información, tal como nombre de usuario y contraseña, que es necesaria para autenticar y comprobar si hay correo utilizando un servidor de correo concreto.

Las opciones globales se encuentran en la parte superior del archivo .fetchmailrc, seguidas de una o varias opciones de servidor con las que se designa cada uno de los servidores de correo diferentes que debería comprobar Fetchmail. Por último, se encuentran las opciones de usuario específicas de cada cuenta de usuario que desea comprobar en el servidor de correo. Al igual que las opciones de servidor, se pueden especificar varias opciones de usuario para utilizarlas con un servidor determinado así como también comprobar varias cuentas de correo electrónico en el mismo servidor.

Las opciones de servidor se llaman para ejecución en el archivo .fetchmailrc mediante el uso de una opción especial, poll o skip, que precede cualquier información de servidor. La acción poll indica a Fetchmail que use esta opción de servidor cuando se ejecute, lo que en realidad verifica por correo usando las opciones de usuario. Cualquier opción de servidor luego de una acción skip, sin embargo, no se verificará a menos que este nombre de host sea especificado cuando se llama Fetchmail. La opción skip es muy útil cuando se evalúan configuraciones en .fetchmailrc pues sólo chequea servidores saltados cuando se invoquen específicamente, y no afecta ninguna configuracion en funcionamiento actualmente.

Un archivo .fetchmailrc de ejemplo se vería así:

set postmaster "user1" set bouncemail poll pop.domain.com proto pop3 user 'user1' there with password 'secret' is user1 here poll mail.domain2.com user 'user5' there with password 'secret2' is user1 here user 'user7' there with password 'secret3' is user1 here

En este ejemplo, las opciones globales establecen que se le envíe correo al usuario en última instancia (opción postmaster) y que todos los errores de correo se manden al postmaster en lugar de al emisor (opción bouncemail). La acción set indica a Fetchmail que esta línea contiene una opción global. A continuación, se especifican dos servidores de correo: uno para que compruebe si hay correo con el protocolo POP3 y otro para que pruebe a usar varios protocolos para encontrar uno que funcione. Se comprueba el correo de dos usuarios con la segunda opción de servidor, pero todo el correo que se encuentre se envía al spool de correo del user1. Esto permite comprobar varios buzones en diversos servidores como si se tratara de un único buzón MUA. La información específica de cada usuario comienza con la acción user.

Nota

No es necesario que los usuarios coloquen sus contraseñas en el archivo .fetchmailrc. El omitir la sección with password '<password>' causa que Fetchmail solicite una contraseña cuando es lanzado.

Fetchmail contiene muchas opciones diferentes globales, de servidor y locales. Muchas de estas opciones casi nunca se usan o sólo se aplican en situaciones muy específicas. La página del manual de fetchmail explica cada opción en detalle, pero las usadas más a menudo se listan aquí.

24.3.3.2. Opciones globales

Cada opción global debería ser colocada en una línea individual después de una acción set.

  • daemon <seconds> — Indica a Fetchmail usar el modo de demonio, con el que estará en segundo plano. Reemplace <seconds> con el número de segundos que Fetchmail debe esperar antes de consultar el servidor.

  • postmaster — Indica a Fetchmail un usuario local para enviar el correo en caso de problemas de entrega.

  • syslog — Indica a Fetchmail el registro de mensajes de error y de estado. Por defecto, es /var/log/maillog.

24.3.3.3. Opciones de servidor

Las opciones de servidor deben ser colocadas en su propia línea en .fetchmailrc después de una acción poll o skip.

  • auth <auth-type> — Especifica el tipo de autenticación que se utilizará. Por defecto, se utiliza la autenticación por password pero algunos protocolos admiten también otros tipos de autenticación, entre los que se incluyen kerberos_v5, kerberos_v4 y ssh. Si se usa el tipo de autenticación any, Fetchmail primero usará métodos que no necesiten contraseña y luego otros que creen máscara para la contraseña. Finalmente, intentará enviar la contraseña sin encriptar para ser autenticada al servidor.

  • interval <number> — Registra el servidor especificado cada <number> de veces que verifica por correo en todos los servidores configurados. Esta opción es generalmente utilizada por servidores de correo donde el usuario rara vez recibe mensajes.

  • port <port-number> — Reemplace <port-number> con el número de puerto. Este valor sobreescribe el número de puerto por defecto para un protocolo especificado.

  • proto <protocol> — Sustituya <protocol> con el protocolo, tal como pop3 or imap, a utilizar cuando se verifique por mensajes en el servidor.

  • timeout <seconds> — Sustituya <seconds> con el número de segundos de inactividad del servidor después de los cuales Fetchmail abandonará el intento de conexión. Si no se define este valor, se asume un valor de 300 segundos.

24.3.3.4. Opciones de usuario

Las opciones de usuario se pueden insertar en sus propias líneas debajo de una opción de servidor o en la misma línea que la opción de servidor. En cualquier caso, las opciones definidas van después de la opción user (definida más abajo).

  • fetchall — Ordena a Fetchmail descargar todos los mensajes en cola, incluidos los mensajes que ya se han visto. Por defecto, Fetchmail sólo lo hace con los nuevos mensajes.

  • fetchlimit <number> — Sustituya <number> con el número de mensajes a recuperar antes de detenerse.

  • flush — Elimina todos los mensajes en cola que ya se han visto antes de descargar mensajes nuevos.

  • limit <max-number-bytes> — Reemplace <max-number-bytes> con el tamaño máximo en bytes que pueden tener los mensajes recuperados por Fetchmail. Esta opción es útil con enlaces lentos, cuando un mensaje largo toma mucho tiempo en descargarse.

  • password '<password>' — Reemplace <password> con la contraseña del usuario.

  • preconnect "<command>" — Sustituya <command> con un comando a ejecutar antes de recuperar los mensajes de este usuario.

  • postconnect "<command>" — Sustituya <command> con el comando a ejecutar después de recuperar los mensajes de este usuario.

  • ssl — Activa la encriptación SSL.

  • user "<username>" — Reemplace <username> con el nombre de usuario que Fetchmail usa para recuperar los mensajes. Esta opción debe listarse antes de cualquier otra opción de usuario.

24.3.3.5. Opciones de comando de Fetchmail

La mayoría de las opciones de Fetchmail utilizadas en la línea de comando al ejecutar el comando fetchmail, reflejan las opciones de configuración de .fetchmailrc. Esto se realiza para que se pueda usar Fetchmail con o sin un archivo de configuración. La mayoría de los usuarios no usan estas opciones en la línea de comandos porque les resulta más sencillo dejarlas en el archivo .fetchmailrc.

Sin embargo, en ocasiones puede estar interesado en ejecutar el comando fetchmail con otras opciones para un fin concreto. Es posible producir opciones de comando para que temporalmente se ignore una configuración .fetchmailrc que está causando un error, puesto que cualquier opción especificada en la línea de comandos sobreescribe las opciones del archivo de configuración.

24.3.3.6. Opciones de depuración o información

Algunas opciones usadas luego del comando fetchmail pueden suministrar información importante.

  • --configdump — Muestra cada opción posible en función de la información de .fetchmailrc y los valores por defecto de Fetchmail. No se recupera correo de ningún usuario al usar esta opción.

  • -s — Ejecuta Fetchmail en modo silencioso, con lo cual se evita que aparezcan mensajes, excepto errores, después del comando fetchmail.

  • -v — Ejecuta Fetchmail en modo detallado y muestra todas las comunicaciones entre Fetchmail y los servidores de correo remotos.

  • -V — Hace que Fetchmail muestre información de versión detallada, una lista de las opciones globales y los parámetros que se utilizarán con cada usuario, incluido el protocolo de correo y el método de autenticación. No se recupera correo de ningún usuario al usar esta opción.

24.3.3.7. Opciones especiales

Estas opciones son en ocasiones útiles para sobrescribir los valores por defecto que a menudo contiene el archivo .fetchmailrc.

  • -a — Indica a Fetchmail que descargue todos los mensajes del servidor de correo remoto, ya se hayan o no visto antes. Por defecto, Fetchmail sólo descarga los mensajes nuevos.

  • -k — Hace que Fetchmail deje una copia de los mensajes en el servidor de correo remoto después de descargarlos. Esta opción sobrescribe el comportamiento por defecto de eliminar los mensajes después de descargarlos.

  • -l <max-number-bytes> — Indica a Fetchmail que no descargue mensajes con un tamaño superior al indicado y dejarlos en el servidor de correo remoto.

  • --quit — Sale del proceso de demonio de Fetchmail.

Se pueden encontrar más comandos y opciones de .fetchmailrc en la página del manual de fetchmail.

24.4. Configuración del Agente de Transporte de Correo (MTA)

Un Agente de Transporte de Correo (MTA) es esencial para enviar correos electrónicos. Un Agente Usario de Correo (MUA) tal como Evolution, Thunderbird y Mutt se utiliza para leer y componer correos electrónicos. Cuando un usuario envía un correo electrónico desde un MUA el mensaje se entrega al MTA, el cual envía el mensaje por medio de una serie de MTAs hasta que alcanza su destino.

Si un usuario no tiene previsto enviar un email desde el sistema, algunas tareas automatizadas o programas del sistema utilizarán el comando /bin/mail para enviar un correo electrónico que contenga mensajes de registro para el usuario root del sistema local.

Red Hat Enterprise Linux 5 tiene tres MTAs: Sendmail, Postfix y Exim. Si los tres están instalados, sendmail es el MTA predeterminado. El Conmutador del Agente de Transporte de Correos le permite a un usuario seleccionar o sendmail, postfix, o exim como el MTA predeterminado para el sistema.

El paquete RPM system-switch-mail tiene que ser instalado para utilizar la versión basada en texto del programa Conmutador del Agente de Transporte de Correos. Si quiere utilizar la versión gráfica también tiene que tener instaldo el paquete system-switch-mail-gnome.

Nota

Para obtener mayor información sobre la instalación de los paquetes RPM consulte Parte II, “Administración de paquetes”.

Para iniciar Conmutador de Agente de Transporte de Correo seleccione Sistema (el menú principal en el panel) => Administración => Conmutador de Agente de Transporte de Correo o escriba el comando system-switch-mail en el intérprete de comandos de shell (por ejemplo, en una terminal XTerm o GNOME).

El programa detecta automáticamente si el sistemas de ventanas X se está ejecutando. Si si lo está haciendo, el programa inicia en modo gráfico como se muestra en Figura 24.1, “Conmutador de Agente de Transporte de Correo. Si X no es detectado, inicia en modo de texto. Para forzar al Conmutador del Agente de Transporte de Correo a que ejecute en modo de texto utilice el comando system-switch-mail-nox.

Conmutador de Agente de Transporte de Correo

Captura de pantalla del Conmutador del Agente de Transporte de Correo

Figura 24.1. Conmutador de Agente de Transporte de Correo

Si selecciona OK para cambiar el MTA el demonio de correo seleccionado es habilitado para iniciar en tiempo de arranque y los demonios de correo que no se han seleccionado son deshabilitados para que no inicen en tiempo de arranque. El demonio de correo seleccionado es iniciado y cualquier otro demonio de correo será detenido lo cual hará que los cambios sean efectivos inmediatamente.

24.5. Agente de entrega de correo

Red Hat Enterprise Linux incluye dos MDAs principales, Procmail y mail. Ambas aplicaciones son consideradas Agentes de entrega local (LDAs) y ambas mueven el correo desde el archivo spool MTA al buzón de correo del usuario. Sin embargo, Procmail proporciona un sistema robusto de filtrado de correo.

Esta sección detalla solamente Procmail. Para información sobre el comando mail, consulte su página man.

Procmail entrega y filtra correo mientras es colocado en el archivo spool de correo de la máquina local. Es una herramienta eficaz, que hace un uso adecuado de los recursos del sistema y de amplio uso. Procmail desempeña un papel crítico en la entrega de correo a ser leído por las aplicaciones clientes de correo.

Procmail se puede invocar de muchas formas diferentes. Cada vez que un MTA coloca un correo en el archivo spool de correo, Procmail es lanzado. Procmail luego filtra y archiva el correo para el MUA y sale. Alternativamente, el MUA puede ser configurado para ejecutar Procmail cada vez que se recibe un mensaje y así los mensajes son movidos en sus buzones correctos. Por defecto, la presencia de un archivo /etc/procmailrc o .procmailrc (también llamado archivo rc) en el directorio principal del usuario llamará a Procmail cada vez que un MTA reciba un nuevo mensaje.

Las acciones que toma Procmail con un correo dependen de si el mensaje coincide con un grupo de condiciones o de recetas particulares en el archivo rc. Si un mensaje coincide con la receta o regla, entonces el correo se ubicará en un determinado archivo, se eliminará o se procesará.

Cuando Procmail arranca, lee el mensaje de correo y separa el cuerpo de la información de cabecera. A continuación, busca los archivos /etc/procmailrc y rc en el directorio por defecto /etc/procmailrcs, de todo el sistema, así como las variables de entorno Procmail y reglas. Luego busca si hay un archivo .procmailrc en el directorio principal del usuario. Muchos usuarios también crean archivos rc adicionales para Procmail a los que se hace referencia dentro de .procmailrc en su directorio principal.

Por defecto, no hay archivos rc aplicables a todo el sistema en el directorio /etc/ y ningún archivo de .procmailrc existe en ningún directorio de usuarios. Por lo tanto, para comenzar a usar Procmail, cada usuario debe construir un archivo .procmailrc con variables de entorno y reglas particulares.

24.5.1. Configuración de Procmail

El archivo de configuración de Procmail contienen variables de entorno importantes. Estas variables especifican cosas tales como, qué mensajes deben ordenarse, qué hacer con los mensajes que no coinciden con ninguna receta, etc.

Estas variables de entorno normalmente aparecen al principio del archivo .procmailrc con el siguiente formato:

<env-variable>="<value>"

En este ejemplo, <env-variable> es el nombre de la variable y <value> define la variable.

La mayor parte de los usuarios de Procmail no utilizan muchas variables de entorno y muchas de las variables de entorno más importantes ya están definidas con un valor por defecto. La mayoría de las veces tratará con las siguientes variables:

  • DEFAULT — Establece el buzón por defecto en el que se ubicarán los mensajes que no coincidan con ninguna receta.

    El valor por defecto DEFAULT es el mismo que $ORGMAIL.

  • INCLUDERC — Especifica archivos rc adicionales que contienen más recetas para los que deben comprobarse los mensajes. Esto permite desglosar las listas de recetas de Procmail en archivos individuales que cumplen papeles diferentes, tales como como bloquear correo basura y gestionar listas de correo, que se pueden activar o desactivar con caracteres de comentario en el archivo de usuario .procmailrc.

    Por ejemplo, las líneas en el archivo .procmailrc del usuario se pueden parecer a lo siguiente:

    MAILDIR=$HOME/Msgs INCLUDERC=$MAILDIR/lists.rc INCLUDERC=$MAILDIR/spam.rc
    

    Si el usuario desea desactivar el filtro de Procmail para las listas de correo, pero quiere controlar el correo basura, solamente deberá comentar la primera línea INCLUDERC con un carácter #.

  • LOCKSLEEP — Establece cuanto tiempo, en segundos, entre los intentos de Procmail de usar un lockfile concreto. El valor por defecto es ocho segundos.

  • LOCKTIMEOUT — Establece la cantidad de tiempo, en segundos, que debe transcurrir después de modificar un lockfile para que Procmail asuma que este lockfile es antiguo y que se puede eliminar. El valor por defecto es 1024 segundos.

  • LOGFILE — El archivo que contendrá los mensajes de error o de información de Procmail.

  • MAILDIR — Establece el directorio de trabajo actual de Procmail. Si se define este directorio, todas las otras rutas de Procmail serán relativas a este directorio.

  • ORGMAIL — Especifica el buzón original u otro lugar para colocar los mensajes si no se pueden ubicar en la ubicación de receta o por defecto.

    Por defecto, se utiliza un valor de /var/spool/mail/$LOGNAME.

  • SUSPEND — Establece la cantidad de tiempo, en segundos, que Procmail se detendrá si no está disponible un recurso necesario, tal como espacio de intercambio (swap).

  • SWITCHRC — Permite a un usuario especificar un archivo externo que contiene recetas de Procmail adicionales, como la opción INCLUDERC, excepto que la verificación de recetas es en realidad detenida en el archivo de configuración referido y sólo se usan las recetas en el archivo SWITCHRC especificado.

  • VERBOSE — Hace que Procmail registre mucha más información. Esta opción es útil para procesos de depuración.

Otras variables de entorno importantes se extraen del shell, tal como LOGNAME, que es el nombre de conexión, HOME, que es la ubicación del directorio principal y SHELL, que es el shell por defecto.

Hay una explicación completa de todas las variables de entorno y sus valores por defecto en la página man de procmailrc.

24.5.2. Recetas de Procmail

Con frecuencia los usuarios nuevos consideran que la creación de recetas es la parte más difícil de Procmail. En cierto modo, esto es lógico, ya que las recetas comparan los mensajes con las expresiones regulares, el cual es un formato específico que se utiliza para especificar calificaciones para una cadena coincidente. Sin embargo, las expresiones regulares no son difíciles de crear, e incluso es más fácil entenderlas cuando se leen. Además, la consistencia en la forma en que las recetas de Procmail están escritas, independientemente de las expresiones regulares, facilita aprender a través de ejemplos. Para ver ejemplos de recetas consulte Sección 24.5.2.5, “Ejemplos de recetas”.

Una receta de Procmail tiene la siguiente estructura:

:0<flags>: <lockfile-name> * <special-condition-character><condition-1> * <special-condition-character><condition-2> * <special-condition-character><condition-N><special-action-character><action-to-perform>

Los dos primeros caracteres de una receta de Procmail son dos puntos y un cero. Opcionalmente, se pueden insertar varios indicadores después del cero para controlar cómo Procmail procesa la receta. Dos puntos después de la sección <flags> especifica que se creará un lockfile para este mensaje. Si se crea un lockfile, debe especificar su nombre en el espacio <lockfile-name>.

Una receta puede contener varias condiciones con las que se comparará el mensaje. Si no tiene condiciones, cada mensaje coincide la receta. Las expresiones regulares se insertan en algunas condiciones para facilitar su comparación con un mensaje. Si se usan varias condiciones, todas ellas deben coincidir para que se realice una acción. Las condiciones se comprueban en función de los indicadores establecidos en la primera línea de la receta. El uso de caracteres especiales opcionales que se insertan después del carácter * permiten controlar todavía más la condición.

La opción <action-to-perform> especifica lo que le ocurrirá a un mensaje si coincide con una de las condiciones. Sólo puede haber una acción por receta. En muchos casos, se usa aquí el nombre de un buzón para dirigir los mensajes que coinciden con ese archivo con el fin de ordenar de una manera eficaz el correo. También se pueden utilizar caracteres de acción especiales antes de especificar la acción. Consulte la Sección 24.5.2.4, “Condiciones y acciones especiales” para obtener mayor información.

24.5.2.1. Recetas de entrega vs. recetas de no entrega

La acción usada si la receta coincide con un mensaje concreto determina si la receta se considera de entrega o de no entrega. Una receta de entrega contiene una acción que registra el mensaje a un archivo, envía el mensaje a otro programa o reenvía el mensaje a otra dirección de correo. Una receta de no entrega cubre cualquier otra acción, como el uso de un bloque de anidamiento. Un bloque de anidamiento es un conjunto de acciones entre llaves {}, que designa las acciones adicionales que deben realizarse en los mensajes que cumplen las condiciones de la receta. Los bloques de anidamiento pueden ser anidados uno entre otro, lo cual proporciona un mayor control a la hora de identificar y realizar acciones en los mensajes.

Cuando los mensajes coinciden con una receta de entrega, Procmail lleva a cabo la acción especificada y deja de comparar el mensaje con otras recetas. Los mensajes que coinciden con recetas de no entrega siguen siendo comparados contra otras recetas.

24.5.2.2. Indicadores

Los indicadores son muy importantes para determinar cómo o si se compararán las condiciones de una receta con un mensaje. Los siguientes indicadores son de uso común:

  • A — Especifica que esta receta sólo se usará si la receta anterior sin un indicador A o a también coincidió con este mensaje.

  • a — Especifica que esta receta sólo se usará si la receta anterior con un indicador A o a también coincidió con este mensaje y se completó exitosamente.

  • B — Analiza el cuerpo del mensaje y busca condiciones coincidentes.

  • b — Utiliza el cuerpo en cualquier acción resultante, como escribir el mensaje a un archivo o reenviarlo. Este es el comportamiento por defecto.

  • c — Genera una copia al carbón (CC) del correo. Es útil para la entrega de recetas, puesto que la acción necesaria se puede realizar en el mensaje y se puede seguir procesando una copia del mensaje en los archivos rc.

  • D — Hace una comparación egrep que distingue entre mayúsculas y minúsculas. Por defecto, el proceso de comparación no distingue entre mayúsculas y minúsculas.

  • E — Similar al indicador A, con la diferencia de que las condiciones de la receta sólo se comparan con el mensaje si la receta inmediatamente anterior sin un indicador E no coincide. Se puede comparar con la acción else.

  • e — Solamente se compara la receta con el mensaje si la acción especificada en la receta inmediatamente anterior falla.

  • f — Usa la canalización (pipes) como filtro.

  • H — Analiza la cabecera del mensaje y busca condiciones coincidentes. Este es el comportamiento por defecto.

  • h — Usa la cabecera en la acción resultante. Este es el comportamiento por defecto.

  • w — Indica a Procmail que debe esperar a que finalice el proceso del filtro o programa especificado, y que cree un informe indicando si tuvo éxito o no antes de considerar el mensaje como filtrado.

  • W — Esto es idéntico a w excepto que se eliminan los mensajes "Program failure".

Para una lista detallada de los indicadores asicionales, consulte la página man de procmailrc.

24.5.2.3. Especificación de un Lockfile local

Los archivos lockfiles son muy útiles en Procmail para garantizar que no más de un proceso intenta alterar un mensaje concreto al mismo tiempo. Puede especificar un lockfile local si inserta un carácter de dos puntos (:)después de cualquier indicador en la primera línea de una receta. Con esto se creará un lockfile local basado en el nombre de archivo de destino más cualquier otro valor definido en la variable de entorno global LOCKEXT.

Como alternativa, puede especificar el nombre del lockfile local que se usará con esta receta después del carácter :.

24.5.2.4. Condiciones y acciones especiales

El uso de caracteres especiales antes de las condiciones y acciones de recetas de Procmail cambian el modo en que se interpretan.

Los siguientes caracteres se pueden usar después del carácter * al principio de una línea de condición de receta:

  • ! — En la línea de condición, invierte la condición y ocasiona que sólo se produzca una coincidencia si la condición no coincide con el mensaje.

  • < — Comprueba si el mensaje está por debajo de un número especificado de bytes.

  • > — Comprueba si el mensaje está sobre un número especificado de bytes.

Los siguientes caracteres se utilizan para realizar acciones especiales:

  • ! — En la línea de acción, este carácter le indica a Procmail que reenvie el mensaje a las direcciones de correo especificadas.

  • $ — Hace referencia a una variable establecida anteriormente en el archivo rc. Se usa normalmente para configurar un buzón común que utilizarán varias recetas.

  • | — Inicia un programa especificado para procesar el mensaje.

  • { y } — Crea un bloque de anidamiento que se usa para contener recetas adicionales a aplicar a los mensajes coincidentes.

Si no se utiliza un carácter especial al principio de la línea de acción, Procmail asume que la línea de acción está especificando el buzón en donde registrar el mensaje.

24.5.2.5. Ejemplos de recetas

Procmail es un programa extremadamente flexible. Sin embargo, como resultado de esta flexibilidad, la composición de una receta de Procmail desde cero para alcanzar un objetivo concreto, puede resultar una labor muy complicada para los usuarios nuevos.

La mejor forma de desarrollar habilidades para construir recetas Procmail parte de un buen entendimiento de las expresiones regulares combinadas con la revisión de ejemplos construídos por otros. No entra en el ámbito de este capítulo ofrecer una explicación extensa sobre las expresiones regulares. La estructura de las recetas de Procmail es más importante y hay ejemplos útiles de ellas en varios sitios de Internet (por ejemplo en http://www.iki.fi/era/procmail/links.html). Se puede obtener el uso y la adaptación adecuada de las expresiones regulares contenidas en estos ejemplos observando estos ejemplos de recetas. Puede encontrar información básica sobre las reglas de expresiones regulares en las páginas man de grep.

Los ejemplos siguientes demuestran la estructura básica de las recetas Procmail y pueden suministrar la base para construcciones más elaboradas.

Una receta básica puede que ni siquiera tenga condiciones, como se demuestra en el siguiente ejemplo:

:0: new-mail.spool

La primera línea especifica que se cree un lockfile local pero sin indicar un nombre, de modo que Procmail utilice el nombre del archivo de destino y anexa el valor especificado en la variable de ambiente LOCKEXT. No se especifica ninguna condición y, por tanto, cada mensaje coincide con esta receta y se insertará en el archivo de spool denominado new-mail.spool, que se encuentra dentro del directorio especificado por la variable de entorno MAILDIR. Un agente MUA puede a continuación ver los mensajes de este archivo.

Se puede colocar una receta básica como esta, al final de todos los archivos rc para dirigir los mensajes a una ubicación por defecto.

El ejemplo siguiente coincide los mensajes provenientes de una dirección de correo específica y los descarta.

:0 * ^From: spammer@domain.com /dev/null

Con este ejemplo, cualquier mensaje enviado por spammer@domain.com se mueve inmediatamente al dispositivo /dev/null, eliminándolos.

Atención

Asegúrese de que una regla funciona adecuadamente antes de mover los mensajes a /dev/null, que supone una eliminación permanente. Si las condiciones de receta "atrapan" inadvertidamente mensajes no destinados correctamente y estos mensajes desaparecen sin dejar rastro, entonces se hace más difícil revisar problemas en la regla.

Una solución mejor es dirigir la acción de la receta a un buzón especial que compruebe de vez en cuando para buscar positivos falsos. Una vez comprobado que no se han coincidido por error los mensajes, puede eliminar el buzón y dirigir la acción para enviar los mensajes a /dev/null.

La receta siguiente atrapa el correo enviado a una lista de correo particular y lo coloca en una carpeta indicada.

:0: * ^(From|CC|To).*tux-lug tuxlug

Cualquier mensaje enviado desde la lista de distribución tux-lug@domain.com se colocará automáticamente en el buzón tuxlug para el agente MUA. Tenga en cuenta que la condición de este ejemplo comparará el mensaje si tiene la dirección de correo de la lista de distribución en las líneas Desde, CC, o Para.

Para obtener más detalles consulte los muchos recursos disponibles para Procmail en línea en la Sección 24.7, “Recursos adicionales”.

24.5.2.6. Filtros de correo basura

Puesto que Procmail es llamado por Sendmail, Postfix y Fetchmail cuando reciben nuevos correos, se puede usar también como una herramienta poderosa para combatir correo basura.

Esto es particularmente cierto cuando Procmail es usado en conjunto con SpamAssassin. Cuando se usan juntos, estas dos aplicaciones pueden identificar rápidamente correo basura y ordenarlos o destruirlos.

SpamAssassin usa análisis de las cabeceras, de texto, listas negras, una base de datos de seguimiento de correo basura y el análisis de correo basura Bayesiano de autoaprendizaje, para identificar y marcar efectivamente el correo basura.

La forma más fácil para que un usuario local use SpamAssassin es colocar la siguiente línea cerca de la parte superior del archivo ~/.procmailrc:

INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc

El /etc/mail/spamassassin/spamassassin-default.rc contiene una regla simple de Procmail que activa SpamAssassin para todo el correo entrante. Si un correo es identificado como basura, se marca en la cabecera como tal y en el título se coloca:

*****SPAM*****

El cuerpo del mensaje es también marcado al principio con una lista de qué elementos provocaron que fuese considerado basura.

Para archivar correo marcado como basura, se puede usar una regla similar a lo siguiente:

:0 Hw * ^X-Spam-Status: Yes spam

Esta regla archiva todo el correo marcado como basura en el buzón de correo llamado spam.

Puesto que SpamAssassin es un script Perl, puede ser necesario en servidores ocupados usar un demonio binario SpamAssassin (spamd) y la aplicación cliente (spamc). Configurar SpamAssassin de esta forma requiere acceso root.

Para arrancar el demonio spamd, escriba el siguiente comando como usuario root:

/sbin/service spamassassin start

Para iniciar el demonio SpamAssassin cuando se inicia el sistema, use una utilidad initscript, tal como la Herramienta de Configuración de Servicios (system-config-services), para activar el servicio spamassassin. Consulte la para más información sobre las utilidades initscript.

Para configurar Procmail a usar la aplicación cliente SpamAssassin en vez de un script Perl, coloque la siguiente línea cerca de la parte superior del archivo ~/.procmailrc . Para una configuración global del sistema, colóquela en /etc/procmailrc:

INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

24.6. Agentes de usuario de correo

Hay muchos programas de correo disponibles bajo Red Hat Enterprise Linux. Hay programas gráficos de clientes de correo con características completas tal como Ximian Evolution así como también programas basados en texto, tales como mutt.

El resto de esta sección se enfoca en asegurar la comunicación entre el cliente y el servidor.

24.6.1. Comunicación segura

Los MUAs populares incluidos con Red Hat Enterprise Linux tales como Ximian Evolution y mutt ofrecen sesiones de correo electrónico encriptadas con SSL.

Al igual que otros servicios existentes en una red no cifrada, la información de correo electrónico importante, como nombres de usuario, contraseñas y mensajes, se puede interceptar y ver sin que tenga conocimiento el servidor o el cliente de correo. Al usar los protocolos estándar POP e IMAP, toda la información de autenticación se envía "limpiamente", sin encriptar, por lo que es posible para un intruso ganar acceso a las cuentas de usuarios reuniendo los nombres de los usuarios y sus contraseñas cuando estos son transmitidos sobre la red.

24.6.1.1. Clientes de correo electrónico seguros

Afortunadamente, la mayoría de los agentes MUA de Linux diseñados para comprobar correo en servidores remoto utilizan SSL. Para usar SSL al recuperar el correo, se debe activar esta opción en el cliente y en el servidor de correo.

SSL se activa muy fácilmente en el cliente, normalmente basta con pulsar un botón en el área de configuración del agente MUA o mediante una opción en el archivo de configuración del MUA. Los protocolos IMAP y POP seguros tienen números de puerto conocidos (993 y 995, respectivamente) que el MUA utiliza para autenticar y descargar los mensajes.

24.6.1.2. Asegurar las comunicaciones de cliente de correo

Ofrecer cifrado SSL a los usuarios de IMAP y POP del servidor de correo es muy sencillo.

Primero, cree un certificado SSL. Esto se puede hacer de dos formas: solicitando a una Certificate Authority (CA) por un certificado SSL o mediante la creación de un certificado auto-firmado.

Atención

Los certificados auto-firmados solamente deberían ser usados para propósitos de prueba. Cualquier servidor usado en un ambiente de producción debería usar un certificado SSL emitido por una CA.

Para crear un certificado SSL con firma propia para IMAP, cámbiese al directorio /etc/pki/tls/certs/ y escriba el comando siguiente como root:

rm -f cyrus-imapd.pem make cyrus-imapd.pem

Conteste todas las preguntas para completar el proceso.

Para crear un certificado SSL con firma propia para POP, cámbiese al directorio /etc/pki/tls/certs/ y escriba los siguientes comandos como usuario root:

rm -f ipop3d.pem make ipop3d.pem

Una vez más, conteste todas las preguntas para completar el proceso.

Importante

Asegúrese de eliminar los archivos predeterminados imapd.pem y ipop3d.pem antes de ejecutar el comando make.

Una vez finalizado, ejecute el comando /sbin/service xinetd restart para reiniciar el demonio xinetd que controla imapd y ipop3d.

Alternativamente, el comando stunnel puede ser usado como una envoltura de criptación SSL con el estándar, para los demonios no seguros, imapd o pop3d.

El programa stunnel utiliza bibliotecas OpenSSL externas incluidas con Red Hat Enterprise Linux para proporcionar una criptografía robusta y proteger las conexiones. Es mejor solicitar a una Autoridad de Certificación (Certificate Authority, CA) un certificado SSL, pero también es posible crear un certificado auto-firmado.

Para crear un certificado SSL auto-firmado, cámbiese al directorio /etc/pki/tls/certs/ y escriba el /etc/pki/tls/certs/ siguiente comando:

make stunnel.pem

Una vez más, conteste todas las preguntas para completar el proceso.

Una vez que el certificado es generado, es posible usar el comando stunnel para iniciar el demonio de correo imapd usando el comando siguiente:

/usr/sbin/stunnel -d 993 -l /usr/sbin/imapd imapd

Una vez que este comando es emitido, es posible abrir un cliente de correo IMAP y conectarse al servidor de correo usando una encriptación SSL.

Para arrancar pop3d usando el comando stunnel, escriba el comando siguiente:

/usr/sbin/stunnel -d 995 -l /usr/sbin/pop3d pop3d

Para más información sobre el uso de stunnel, lea la página man stunnel o refiérase a los documentos en el directorio /usr/share/doc/stunnel-<version-number>/, donde <version-number> es el número de versión para stunnel.

24.7. Recursos adicionales

La siguiente es una lista con la documentación adicional sobre las aplicaciones de correo.

24.7.1. Documentación instalada

  • Información sobre la configuración de Sendmail es incluida con los paquetes sendmail y sendmail-cf.

    • /usr/share/sendmail-cf/README — Contiene información sobre m4, ubicaciones de archivos para Sendmail, transportadores de correo soportados, cómo acceder a las características avanzadas y más.

    Además, las páginas man de sendmail y aliases contienen información útil sobre varias opciones de Sendmail y la configuración adecuada del archivo Sendmail /etc/mail/aliases.

  • /usr/share/doc/postfix-<version-number>/ — Este directorio contiene una gran cantidad de información sobre Postfix. Reemplace <version-number> con el número de la versión de Postfix.

  • /usr/share/doc/fetchmail-<version-number> — Contiene una lista completa de las características de Fetchmail en el archivo FEATURES y un documento FAQ introductorio. Reemplace <version-number> con el número de versión de Fetchmail.

  • /usr/share/doc/procmail-<version-number> — Contiene un archivo README que proporciona una visión general de Procmail, un archivo FEATURES que explora cada característica del programa y una sección FAQ con respuestas a muchas de las pregunas comunes. Reemplace <version-number> con el número de versión de Procmail.

    Mientras aprende cómo Procmail funciona y cómo crear nuevas recetas, las siguientes páginas man son de gran utilidad:

    • procmail — Proporciona una vista general de cómo Procmail funciona y los pasos implicados cuando se esté filtrando correo.

    • procmailrc — Explica el formato del archivo rc usado para construir recetas.

    • procmailex — Proporciona un número de ejemplos de la vida real de recetas Procmail.

    • procmailsc — Explica la técnica de puntaje por pesos usada por Procmail para ver si una receta particular coincide un mensaje.

    • /usr/share/doc/spamassassin-<version-number>/ — Este directorio contiene una gran cantidad de información sobre SpamAssassin. Reemplace <version-number> con el número de la versión del paquete spamassassin.

24.7.2. Sitios web útiles

  • http://www.sendmail.org/ — Ofrece un desglose completo de las características técnicas de Sendmail y ejemplos de configuración.

  • http://www.sendmail.com/ — Contiene noticias, entrevistas y artículos concernientes a Sendmail, incluyendo una vista ampliada de las muchas opciones disponibles.

  • http://www.postfix.org/ — La página principal para el proyecto Procmail con mucha información sobre Postfix. La lista de correo es un buen lugar para comenzar a buscar información.

  • http://fetchmail.berlios.de/ — La página principal para Fetchmail, presentando un manual en línea y una sección Preguntas Frecuentes (FAQ) completa.

  • http://www.procmail.org/ — La página principal para Procmail con enlaces a listas de correo varias dedicadas a Procmail así como también varios documentos FAQ.

  • http://partmaps.org/era/procmail/mini-faq.html — Una sección FAQ excelente de Procmail, ofrece sugerencias para la solución de problemas, detalles sobre bloqueo de archivos y el uso de comodines.

  • http://www.uwasa.fi/~ts/info/proctips.html — Contiene docenas de sugerencias que hacen el uso de Procmail mucho más fácil. Incluye instrucciones sobre cómo probar los archivos .procmailrc y usar el puntaje de Procmail para decidir si una acción particular debería ser tomada.

  • http://www.spamassassin.org/ — El sitio oficial del proyecto SpamAssassin.

24.7.3. Libros relacionados

  • Sendmail Milters: A Guide for Fighting Spam por Bryan Costales y Marcia Flynt; Addison-Wesley — Un buen manual sobre Sendmail que le puede ayudar a personalizar sus filtros de correo.

  • Sendmail por Bryan Costales con Eric Allman et al; O'Reilly & Associates — Una buena referencia sobre Sendmail escrita con la ayuda del creador original de Delivermail y Sendmail.

  • Removing the Spam: Email Processing and Filtering por Geoff Mulligan; Addison-Wesley Publishing Company — Un volumen que muestra varios métodos usados por los administradores de correo usando herramientas establecidas, tales como Sendmail y Procmail, para manejar los problemas del correo basura.

  • Internet Email Protocols: A Developer's Guide por Kevin Johnson; Addison-Wesley Publishing Company — Proporciona una revisión profunda de los principales protocolos y la seguridad que éstos proporcionan.

  • Managing IMAP por Dianna Mullet y Kevin Mullet; O'Reilly & Associates — Detalla los pasos necesarios para configurar un servidor IMAP.

Capítulo 25. Protocolo Ligero de Acceso a Directorios (LDAP)

El Protocolo Ligero de Acceso a Directorios (en inglés, Lightweight Directory Access Protocol, LDAP) es un conjunto de protocolos abiertos usados para acceder información almacenada centralmente a través de la red. Está basado en el estándar X.500 para compartir directorios, pero es menos complejo e intensivo en el uso de recursos. Por esta razón, a veces se habla de LDAP como "X.500 Lite." El estándar X.500 es un directorio que contiene información de forma jerárquica y categorizada que puede incluir nombres, directorios y números telefónicos.

Como X.500, LDAP organiza la información en un modo jerárquico usando directorios. Estos directorios pueden almacenar una gran variedad de información y se pueden incluso usar de forma similar al Servicio de información de red (NIS), permitiendo que cualquiera pueda acceder a su cuenta desde cualquier máquina en la red acreditada con LDAP.

Sin embargo, en la mayoría de los casos, LDAP se usa simplemente como un directorio telefónico virtual, permitiendo a los usuarios acceder fácilmente la información de contacto de otros usuarios. Pero LDAP va mucho más lejos que un directorio telefónico tradicional, ya que es capaz de propagar su consulta a otros servidores LDAP por todo el mundo, proporcionando un repositorio de información ad-hoc global. Sin embargo, en este momento LDAP se usa más dentro de organizaciones individuales, como universidades, departamentos del gobierno y compañías privadas.

LDAP es un sistema cliente/servidor. El servidor puede usar una variedad de bases de datos para guardar un directorio, cada uno optimizado para operaciones de lectura rápidas y en gran volúmen. Cuando una aplicación cliente LDAP se conecta a un servidor LDAP puede, o bien consultar un directorio, o intentar modificarlo. En el evento de una consulta, el servidor, puede contestarla localmente o puede dirigir la consulta a un servidor LDAP que tenga la respuesta. Si la aplicación cliente está intentando modificar información en un directorio LDAP, el servidor verifica que el usuario tiene permiso para efectuar el cambio y después añade o actualiza la información.

Este capítulo hace referencia a la configuración y uso de OpenLDAP 2.0, una implementación de código abierto de los protocolos LDAPv2 y LDAPv3.

25.1. Razones por las cuales usar LDAP

La mayor ventaja de LDAP es que se puede consolidar información para toda una organización dentro de un repositorio central. Por ejemplo, en vez de administrar listas de usuarios para cada grupo dentro de una organización, puede usar LDAP como directorio central, accesible desde cualquier parte de la red. Puesto que LDAP soporta la Capa de conexión segura (SSL) y la Seguridad de la capa de transporte (TLS), los datos confidenciales se pueden proteger de los curiosos.

LDAP también soporta un número de bases de datos back-end en las que se guardan directorios. Esto permite que los administradores tengan la flexibilidad para desplegar la base de datos más indicada para el tipo de información que el servidor tiene que diseminar. También, ya que LDAP tiene una interfaz de programación de aplicaciones (API) bien definida, el número de aplicaciones acreditadas para LDAP son numerosas y están aumentando en cantidad y calidad.

25.1.1. Características de OpenLDAP

OpenLDAP incluye un número de características importantes.

  • Soporte LDAPv3 — OpenLDAP soporta la Capa de autenticación y seguridad (SASL), la Seguridad de la capa de transporte (TLS) y la Capa de conexión segura (SSL), entre otras mejoras. Muchos de los cambios en el protocolo desde LDAPv2 han sido diseñados para hacer LDAP más seguro.

  • Soporte IPv6 — OpenLDAP soporta la próxima generación del protocolo de Internet versión 6.

  • LDAP sobre IPC — OpenLDAP se puede comunicar dentro de un sistema usando comunicación interproceso (IPC). Esto mejora la seguridad al eliminar la necesidad de comunicarse a través de la red.

  • API de C actualizada — Mejora la forma en que los programadores se conectan para usar servidores de directorio LDAP.

  • Soporte LDIFv1 — Provee compatibilidad completa con el formato de intercambio de datos, Data Interchange Format (LDIF) versión 1.

  • Servidor Stand-Alone mejorado — Incluye un sistema de control de acceso actualizado, conjunto de hilos, herramientas mejoradas y mucho más.

25.2. Terminología LDAP

Cualquier discusión sobre LDAP requiere un entendimiento básico del conjunto de términos específicos de LDAP:

  • entrada — una entrada es una unidad en un directorio LDAP. Cada entrada se identifica por su único Nombre distinguido (Distinguished Name (DN)).

  • atributos — Los atributos son piezas de información directamente asociada con la entrada. Por ejemplo, una organización puede ser representada como una entrada LDAP. Los atributos asociados con la organización pueden ser su número de fax, su dirección, etc. En un directorio LDAP las entradas pueden ser también personas, con atributos comunes como el número de teléfono y la dirección de e-mail.

    Algunos atributos son obligatorios mientras que otros son opcionales. Una definición objectclass determina los atributos que se necesitan y los que no para cada entrada. Las definiciones de objectclass se encuentran en varios archivos de esquema dentro del directorio /etc/openldap/schema/. Para obtener mayor información consulte la Sección 25.5, “El directorio /etc/openldap/schema/.

    La afirmación de un atributo y su valor correspondiente también se conocen como Nombre Distinguido Relativo (RDN). Un RDN sólamente es único por entrada mientras que un DN es unico globalmente.

  • LDIF — El Formato de intercambio de datos de LDAP (LDIF) es una representación de texto ASCII de entradas LDAP. Los archivos usados para importar datos a los servidores LDAP deben estar en formato LDIF. Una entrada LDIF se ve similar al ejemplo siguiente:

    [<id>] dn: <distinguished name>
    <attrtype>: <attrvalue> 
    <attrtype>: <attrvalue> 
    <attrtype>: <attrvalue>
    

    Una entrada puede contener tantos pares <attrtype>: <attrvalue> como sean necesarios. Una línea en blanco indica el final de una entrada.

    Aviso

    Todas las parejas <attrtype> y <attrvalue>deben estar definidas en el archivo esquema correspondiente para usar esta información.

    Cualquier valor comprendido dentro de < y > es una variable y puede ser configurado cuando se cree una nueva entrada LDAP. Sin embargo, esta regla no se aplica a <id>. El <id> es un número determinado por la aplicación que se usa para modificar la entrada.

25.3. Demonios y utilidades OpenLDAP

El grupo de bibliotecas y herramientas OpenLDAP están incluidas en los paquetes siguientes:

  • openldap — Contiene las librerías necesarias para ejecutar las aplicaciones del servidor y cliente OpenLDAP.

  • openldap-clients — Contiene herramientas de línea de comandos para visualizar y modificar directorios en un servidor LDAP.

  • openldap-server — Contiene los servidores y otras utilidades necesarias para configurar y ejecutar un servidor LDAP.

Hay dos servidores contenidos en el paquete openldap-servers: el Demonio independiente LDAP (/usr/sbin/slapd) y el Demonio independiente de actualización de réplicas LDAP (/usr/sbin/slurpd).

El demonio slapd es el servidor independiente LDAP mientras que el demonio slurpd es usado para sincronizar los cambios desde un servidor LDAP a otro en la red. El demonio slurpd sólo es usado cuando se trabaja con múltiples servidores LDAP.

Para llevar a cabo tareas administrativas, el paquete openldap-server instala las utilidades siguientes en el directorio /usr/sbin/:

  • slapadd — Añade entradas desde un archivo LDIF a un directorio LDAP. Por ejemplo, el comando /usr/sbin/slapadd -l ldif-input leerá en el archivo LDIF, ldif-input, que contiene las nuevas entradas.

    Importante

    Debe ser usuario root para usar /usr/sbin/slapadd. Sin embargo, el servidor de directorio se ejecuta como usuario ldap. Por lo tanto, el servidor de directorio no podrá modificar ningún archivo creado por slapadd. Para corregir este problema, después que haya terminado de usar slapadd, escriba el comando siguiente:

    chown -R ldap /var/lib/ldap
    
  • slapcat — Extrae entradas de un directorio LDAP en el formato por defecto Sleepycat Software's Berkeley DB, y las guarda en un archivo LDIF. Por ejemplo, el comando /usr/sbin/slapcat -l ldif-output tendrá como resultado un archivo LDIF llamado ldif-output que contendrá las entradas para el directorio LDAP.

  • slapindex — Re-indexa el directorio slapd basado en el contenido actual. Esta herramienta se debería ejecutar siempre que se cambien las opciones de indexado dentro de /etc/openldap/slapd.conf.

  • slappasswd — Genera un valor de contraseña encriptada de usuario para ser usada con ldapmodify o el valor rootpw en el archivo de configuración slapd, /etc/openldap/slapd.conf. Ejecute el comando /usr/sbin/slappasswd para crear la contraseña.

Aviso

Asegúrese de detener slapd ejecutando /sbin/service lapd stop antes de usar slapadd, slapcat o slapindex. De otro modo se pondrá en riesgo la integridad del directorio LDAP.

Para más información sobre cómo utilizar estas utilidades, consulte sus páginas del manual respectivas.

El paquete openldap-clients instala herramientas utilizadas para agregar, modificar y borrar entradas en un directorio LDAP dentro de /usr/bin/ Estas herramientas incluyen lo siguiente:

  • ldapadd — Agrega entradas a un directorio LDAP aceptando entradas vía archivo o entrada estándar; ldapadd es en realidad un enlace duro a ldapmodify -a.

  • ldapdelete — Borra entradas de un directorio LDAP al aceptar instrucciones del usuario por medio de la entrada desde el indicador de comandos o por medio de un archivo.

  • ldapmodify — Modifica las entradas en un directorio LDAP, aceptando la entrada por medio de un archivo o entrada estándar.

  • ldappasswd — Configura una contraseña para un usuario LDAP.

  • ldapsearch — Busca por entradas en el directorio LDAP usando un indicador de comandos shell.

  • ldapcompare — Abre una conexión a un servidor LDAP, se vincula y hace una comparación utilizando parámetros especificados.

  • ldapwhoami — Abre una conexión en un servidor LDAP, se vincula y realiza una operación whoami.

  • ldapmodrdn — Abre una conexión en un servidor LDAP, se vincula y modifica los RDNs de entradas.

Con la excepción de ldapsearch, cada una de estas utilidades se usa más fácilmente haciendo referencia a un archivo que contiene los cambios que se deben llevar a cabo, que escribiendo un comando para cada entrada que se desea cambiar en un directorio LDAP. El formato de dicho archivo está esquematizado en las páginas del manual sobre cada utilidad.

25.3.1. NSS, PAM, y LDAP

Además de los paquetes OpenLDAP, Red Hat Enterprise Linux incluye un paquete llamado nss_ldap, el cual mejora la habilidad de LDAP para integrarse tanto en Linux como en otros ambientes UNIX.

El paquete nss_ldap provee los siguientes módulos (en donde <version> se refiere a la versión de libnss_ldap en uso):

  • /lib/libnss_ldap-<version>.so

  • /lib/security/pam_ldap.so

El paquete nss_ldap provee los siguientes módulos para las arquitecturas Itanium o AMD64.

  • /lib64/libnss_ldap-<version>.so

  • /lib64/security/pam_ldap.so

El módulo libnss_ldap-<version>.so permite a las aplicaciones buscar usuarios, grupos, hosts y otra información utilizando un directorio LDAP por medio de la interfaz de glibcNameservice Switch (NSS). NSS permite a las aplicaciones autenticarse usando LDAP junto con el servicio de nombres de NIS y archivos de autenticación planos.

El módulo pam_ldap permite que las aplicaciones PAM puedan validar usuarios utilizando la información almacenada en el directorio LDAP. Las aplicaciones PAM incluyen conexiones desde la consola, servidores de correo POP e IMAP y Samba. Al desarrollar un servidor LDAP en una red, se pueden autentificar todas estas aplicaciones usando la misma combinación de nombre de usuario y contraseña, simplificando en gran medida la administración.

25.3.2. PHP4, LDAP y el Servidor HTTP Apache

Red Hat Enterprise Linux incluye también un paquete que contiene un módulo LDAP para el lenguaje de comandos del servidor PHP.

El paquete php-ldap añade soporte LDAP al lenguaje incluido en HTML, PHP4 a través del módulo /usr/lib/php4/ldap.so. Este módulo permite a los scripts PHP4 acceder a información almacenada en un directorio LDAP.

Red Hat Enterprise Linux se entrega con el módulo mod_authz_ldap para el Servidor HTTP Apache. Este módulo utiliza la forma corta del nombre distinguido para un sujeto y el emisor del certificado de cliente SSL para determinar el nombre distinguido de un usuario dentro de un directorio LDAP. También es capaz de autorizar usuarios basado en los atributos de esa entrada del usuario del directorio LDAP, determinando el acceso a los activos basado en los privilegios de usuario y grupo de ese activo y negando el acceso a los usuarios con contraseñas caducadas. Se requiere el módulo mod_ssl cuando se utilice el módulo mod_authz_ldap.

Importante

El módulo mod_authz_ldap no autentica a un usuario en un directorio LDAP usando un hash de contraseña encriptado. Esta funcionalidad es proporcionada por el módulo experimental mod_auth_ldap, el cual no está incluido con Red Hat Enterprise Linux. Para más detalles sobre el estado de este módulo vea el sitio web de la Apache Software Foundation en http://www.apache.org/.

25.3.3. Aplicaciones cliente LDAP

Existen clientes gráficos de LDAP que soportan la creación y modificación de directorios, pero no se entregan con Red Hat Enterprise Linux. Una de estas aplicaciones es LDAP Browser/Editor — Una herramienta basada en Java que está disponible en línea en http://www.iit.edu/~gawojar/ldap/.

Otros clientes LDAP acceden a directorios como sólo lectura, utilizándolos como referencia, pero sin alterar información a lo largo de la organización. Algunos ejemplos de tales aplicaciones son Sendmail, Mozilla, Gnome Meeting, and Evolution.

25.4. Archivos de configuración de OpenLDAP

Los archivos de configuración OpenLDAP son instalados dentro del directorio /etc/openldap/. A continuación aparece una lista breve marcando los directorios y archivos más importantes:

  • /etc/openldap/ldap.conf — Este es el archivo de configuración para todas las aplicaciones cliente que usan las bibliotecas OpenLDAP tales como ldapsearch, ldapadd, Sendmail, Pine, Balsa, Evolution, y Gnome Meeting.

  • /etc/openldap/slapd.conf — Este es el archivo configuración para el demonio slapd. Vea la Sección 25.6.1, “Modificar /etc/openldap/slapd.conf para obtener más información sobre este archivo.

  • Directorio /etc/openldap/schema/— Este subdirectorio contiene el esquema utilizado por el demonio slapd. Vea la Sección 25.5, “El directorio /etc/openldap/schema/ para obtener más información sobre este directorio.

Nota

Si está instalado el paquete nss_ldap creará un archivo llamado /etc/ldap.conf. Este archivo es usado por los módulos PAM y NSS proporcionados por el paquete nss_ldap. Vaya a Sección 25.7, “Configurar un sistema para la autenticación mediante OpenLDAP” para obtener más información.

25.5. El directorio /etc/openldap/schema/

El directorio /etc/openldap/schema/ almacena las definiciones LDAP, previamente ubicadas en los archivos slapd.at.conf y slapd.oc.conf. El directorio /etc/openldap/schema/redhat/ guarda esquemas personalizados distribuidos por Red Hat para Red Hat Enterprise Linux.

Todas las definiciones de sintaxis de atributos y las definiciones de objectclass son ahora ubicadas en los diferentes archivos de esquema. Los archivos de esquemas son referenciados en /etc/openldap/slapd.conf usando líneas include, como se muestra en este ejemplo:

include                /etc/openldap/schema/core.schema 
include                /etc/openldap/schema/cosine.schema 
include                /etc/openldap/schema/inetorgperson.schema 
include                /etc/openldap/schema/nis.schema 
include                /etc/openldap/schema/rfc822-MailMember.schema 
include                /etc/openldap/schema/redhat/autofs.schema

Aviso

No modifique ninguno de los ítems de esquemas definidos en los archivos de esquemas instalados por OpenLDAP.

Puede extender el esquema usado por OpenLDAP para soportar tipos de atributos adicionales y clases de objetos usando los archivos de esquema por defecto como una guía. Para lograr esto, cree un archivo local.schema en el directorio /etc/openldap/schema. Referencie este nuevo esquema dentro de slapd.conf agregando la línea siguientes debajo de las líneas include por defecto:

include          /etc/openldap/schema/local.schema

Luego, defina nuevos tipos de atributos y clases de objetos dentro del archivo local.schema. Muchas organizaciones usan los tipos de atributos existentes a partir de los archivos esquema instalados por defecto y agregan nuevas clases de objeto al archivo local.schema.

Ampliar esquemas para cubrir requerimientos específicos es un poco complicado y está más allá del ámbito de éste capítulo. Visite http://www.openldap.org/doc/admin/schema.html para más información.

25.6. Descripción general de la configuración de OpenLDAP

Esta sección explica rápidamente la instalación y la configuración del directorio OpenLDAP. Para más información, consulte las URLs siguientes:

Los pasos básicos para crear un servidor LDAP son los siguientes:

  1. Instale los RPMs openldap, openldap-servers y openldap-clients.

  2. Modifique el archivo /etc/openldap/slapd.conf para referenciar su dominio y servidor LDAP. Para obtener mayor información consulte la Sección 25.6.1, “Modificar /etc/openldap/slapd.conf.

  3. Inicie slapd con el comando:

    /sbin/service ldap start
    

    Después de configurar LDAP, puede usar chkconfig, /usr/sbin/ntsysv, o Herramienta de configuración de serviciospara configurar LDAP para que se inicie en el momento de arranque. Para obtener más información sobre cómo configurar servicios refiérase al capítulo Capítulo 16, Control de acceso a servicios.

  4. Agregue entradas a un directorio LDAP con ldapadd.

  5. Use ldapsearch para ver si slapd accede a la información correctamente.

  6. Llegados a este punto, su directorio LDAP debería estar funcionando correctamente y se puede configurar con aplicaciones capacitadas para LDAP.

25.6.1. Modificar /etc/openldap/slapd.conf

Para poder usar el servidor LDAP slapd, tendrá que modificar su archivo de configuración, /etc/openldap/slapd.conf para especificar el dominio y servidor correcto.

La línea de suffix nombra el dominio para el cual el servidor LDAP proveerá información y deberá ser cambiado de:

suffix          "dc=your-domain,dc=com"

Modifiquelo para que refleje un nombre de dominio completamente calificado. Por ejemplo:

suffix          "dc=example,dc=com"

La entrada rootdn es el Nombre distinguido (DN) para un usuario que no está restringido por el control de acceso o los parámetros de límites administrativos fijados para operaciones en el directorio LDAP. Se puede pensar en el usuario rootdn como el usuario root para el directorio LDAP. En el archivo de configuración, cambie la línea rootdn de su valor por defecto a algo similar a lo siguiente:

rootdn          "cn=root,dc=example,dc=com"

Cuando esté poblando el directorio LDAP sobre una red, cambie la línea rootpw — reemplazando el valor por defecto con una cadena de contraseña encriptada. Para crear una cadena de contraseña encriptada, escriba el comando siguiente:

slappasswd

Se le pedirá ingresar y re-ingresar la contraseña, luego el programa muestra la contraseña resultante encriptada al terminal.

Luego, copie la nueva contraseña encriptada en el archivo >/etc/openldap/slapd.conf en alguna de las líneas rootpw y elimine el símbolo de almohadilla (#).

Cuando termine, la línea debería de verse como el ejemplo siguiente:

rootpw {SSHA}vv2y+i6V6esazrIv70xSSnNAJE18bb2u

Aviso

Las contraseñas LDAP, incluyendo la directiva rootpw especificada en /etc/openldap/slapd.conf, son enviadas sobre la red sin encriptar, a menos que active la encriptación TLS.

Para activar la encriptación TLS, revise los comentarios en /etc/openldap/slapd.conf y vea la página del manual para slapd.conf.

Para mayor seguridad, la directriz rootpw debería ser colocada entre comentarios después de poblar el directorio LDAP simplemente escribiendo el símbolo de almohadilla (#).

Cuando utilice la herramienta de línea de comandos /usr/sbin/slapadd localmente para poblar el directorio LDAP, el uso de la directiva rootpw no es necesario.

Importante

Debe ser usuario root para usar /usr/sbin/slapadd. Sin embargo, el servidor de directorio se ejecuta como usuario ldap. Por lo tanto, el servidor de directorio no podrá modificar ningún archivo creado por slapadd. Para corregir este problema, después que haya terminado de usar slapadd, escriba el comando siguiente:

chown -R ldap /var/lib/ldap

25.7. Configurar un sistema para la autenticación mediante OpenLDAP

Este sección ofrece una perspectiva general de cómo configurar la autenticación usando OpenLDAP. A menos que usted sea un experto en OpenLDAP necesitará más información de la que le proporcionamos aquí. Para obtener más información consulte las referencias proporcionadas en Sección 25.9, “Recursos adicionales”.

Instale los paquetes LDAP Necesarios

Primero, debería asegurarse de tener los paquetes apropiados en ambos, el servidor LDAP y las máquinas cliente LDAP. El servidor LDAP requiere el paquete openldap-server.

Los paquetes openldap, openldap-clients, y nss_ldap necesitan estar instalados en todas las máquinas LDAP clientes.

Modifique los Archivos de Configuración

  • En el servidor, modifique el archivo /etc/openldap/slapd.conf en el servidor LDAP para asegurarse de que corresponde con las especificaciones de su organización. Por favor refiérase a Sección 25.6.1, “Modificar /etc/openldap/slapd.conf para obtener instrucciones sobre la modificación de slapd.conf.

  • En las máquinas clientes, ambos archivos /etc/ldap.conf y /etc/openldap/ldap.conf necesitan contener el servidor apropiado y la información base de búsqueda para la organización.

    Para hacer esto, ejecute Herramienta de Configuración de Autenticación (system-config-authentication) y seleccione Activar Soporte LDAP bajo la pestaña Información de Usuario.

    También puede editar estos archivos manualmente.

  • En las máquinas clientes, el archivo /etc/nsswitch.conf debe ser editado para usar LDAP.

    Para hacer esto, ejecute Herramienta de Configuración de Autenticación (system-config-authentication) y seleccione Activar Soporte LDAP bajo la pestaña Información de Usuario.

    Si está modificando el archivo /etc/nsswitch.conf manualmente, agregue ldap a las líneas adecuadas.

    Por ejemplo:

    passwd: files ldap
    shadow: files ldap
    group: files ldap
    

25.7.1. PAM y LDAP

25.7.2. Migrar la información de autenticación antigua al formato LDAP

El directorio /usr/share/openldap/migration/ contiene un conjunto de scripts de shell y Perl para la migración de información de autenticación en el formato LDAP.

Nota

Debe tener Perl instalado en su sistema para usar estos scripts.

Primero, modifique el archivo migrate_common.ph para que refleje el dominio correcto. El dominio DNS por defecto debería ser modificado desde su valor por defecto a algo como lo siguiente:

$DEFAULT_MAIL_DOMAIN = "example";

La base por defecto también debería ser modificada para que se parezca a:

$DEFAULT_BASE = "dc=example,dc=com";

La tarea de migrar una base de datos de usuario a un formato que pueda leer LDAP le corresponde a un grupo de scripts de migración instalado en el mismo directorio. Usando la Sección 43.4, “Pluggable Authentication Modules (PAM)” decida cúal script va a ejecutar para poder migrar su base de datos de usuario.

Ejecute el script apropiado basándose en el nombre del servicio actual.

Los archivos README y migration-tools.txt en el directorio /usr/share/openldap/migration/ dan más detalles sobre cómo migrar la información.

Nombre del servicio actual ¿Está LDAP ejecutándose? Utilice este script
/etc archivos planos si migrate_all_online.sh
/etc archivos planos no migrate_all_offline.sh
NetInfo si migrate_all_netinfo_online.sh
NetInfo no migrate_all_netinfo_offline.sh
NIS (YP) si migrate_all_nis_online.sh
NIS (YP) no migrate_all_nis_offline.sh
Tabla 25.1. Scripts de migración de LDAP

25.8. Migración de directorios desde versiones anteriores

With Red Hat Enterprise Linux, OpenLDAP uses Sleepycat Software's Berkeley DB system as its on-disk storage format for directories. Earlier versions of OpenLDAP used GNU Database Manager (gdbm). For this reason, before upgrading an LDAP implementation to Red Hat Enterprise Linux 5.2, original LDAP data should first be exported before the upgrade, and then reimported afterwards. This can be achieved by performing the following steps:

  1. Antes de actualizar el sistema operativo, ejecute el comando /usr/sbin/slapcat -l ldif-output. Esto produce un archivo LDIF llamado ldif-output que contendrá las entradas del directorio LDAP.

  2. Actualice el sistema operativo, teniendo cuidado de no reformatear la partición que contiene el archivo LDIF.

  3. Vuelva a importar el directorio LDAP al formato Berkeley DB actualizado ejecutando el comando /usr/sbin/slapadd -l ldif-output.

25.9. Recursos adicionales

Los recursos siguientes ofrecen información adicional sobre LDAP. Por favor revise estas fuentes, especialmente el sitio web de OpenLDAP y la sección HOWTO de LDAP, antes de configurar LDAP en su sistema.

25.9.1. Documentación instalada

  • /usr/share/docs/openldap-<versionnumber>/ directory — Contiene un documento README e información general.

  • Páginas man relacionadas con LDAP — Existen varias páginas man para las diferentes aplicaciones y archivos de configuración relacionados con LDAP. La lista siguiento muestra algunas de las páginas man más importantes.

    Aplicaciones cliente
    • man ldapadd — Describe cómo añadir entradas a un directorio LDAP.

    • man ldapdelete — Describe cómo eliminar entradas dentro de un directorio LDAP.

    • man ldapmodify — Describe cómo modificar entradas en un directorio LDAP.

    • man ldapsearch — Describe cómo buscar entradas en un directorio LDAP.

    • man ldappasswd — Describe cómo configurar o cambiar la contraseña de un usuario LDAP.

    • man ldapcompare — Describe como utilizar la herramienta ldapcompare.

    • man ldapwhoami — Describe como utilizar la herramienta ldapwhoami.

    • man ldapmodrdn — Describe como modificar los RDNs de entradas.

    Aplicaciones servidor
    • man slapd — Describe las opciones de línea de comandos disponibles para un servidor LDAP.

    • man slurpd — Describe las opciones de línea de comandos disponibles para el servidor de réplicas LDAP.

    Aplicaciones administrativas
    • man slapadd — Describe las opciones de línea de comandos utilizadas para añadir entradas a la base de datos slapd.

    • man slapcat — Describe las opciones de línea de comandos utilizadas para generar un archivo LDIF desde una base de datos slapd.

    • man slapindex — Describe las opciones de línea de comando usadas para regenerar un índice basado en los contenidos de una base de datos slapd.

    • man slappasswd — Describe las opciones de línea de comandos utilizadas para generar contraseñas de usuarios para directorios LDAP.

    Archivos de configuración
    • man ldap.conf — Describe el formato y las opciones disponibles dentro del archivo de configuración para clientes LDAP.

    • man slapd.conf — Describe el formato y las opciones disponibles dentro del archivo de configuración referenciado por las aplicaciones del servidor LDAP (slapd y slurpd) y por las herramientas administrativas LDAP (slapadd, slapcat y slapindex).

25.9.2. Sitios web útiles

  • http://www.openldap.org/ — Hogar del Proyecto OpenLDAP. Este sitio web contiene una gran variedad de información sobre la configuración de OpenLDAP así como también una guía para los futuros cambios de versiones.

  • http://www.padl.com/ — Desarrolladores de nss_ldap y pam_ldap, entre otras herramientas útiles de LDAP.

  • http://www.kingsmountain.com/ldapRoadmap.shtml — Jeff Hodges' LDAP Road Map contiene enlaces a muchas secciones FAQs de utilidad y a noticias recientes concernientes al protocolo LDAP.

  • http://www.ldapman.org/articles/ — Articulos que ofrecen una buena introducción a LDAP, incluyendo métodos para diseñar un árbol y personalizar estructuras de directorios.

25.9.3. Libros relacionados

  • OpenLDAP by Example por John Terpstra y Benjamin Coles; Prentice Hall.

  • Implementing LDAP de Mark Wilcox; Wrox Press, Inc.

  • Understanding and Deploying LDAP Directory Services por Tim Howes et al.; Macmillan Technical Publishing.

Capítulo 26. Configuración de la autenticación

Cuando un usuario se conecta a un sistema Red Hat Enterprise Linux, se verifican el nombre de usuario y la contraseña, o en otras palabras se autentifican, como un usuario activo válido. Algunas veces la información para verificar el usuario está localizada en el sistema local, otras veces el sistema delega la validación a una base de datos de usuarios en un sistema remoto.

La Herramienta de configuración de autenticación proporciona una interfaz gráfica para configurar NIS, LDAP y servidores Hesiod para recuperar información del usuario así como también para configurar LDAP, Kerberos y SMB como protocolos de autenticación.

Nota

Si configuró un nivel de seguridad medio o alto durante la instalación (o con la Herramienta de configuración del nivel de seguridad) entonces el cortafuegos no permitirá la autenticación NIS (Servicio de Información de la Red).

Este capítulo no explica cada uno de los diferentes tipos de autenticación en detalle. En vez de eso explica cómo usar la Herramienta de configuración de autenticación para configurarlos.

Para iniciar la versión gráfica de la Herramienta de configuración de autenticación desde el escritorio, seleccione el System (on the panel) => Administración => Authenticación o escriba el comando system-config-authentication en el intérprete de comandos (por ejemplo en una terminal XTerm o GNOME).

Importante

Después de salir del programa de autenticación, los cambios tendrán efecto de inmediato.

26.1. Información del usuario

La pestaña de Información del Usuario le permite configurar la manera en que los usuarios deben ser autenticados y tiene varias opciones. Para habilitar una opción, haga click en la casilla de verificación al lado de ella. Para inhabilitarla, haga click en la casilla para limpiarla. Luego haga click en OK para salir del programa y aplicar los cambios.

Información del usuario

Información del usuario

Figura 26.1. Información del usuario

La lista siguiente explica lo que configura cada una de las opciones:

NIS

La opción Habilitar Soporte NIS configurar el sistema para conectarse a un servidor NIS (como un cliente NIS) para la autentificación de usuarios y contraseñas. Haga click en el botón Configurar NIS... para especificar el dominio NIS y el servidor NIS. Si no se especifica el servidor NIS, el demonio intentará buscarlo vía difusión (broadcast).

Debe tener el paquete ypbind instalado para que esta opción funcione. Si el soporte NIS está activado, los servicios portmap y ypbind serán iniciados y también estarán habilitados para arrancar en el momento de inicio del sistema.

LDAP

La opción Habilitar el soporte LDAP le ordena al sistema que recupere información del usuario a través de LDAP. Haga click en el botón Configurar LDAP... para especificar lo siguiente:

  • DN de Base de Búsqueda LDAP — Recupera la información del usuario por medio de su nombre distinguido, Distinguished Name (DN).

  • Servidor LDAP — Especifique la dirección IP del servidor LDAP.

  • Use TLS para encriptar conexiones — Cuando se encuentra habilidata, se utilizará la Seguridad de la Capa de Transporte para encriptar las contraseñas enviadas al servidor LDAP. La opción Descargar Certificado AC le permite especificar una URL desde donde se podrá descargar un Certificado AC (Autoridad de Certificación) válido. Un Certificado CA válido tiene que estar en formato PEM (del inglés Correo con Privacidad Mejorada).

Debe tener instalado el paquete openldap-clients para que esta opción funcione.

Hesiod

La opción Habilitar soporte Hesiod configura el sistema para recuperar información (incluyendo información del usuario) desde una base de datos remota Hesiod. Haga clic en el botón Configurar Hesiod... para especificar lo siguiente:

  • Hesiod LHS — Especifica el prefijo del dominio que se utiliza para consultas Hesiod.

  • Hesiod RHS — Especifica el dominio Hesiod predeterminado.

El paquete hesiod debe estar instalado para que esta opción funcione.

Para obtener más información sobre Hesiod vaya a su página man utilizando el comando man hesiod. También se puede referir a la página man man hesiod. (man hesiod.conf) para obtener más información sobre LHS y RHS.

Winbind

La opción Habilitar Soporte Winbind configura el sistema para conectarse a un controlador de dominio Windows o Windows Active Directory. Se puede acceder a la información de los usuarios y configurar las opciones de autenticación del servidor. Haga click en el botón Configurar Winbind... para especificar lo siguiente:

  • Dominio Winbind — Especifica el Windows Active Directory o el controlador de dominio al cual conectarse.

  • Modelo de Seguridad — le permite seleccionar un modelo de seguridad, el cual configura la manera en que los clientes deben responder a Samba. La lista desplegable le permite seleccionar cualquiera de los siguientes:

    • usuario — Este es el modo predeterminado. Con este nivel de seguridad, el cliente debe iniciar la sesión con una nombre de usuario y una contraseña válidas. Este modo de seguridad también permite el uso de contraseñas encriptadas.

    • server — En este modo, Samba tratará de validar el nombre de usuario/contraseña autenticándolos a través de otro servidor SMB (por ejemplo, un Servidor Windows NT). Si no tiene exito tendrá efecto el modo user.

    • domain — En este modo Samba intentará validar el nombre de usuario/contraseña autenticándolos a través de Windows NT Primary o un Controlador de Dominio de Respaldo (Backup Domain Controller) de manera similar a lo que haría un Servidor Windows NT.

    • ads — Este modo le ordena a Samba que se comporte como un miembro de dominio en un Active Directory Server (ADS). Para operar de este modo necesita tener instalado el paquete krb5-server y Kerberos debe estar configurado apropiadamente.

  • Winbind ADS Realm — cuando se selecciona el Modelo de Seguridad ads, esto le permite especificar el Dominio ADS en el que el servidor Samba debe desempeñarse como un miembro de dominio.

  • Template Shell — Cuando llene la información del usuario para un usuario de Windows NT, el demonio winbindd utiliza el valor seleccionado aquí para especificar el shell de registro para ese usuario.

26.2. Autenticación

La pestaña de Autenticación permite la configuración de los métodos de autenticación de red. Para activar una opción haga click sobre la casilla de verificación al lado de la misma. Para desactivarla, haga click nuevamente sobre la casilla para desmarcarla o limpiarla.

Autenticación

Autenticación

Figura 26.2. Autenticación

A continuación se explica lo que configura cada opción:

Kerberos

La opción Habilitar el Soporte de Kerberos habilita la autenticación de Kerberos. Haga click en Configurar Kerberos... para abrir el diálogo Configuración de Kerberos Settings para configurar:

  • Entorno — Configure el entorno para el servidor de Kerberos. El entorno o reino es la red que Kerberos utiliza, compuesta de uno o más KDCs y un número potencial de muchos clientes.

  • KDC — Define el Centro de Distribución de Claves, Key Distribution Center (KDC), el cual es el servidor que emite los tickets de Kerberos.

  • Servidores de Administración — Especifica el o los servidores de administración ejecutando kadmind.

El diálogo Configuración de Kerberos también le permite utilizar DNS para resolver hosts en entornos y localizar KDCs para entornos.

LDAP

La opción Habilitar el soporte LDAP le ordena a las aplicaciones estándares PAM habilitadas para que utilicen LDAP para la autenticación. El botón Configurar LDAP... le permite configurar el soporte LDAP con opciones identicas a aquellas que se encuentran en Configurar LDAP... bajo la pestaña Information de Usuario. Para obtner mayor información sobre estas opciones vaya a Sección 26.1, “Información del usuario”.

Debe tener instalado el paquete openldap-clients para que esta opción funcione.

Tarjeta Inteligente

La opción Habilitar el soporte SMB habilita la autenticación por medio de tarjetas inteligentes. Esto permite que los usuarios inicien sesión utilizando un certificado y una llave asociada alamacenados en una tarjeta inteligente. Haga click en el botón Configurar SMB para ver más opciones.

SMB

La opción Habilitar el soporte SMB configura PAM para utilizar un servidor SMB para autentificar a los usuarios. SMB se refiere a un protocolo del servidor del cliente utilizado para la comunicación entre sistemas y Samba también lo utiliza para parecer como un servidor Windows para los clientes Windows. Haga click en el botón Configurar SMB para especificar:

  • Grupo de trabajo — Especifica el grupo de trabajo SMB a utilizar.

  • Controladores de Dominio — Especifica los controladores de dominio SMB a utilizar.

Winbind

La opción Habilitar el soporte Winbind configura la conexión del sistema con Windows Active Directory o con un controlador de dominios de Windows. Se puede acceder a la información de los usuarios y configurar las opciones de autenticación del servidor.

Las opciones Configurar Winbind... son idénticas a las del botón Configurar Winbind... en la pestaña Información de Usuario. Para obtener mayor información vaya a Winbind (bajo Sección 26.1, “Información del usuario”).

26.3. Options

Esta pestaña contiene otras opciones para configuración:

Opciones

Opciones

Figura 26.3. Opciones

Información del Usuario de la Caché

Seleccione esta opción para habilitar el demonio de cache de servicio de nombre (nscd) y configurarlo para que se inicie al momento de arranque.

El paquete nscd debe estar instalado para que esta opción funcione. Para obtener más detalles sobre nscd vaya a su página man utilizando el comando man nscd.

Utilice Contraseñas Shadow

Seleccione esta opción para guardar las contraseñas en formato de contraseñas shadow en el archivo /etc/shadow en vez de en /etc/passwd. Las contraseñas shadow son activadas por defecto durante la instalación y se recomiendan para incrementar la seguridad del sistema.

Utilice Contraseñas MD5

Seleccione esta opción para habilitar las contraseñas MD5, lo cual permite que las contraseñas tengan hasta 256 en vez de 8 o menos. Esta opción es seleccionada por defecto durante la instalación y se recomienda su uso para mayor seguridad.

Authorization local es suficiente para usuarios locales

Cuano esta opción se encuentra habilitada, el sistema no verificará la autorización desde los servicios de red (tal como LDAP o Kerberos) para las cuentas de usuarios mantenidas en su archivo /etc/passwd.

Autenticar cuentas del sistema por medio de servicios de red

Al habilitar esta opción se configura el sistema para permitir servicios de red (tal como LDAP o Kerberos) para autenticar cuentas del sistema (incluído root) en la máquina.

26.4. Versión de línea de comandos

La Herramienta de configuración de autenticación también se puede ejecutar como una herramienta de línea de comandos. La versión de línea de comandos se puede utilizar en un script de configuración de kickstart. Las opciones de autenticación son resumidas en la Tabla 26.1, “Opciones de línea de comandos”.

Sugerencia

Estas opciones también se pueden encontrar en la página del manual de authconfig o escribiendo authconfig --help en el intérprete de comandos.

Opción Descripción
--enableshadow Habilitar contraseñas shadow
--disableshadow Desactivar contraseñas shadow
--enablemd5 Habilitar contraseñas MD5
--disablemd5 Inhabilitar contraseñas MD5
--enablenis Habilitar NIS
--disablenis Inhabilitar NIS
--nisdomain=<domain> Especifica el dominio NIS
--nisserver=<server> Especifica el servidor NIS
--enableldap Habilitar LDAP para información del usuario
--disableldap Inhabilitar LDAP para información del usuario
--enableldaptls Habilitar el uso de TLS con LDAP
--disableldaptls Inhabilitar el uso de TLS con LDAP
--enableldapauth Habilitar LDAP para la autenticación
--disableldapauth Inhabilitar LDAP para la autenticación
--ldapserver=<server> Especifica un servidor LDAP
--ldapbasedn=<dn> Especifica un DN de base LDAP
--enablekrb5 Habilita Kerberos
--disablekrb5 Inhabilita Kerberos
--krb5kdc=<kdc> Especifica un KDC de Kerberos
--krb5adminserver=<server> Especifica un servidor de administración Kerberos
--krb5realm=<realm> Especifica el entorno Kerberos
--enablekrb5kdcdns Habilitar el uso de DNS para encontrar Kerberos KDCs
--disablekrb5kdcdns Deshabilitar el uso de DNS para encontrar Kerberos KDCs
--enablekrb5realmdns Habilitar el uso de DNS para encontrar Kerberos realms
--disablekrb5realmdns Deshabilitar el uso de DNS para encontrar Kerberos realms
--enablesmbauth Habilita SMB
--disablesmbauth Inhabilita SMB
--smbworkgroup=<workgroup> Specify SMB workgroup
--smbservers=<server> Especifica servidores SMB
--enablewinbind Habilitar winbind para la información del usuario por defecto
--disablewinbind Inhabilitar winbind para información del usuario por defecto
--enablewinbindauth Habilitar winbindauth para la autenticación por defecto
--disablewinbindauth Inhabilitar winbindauth para la autenticación por defecto
--smbsecurity=<user|server|domain|ads> Modos de seguridad para usar Samba y windbind
--smbrealm=<STRING> Campo por defecto para Samba y winbind cuando security=ads
--smbidmapuid=<lowest-highest> Rango UID que winbind asigna al dominio o usuario ADS
--smbidmapgid=<lowest-highest> Rango GID que winbind asigna al dominio o usuario ADS
--winbindseparator=<\> Caracter usado para separar la parte del usuario y del dominio de los nombres de usuario de winbind si winbindusedefaultdomain no está habilitado
--winbindtemplatehomedir=</home/%D/%U> Directorio de inicio de los usuarios winbind
--winbindtemplateprimarygroup=<nobody> Grupo primario de los usuarios winbind
--winbindtemplateshell=</bin/false> Shell por defecto de los usuarios winbind
--enablewinbindusedefaultdomain Configurar winbind para asumir que los usuarios sin dominio en sus nombres de usuarios son usuarios con dominio
--disablewinbindusedefaultdomain Configurar winbind para asumir que los usuarios sin dominio en sus nombres de usuarios son usuarios sin dominio
--winbindjoin=<Administrator> Unir el dominio winbind o campo ADS como este administrador
--enablewins Habilitar WINS para la resolución del nombre de host
--disablewins Inhabilitar WINS para la resolución del nombre de host
--enablehesiod Habilita Hesiod
--disablehesiod Inhabilita Hesiod
--hesiodlhs=<lhs> Especifica Hesiod LHS
--hesiodrhs=<rhs> Especifica Hesiod RHS
--enablecache Habilita nscd
--disablecache Inhabilita nscd
--nostart No arranca o detiene los servicios portmap, ypbind o nscd aún si ellos están configurados
--kickstart No muestra la interfaz del usuario
--probe Verifica y muestra las fallas de red
Tabla 26.1. Opciones de línea de comandos

Parte IV. Configuración del sistema

Parte del trabajo de un administrador de sistemas es configurar el sistema para varias tareas, tipos de usuarios y configuraciones de hardware. Esta sección explica cómo configurar un sistema Red Hat Enterprise Linux.

Tabla de contenidos

27. Acceso a consola
27.1. Deshabilitando el apagado a través de Ctrl-Alt-Del
27.2. Desactivación del acceso a programas de la consola
27.3. Definición de la consola
27.4. Colocar los archivos accesibles desde la consola
27.5. Activación del acceso a la consola para otras aplicaciones
27.6. El Grupo floppy
28. El directorio sysconfig
28.1. Archivos en el directorio /etc/sysconfig/
28.1.1. /etc/sysconfig/amd
28.1.2. /etc/sysconfig/apmd
28.1.3. /etc/sysconfig/arpwatch
28.1.4. /etc/sysconfig/authconfig
28.1.5. /etc/sysconfig/autofs
28.1.6. /etc/sysconfig/clock
28.1.7. /etc/sysconfig/desktop
28.1.8. /etc/sysconfig/dhcpd
28.1.9. /etc/sysconfig/exim
28.1.10. /etc/sysconfig/firstboot
28.1.11. /etc/sysconfig/gpm
28.1.12. /etc/sysconfig/hwconf
28.1.13. /etc/sysconfig/i18n
28.1.14. /etc/sysconfig/init
28.1.15. /etc/sysconfig/ip6tables-config
28.1.16. /etc/sysconfig/iptables-config
28.1.17. /etc/sysconfig/irda
28.1.18. /etc/sysconfig/keyboard
28.1.19. /etc/sysconfig/kudzu
28.1.20. /etc/sysconfig/named
28.1.21. /etc/sysconfig/network
28.1.22. /etc/sysconfig/nfs
28.1.23. /etc/sysconfig/ntpd
28.1.24. /etc/sysconfig/radvd
28.1.25. /etc/sysconfig/samba
28.1.26. /etc/sysconfig/selinux
28.1.27. /etc/sysconfig/sendmail
28.1.28. /etc/sysconfig/spamassassin
28.1.29. /etc/sysconfig/squid
28.1.30. /etc/sysconfig/system-config-securitylevel
28.1.31. /etc/sysconfig/system-config-selinux
28.1.32. /etc/sysconfig/system-config-users
28.1.33. /etc/sysconfig/system-logviewer
28.1.34. /etc/sysconfig/tux
28.1.35. /etc/sysconfig/vncservers
28.2. Directorios en el directorio /etc/sysconfig/
28.3. Recursos adicionales
28.3.1. Documentación instalada
29. Configuración de la fecha y hora
29.1. Propiedades de hora y fecha
29.2. Propiedades del protocolo de tiempo de red (NTP)
29.3. Configuración de la zona horaria
30. Configuración del Teclado
31. El Sistema X Window
31.1. El lanzamiento X11R7.1
31.2. Entornos de escritorio y gestores de ventanas
31.2.1. Entornos de escritorio
31.2.2. Gestores de ventanas
31.3. Archivos de configuración del servidor X
31.3.1. xorg.conf
31.4. Fuentes
31.4.1. Fontconfig
31.4.2. Sistema de fuentes base de X
31.5. Niveles de ejecución y X
31.5.1. Nivel de ejecución 3
31.5.2. Nivel de ejecución 5
31.6. Recursos adicionales
31.6.1. Documentación instalada
31.6.2. Sitios Web útiles
32. Configuración del Sistema X Window
32.1. Configuraciones de la visualización
32.2. Configuraciones del hardware de visualización
32.3. Configuraciones de visualización en dos pantallas
33. Usuarios y grupos
33.1. Configuración de grupos y de usuarios
33.1.1. Añadir un nuevo usuario
33.1.2. Modificar las propiedades del usuario
33.1.3. Añadir un nuevo grupo
33.1.4. Modificar las propiedades del grupo
33.2. Herramientas de administración de usuarios y grupos
33.2.1. Configuración desde la línea de comandos
33.2.2. Añadir un usuario
33.2.3. Añadir un grupo
33.2.4. Vencimiento de la contraseña
33.2.5. Explicación del proceso
33.3. Usuarios estándar
33.4. Grupos estándar
33.5. Grupos de usuario privado
33.5.1. Directorios de grupos
33.6. Contraseñas Shadow
33.7. Recursos adicionales
33.7.1. Documentación instalada
34. Configuración de la impresora
34.1. Añadir una impresora local
34.2. Añadir una impresora de red IPP
34.3. Añadir una impresora Samba (SMB)
34.4. Añadir una Impresora JetDirect
34.5. Selección del modelo de impresora
34.5.1. Confirmación de la configuración de la impresora
34.6. Imprimiendo una página de prueba
34.7. Modificar impresoras existentes
34.7.1. La pestaña Configuración
34.7.2. La pestaña Políticas
34.7.3. La Pestaña Control de Acceso
34.7.4. Las pestañas Opciones de la Impresora y Opciones de Trabajo
34.8. Administración de trabajos de impresión
34.9. Recursos adicionales
34.9.1. Documentación instalada
34.9.2. Sitios Web de utilidad
35. Tareas automáticas
35.1. Cron
35.1.1. Configuración de una tarea Cron
35.1.2. Control de acceso a Cron
35.2. At y Batch
35.2.1. Configuración de tareas
35.2.2. Configuración de tareas Batch
35.2.3. Visualización de las tareas pendientes
35.2.4. Opciones adicionales de la línea de comandos
35.2.5. Control de acceso a At y Batch
35.3. Recursos adicionales
35.3.1. Documentación instalada
36. Archivos de registro
36.1. Localizar archivos de registro
36.2. Visualizar los archivos de registro
36.3. Añadir un archivo de registro
36.4. Control de Archivos de Registro

Capítulo 27. Acceso a consola

Cuando los usuarios normales (no root) se registran en un equipo localmente, se les conceden dos tipos de permisos especiales:

  1. Pueden ejecutar ciertos programas que de otra forma no podrían ejecutar.

  2. Pueden tener acceso a ciertos archivos (normalmente archivos de dispositivos especiales usados para acceder a disquetes, CD-ROMs, etc) a los que no tendrían acceso de otro manera.

Puesto que un equipo tiene varias consolas y varios usuarios pueden registrarse a la vez localmente, uno de los usuarios tiene que ganar la carrera para acceder a los archivos. El primer usuario que se registra en la consola será el propietario de dichos archivos. Una vez que el primer usuario sale de la sesión, el siguiente usuario que se registra pasa a ser el propietario de los archivos.

En contraste, cada usuario que se registra en la consola podrá ejecutar programas que realizan tareas normalmente restringidas para ser ejecutadas por el usuario root. Si se ejecuta el sistema X, estas acciones se pueden incluir como elementos del menú en una interfaz gráfica de usuario. Tal y como se distribuyen, los programas accesibles desde una consola incluyen los comandos halt, poweroff, y reboot.

27.1. Deshabilitando el apagado a través de Ctrl-Alt-Del

Por defecto, /etc/inittab especifica que su sistema está configurado para apagarse y rearrancar el sistema si se utiliza la combinación de teclas Ctrl-Alt-Del en la consola. Si desea desactivar completamente esta opción, deberá colocar en comentario la línea /etc/inittab colocando un símbolo de numeral o almohadilla (#) en frente a ella:

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Opcionalmente, puede que también quiera permitir a algunos usuarios no root a que tengan derechos para apagar el sistema desde la consola con la combinación de teclas Ctrl-Alt-Del. Para limitar este privilegio a determinados usuarios, siga los pasos siguientes:

  1. Agregue la opción -a a la línea /etc/inittab mostrada arriba, de modo que se lea lo siguiente:

    ca::ctrlaltdel:/sbin/shutdown -a -t3 -r now
    

    El indicador -a indica al comando shutdown que debe buscar el archivo /etc/shutdown.allow.

  2. Cree un archivo denominado shutdown.allow en /etc. El archivo shutdown.allow debe mostrar los nombres de los usuarios que pueden apagar el sistema con la combinación de teclas Ctrl-Alt-Del. El formato del archivo shutdown.allow es una lista de nombres de usuario en cada línea. Por ejemplo:

    stephen jack sophie
    

De acuerdo a este archivo de ejemplo shutdown.allow los usuarios stephen, jack y sophie pueden apagar el sistema desde la consola con Ctrl-Alt-Del . Cuando se utiliza esta combinación de teclas, shutdown -a en /etc/inittab comprueba si alguno de los usuarios en /etc/shutdown.allow (o root) están conectados en una consola virtual. Si alguno de ellos lo está, el apagado del sistema continuará; en caso contrario, se registrará un mensaje de error en la consola del sistema.

Para más información sobre shutdown.allow, consulte la página man para shutdown.

27.2. Desactivación del acceso a programas de la consola

Para desactivar el acceso de los usuarios a los programas de la consola, debe ejecutar el siguiente comando como root:

rm -f /etc/security/console.apps/*

En los entornos en los que la consola tiene otro sistema de seguridad (se han establecido contraseñas en la BIOS y en el gestor de arranque, se ha desactivado la combinación de teclas Ctrl-Alt-Delete, se han desabilitado los interruptores de encendido y reinicio, etc.), probablemente no desee que ningún usuario que trabaje en una consola ejecute los comandos poweroff, halt, y reboot, a los que de manera predeterminada se puede tener acceso desde la consola.

Para quitar estas opciones, ejecute los siguientes comandos como root:

rm -f /etc/security/console.apps/poweroff rm -f /etc/security/console.apps/halt rm -f /etc/security/console.apps/reboot

27.3. Definición de la consola

El módulo pam_console.so usa el archivo /etc/security/console.perms para determinar los permisos que tienen los usuarios en la consola del sistema. La sintaxis del archivo es muy flexible; puede modificar el archivo para que estas instrucciones dejen de ser válidas. Sin embargo, el archivo por defecto tiene una línea similar a la siguiente:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]

Cuando los usuarios se registran, se conectan a algún terminal, bien sea un servidor X con un nombre como :0 o mymachine.example.com:1.0 o un dispositivo como /dev/ttyS0 o /dev/pts/2. La opción por defecto es definir esas consolas virtuales locales y que los servidores X locales se consideren locales, pero si desea considerar también el terminal serial próximo en el puerto /dev/ttyS1 puede cambiar la línea para que muestre:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] /dev/ttyS1

27.4. Colocar los archivos accesibles desde la consola

La configuración predeterminada para las definiciones de permisos y de clases de dispositivos individuales se encuentran definidas en /etc/security/console.perms.d/50-default.perms. Para modificar permisos de archivos y de dispositivos se aconseja que cree un nuevo archivo predeterminado en /etc/security/console.perms.d/ que contenga su configuración preferida para un grupo especial de archivos o dispositivos. El nombre de un archivo nuevo predeterminado debe comenzar con un número mayor que 50 (por ejemplo, 51-default.perms) para substituir 50-default.perms.

Para lograr esto, cree un nuevo archivo denominado 51-default.perms en /etc/security/console.perms.d/:

touch /etc/security/console.perms.d/51-default.perms

Abra el archivo predeterminado original perms, 50-default.perms. La primera sección define clases de dispositivos de una manera similar a esto:

<floppy>=/dev/fd[0-1]* \ /dev/floppy/* /mnt/floppy* <sound>=/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer \ /dev/sound/* /dev/beep \ /dev/snd/* <cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*

Lo que se encuentra entre corchetes le dan el nombre al dispositivo, en el ejemplo anterior <cdrom> se refiere al dispositivo de CD-ROM. Para añadir un nuevo dispositivo no lo defina en el archivo predeterminado 50-default.perms defínalo en 51-default.perms. Por ejemplo, para definir un escáner añada la siguiente línea a 51-default.perms:

<scanner>=/dev/scanner /dev/usb/scanner*

Por supuesto, debe utilizar el nombre apropiado del dispositivo. Asegúrese de que /dev/scanner es realmente su scanner y no el disco duro, por ejemplo.

Una vez que haya definido apropiadamente un dispositivo o un archivo, el segundo paso es especificar sus definiciones de permisos. La segunda sección de /etc/security/console.perms.d/50-default.perms define esto de una manera similar a esto:

<console> 0660 <floppy> 0660 root.floppy <console> 0600 <sound> 0640 root <console> 0600 <cdrom> 0600 root.disk

Para definir permisos para un escáner añada una línea similar a esta en 51-default.perms:

<console> 0600 <scanner> 0600 root

Luego, cuando se registre en la consola, tendrá derechos de propiedad sobre el dispositivo /dev/scanner y los permisos serán 0600 (permiso exclusivo de lectura y escritura). Cuando cierre la sesión, el dispositivo será propiedad de root y seguirá teniendo permisos 0600 (ahora: permiso exclusivo de lectura y escritura para el usuario root).

Advertencia

Nunca debe modificar el archivo por defecto 50-default.perms. Para modificar permisos para un dispositivo que ya ha sido definido en 50-default.perms añada la definición del permiso deseado para ese dispositivo en 51-default.perms. Esto sustituirá los permisos definidos en 50-default.perms.

27.5. Activación del acceso a la consola para otras aplicaciones

Si desea que los usuarios de la consola puedan acceder a otras aplicaciones tendrá que trabajar un poco más.

En primer lugar, el acceso a la consola sólo funciona para las aplicaciones que residen en /sbin/ o /usr/sbin/, de modo que la aplicación que desee ejecutar deberá estar ubicada en este lugar. Después de verificar esto, siga los siguientes pasos:

  1. Cree un vínculo del nombre de la aplicación, como el programa ejemplo foo, en la aplicación /usr/bin/consolehelper:

    cd /usr/bin ln -s consolehelper foo
    
  2. Cree el archivo /etc/security/console.apps/foo:

    touch /etc/security/console.apps/foo
    
  3. Cree un archivo de configuración de PAM para el servicio foo en /etc/pam.d/. Un modo sencillo de realizar esto es empezar con una copia del archivo de configuración del servicio halt y luego modificar el archivo si desea cambiar su comportamiento:

    cp /etc/pam.d/halt /etc/pam.d/foo
    

Ahora, cuando ejecute /usr/bin/foo, se llamará al comando consolehelper, el cual validará al usuario con la ayuda de /usr/sbin/userhelper. Para validar al usuario, consolehelper solicitará una contraseña del usuario si /etc/pam.d/foo es una copia de /etc/pam.d/halt (en caso contrario, hará precisamente lo que se haya especificado en /etc/pam.d/foo) y a continuación ejecutará /usr/sbin/foo con permisos de root.

En el archivo de configuración PAM, una aplicación puede ser configurada para usar el módulo pam_timestamp para recordar (caché) un intento de conexión exitoso. Cuando una aplicación inicia y se proporciona una autentificación adecuada (la contraseña de root), se crea un archivo timestamp. Por defecto, una validación con éxito está cacheada durante cinco minutos. Durante este tiempo, cualquier otra aplicación que sea configurada para usar pam_timestamp y ejecutar desde la misma sesión, está automáticamente autenticada para el usuario — el usuario no tiene que introducir la contraseña de root de nuevo.

Este módulo está incluido en el paquete pam. Para activar esta característica, el archivo de configuración PAM en etc/pam.d/ debe incluir las líneas siguientes:

auth include config-util account include config-util session include config-util

Estas líneas pueden ser copiadas desde cualquier archivo de configuración /etc/pam.d/system-config-*. Observe que estas líneas se tienen que añadir por debajo de cualquier otra línea auth sufficientsession optional en su archivo de configuración PAM.

Si una aplicación configurada para usar pam_timestamp es autenticada exitósamente desde el Applications (the main menu on the panel), el ícono es desplegado en el área de notificación del panel si está ejecutando el entorno de escritorio GNOME o KDE. Después de que la autentificación caduca (por defecto cinco minutos), el ícono desaparece.

El usuario puede seleccionar olvidar la autentificación cacheada al pulsar el icono y seleccionar la opción de olvidar la autentificación.

27.6. El Grupo floppy

Si, por cualquier motivo, el acceso a la consola no es adecuado para usted y necesita otorgar acceso a los usuarios no root a la unidad de disquete del sistema, puede hacerlo con el grupo floppy. Agregue el(los) usuario(s) al grupo floppy usando la herramienta de su preferencia. Por ejemplo, el comando gpasswd se puede utilizar para añadir el usuario fred al grupo floppy:

gpasswd -a fred floppy

Ahora, el usuario fred podrá acceder a la unidad de disquete del sistema desde la consola.

Capítulo 28. El directorio sysconfig

El directorio /etc/sysconfig/ contiene una gran variedad de archivos de configuración para Red Hat Enterprise Linux.

Este capítulo resalta algunos de los archivos encontrados en el directorio /etc/sysconfig/, su función, y sus contenidos. La información en este capítulo no pretende ser exhaustiva, pues muchos de estos archivos tienen una variedad de opciones que sólo son usadas en circunstancias muy específicas.

28.1. Archivos en el directorio /etc/sysconfig/

Las secciones siguientes ofrecen descripciones de los archivos que normalmente se encuentran en el directorio /etc/sysconfig/. Los archivos que no se listan aquí, así como las opciones adicionales para los archivos, se pueden encontrar en el archivo /usr/share/doc/initscripts-<número-versión>/sysconfig.txt (reemplace <número-versión> con la versión del paquete initscripts). Alternativamente, puede ser útil revisar los initscripts en el directorio /etc/rc.d/.

Nota

Si alguno de los archivos aquí listados no está presente en el directorio /etc/sysconfig/, entonces el programa correspondiente podría no estar instalado.

28.1.1. /etc/sysconfig/amd

El archivo /etc/sysconfig/amd contiene varios parámetros usados por amd, que permiten el montaje y desmontaje automático de sistemas de archivos.

28.1.2. /etc/sysconfig/apmd

El archivo /etc/sysconfig/apmd es usado por apmd para configurar que valores de energía iniciar/detener/cambiar en el estado suspendido o reanudar. Este archivo configura como funciona apmd al momento del arranque, dependiendo de si el hardware soporta la Administración avanzada de energía (Advanced Power Management, APM), o si el usuario ha configurado o no el sistema para usarla. El demonio apm es un programa de supervisión que funciona con el código de administración de energía dentro del kernel de Linux. Es capaz de alertar a los usuarios sobre la condición de energía baja en la batería en las computadoras portátiles y otras configuraciones relacionadas con la energía del sistema.

28.1.3. /etc/sysconfig/arpwatch

El archivo /etc/sysconfig/arpwatch es usado para pasar argumentos al demonio arpwatch durante el arranque. El demonio arpwatch mantiene una tabla de direcciones MAC Ethernet y sus direcciones pares IP. Por defecto, este archivo coloca como propietario del proceso arpwatch al usuario pcap, así como también envía todos los mensajes a la cola de mensajes de root. Para obtener mayor información sobre los parámetros disponibles para este archivo, vea la página man de arpwatch.

28.1.4. /etc/sysconfig/authconfig

El archivo /etc/sysconfig/authconfig configura el tipo de autorización a ser usada en el host. Contiene una o más de las líneas siguientes:

  • USEMD5=<valor>, donde <valor> es uno de los siguientes:

    • yes — Se utiliza MD5 para la autentificación.

    • no — No se utiliza MD5 para la autentificación.

  • USEKERBEROS=<valor>, donde <valor> es uno de los siguientes:

    • yes — Se utiliza Kerberos para la autentificación.

    • no — No se utiliza Kerberos para la autentificación.

  • USELDAPAUTH=<valor>, donde <valor> es uno de los siguientes:

    • yes — Se utiliza LDAP para la autentificación.

    • no — No se usa LDAP para la autentificación.

28.1.5. /etc/sysconfig/autofs

El archivo /etc/sysconfig/autofs define opciones de personalización para el montaje automático de dispositivos. Este archivo controla la operación de los demonios de automontaje, los cuales montan automáticamente los sistemas de archivos cuando los utiliza y los desmonta luego de un período de inactividad. Los sistemas de archivos pueden incluir sistemas de archivos de redes, CD-ROMS, disquetes y otros tipos de media.

El archivo /etc/sysconfig/autofs puede contener lo siguiente:

  • LOCALOPTIONS="<valor>", donde <valor> es una cadena de caracteres que especifica reglas de montaje. El valor por defecto es una cadena de caracteres vacía ("").

  • DAEMONOPTIONS="<valor>", donde <valor> es la duración del tiempo de espera en segundos antes de desmontar el dispositivo. El valor por defecto es 60 segundos ("--timeout=60").

  • UNDERSCORETODOT=<valor>, donde <valor> es un valor binario que controla si se deben convertir los guiones bajos en los nombres de archivos en puntos. Por ejemplo, auto_home a auto.home y auto_mnt a auto.mnt. El valor por defecto es 1 (verdadero).

  • DISABLE_DIRECT=<valor>, donde <valor> es un valor binario que controla si se desactiva o no el soporte para el montaje directo, ya que la implementación de Linux no sigue el comportamiento de automontaje de Sun Microsystems. El valor por defecto es 1 (verdadero), que permite la compatibilidad con la sintaxis de especificación de opciones de automontaje de Sun.

28.1.6. /etc/sysconfig/clock

El archivo /etc/sysconfig/clock controla la interpretación de los valores leídos desde el reloj del sistema.

Los valores correctos son:

  • UTC=<valor>, donde <valor> es uno de los siguientes valores boleanos:

    • true o yes — El reloj del hardware está configurado a Universal Time.

    • false o no — El reloj del hardware está configurado a la hora local.

  • ARC=<valor>, donde <valor> es uno de los siguientes:

    • false o no — Este valor indica que la época UNIX normal está en uso. Otros valores son usados por sistemas no soportados por Red Hat Enterprise Linux.

  • SRM=<valor>, donde <valor> es uno de los siguientes:

    • false o no — Este valor indica que la época UNIX normal está en uso. Otros valores son usados por sistemas no soportados por Red Hat Enterprise Linux.

  • ZONE=<nombre-archivo> — El archivo de zona horaria bajo /usr/share/zoneinfo del cual /etc/localtime es una copia. El archivo contiene información tal como:

    ZONE="America/New York"
    

    Note que el parámetro ZONE es leído por Herramienta de propiedades de fecha y hora (system-config-date), y la edición manual de éste no cambia el huso horario del sistema.

Ediciones previas de Red Hat Enterprise Linux usaban los valores siguientes (las cuales ya no son aprobadas):

  • CLOCKMODE=<valor>, donde <valor> es uno de los siguientes:

    • GMT — El reloj está colocado al Universal Time (Greenwich Mean Time).

    • ARC — El desplazamiento (time offset) de 42 años de la consola ARC está en efecto (sólo para sistemas basados en Alpha).

28.1.7. /etc/sysconfig/desktop

El archivo /etc/sysconfig/desktop especifica el escritorio para los nuevos usuarios y el gestor de pantallas a ser ejecutado, cuando se entra al nivel de ejecución 5.

Los valores correctos son:

  • DESKTOP="<valor>", donde "<valor>" es uno de los siguientes:

    • GNOME — Selecciona el entorno de escritorio de GNOME.

    • KDE — Selecciona el entorno de escritorio KDE.

  • DISPLAYMANAGER="<valor>", donde "<valor>" es uno de los siguientes:

    • GNOME — Selecciona el gestor de pantallas de GNOME.

    • KDE — Selecciona el gestor de pantallas de KDE.

    • XDM — Selecciona el gestor de pantallas de X.

Para obtener mayor información, consulte el Capítulo 31, El Sistema X Window.

28.1.8. /etc/sysconfig/dhcpd

El archivo /etc/sysconfig/dhcpd es usado para pasar argumentos al demonio dhcpd en el momento de arranque. El demonio dhcpd implementa el Protocolo dinámico de configuración de host (DHCP) y el Internet Bootstrap Protocol (BOOTP). DHCP y BOOTP asignan nombres de host a las máquinas en la red. Para más información sobre qué parámetros están disponibles en este archivo, consulte la página del manual de dhcpd.

28.1.9. /etc/sysconfig/exim

El archivo /etc/sysconfig/exim permite enviar mensajes a uno o más clientes, enrutando el mensaje sobre todas las redes que sean necesarias. El archivo configura los valores predeterminados para que la aplicación exim se ejecute. Sus valores por defecto son configurados para ejecutarse como un demonio en el fondo y verificar su cola una vez cada hora en caso de que algo se haya acumulado.

Los valores incluidos son:

  • DAEMON=<valor>, donde <valor> es uno de los siguientes:

    • yesexim debería ser configurado para escuchar en el puerto 25 para el correo entrante. yes implica el uso de las opciones -bd de Exim.

    • noexim no debería ser configurado para escuchar en el puerto 25 para el correo entrante.

  • QUEUE=1h que se entrega a exim como -q$QUEUE. La opción -q no es dada a exim si /etc/sysconfig/exim existe y QUEUE es vacío o no está definida.

28.1.10. /etc/sysconfig/firstboot

La primera vez que el sistema arranca, el programa /sbin/init llama al script etc/rc.d/init.d/firstboot que luego lanza Agente de configuración. Esta aplicación permite al usuario instalar las últimas actualizaciones y cualquier aplicación o documentación adicional.

El archivo /etc/sysconfig/firstboot le dice a la aplicación Agente de configuración que no se ejecute en los subsecuentes reinicios. Para ejecutarlo la próxima vez que el sistema arranca, elimine /etc/sysconfig/firstboot y ejecute chkconfig --level 5 firstboot on.

28.1.11. /etc/sysconfig/gpm

El archivo /etc/sysconfig/gpm es usado para pasar argumentos al demonio gpm en el momento de arranque. El demonio gpm es el servidor del ratón que permite la aceleración del ratón y el pegado con el botón del medio. Para más información sobre qué parámetros están disponibles para este archivo, consulte la página del manual de gpm. Por defecto, la directriz DEVICE se configura a /dev/input/mice.

28.1.12. /etc/sysconfig/hwconf

El archivo /etc/sysconfig/hwconf lista todo el hardware que kudzu detectó en su sistema, así como también los controladores usados, ID de los fabricantes e información de ID de los dispositivos. El programa kudzu detecta y configura el hardware nuevo o modificado en su sistema. El archivo /etc/sysconfig/hwconf se supone que no es para ser modificado manualmente. Si se edita, los dispositivos se pueden repentinamente mostrar como que han sido agregados o eliminados.

28.1.13. /etc/sysconfig/i18n

El archivo /etc/sysconfig/i18n configura el idioma predeterminado, cualquier idioma soportado y la fuente predeterminada del sistema. Por ejemplo:

LANG="en_US.UTF-8" 
SUPPORTED="en_US.UTF-8:en_US:en" 
SYSFONT="latarcyrheb-sun16"

28.1.14. /etc/sysconfig/init

El archivo /etc/sysconfig/init controla cómo el sistema aparecerá y funcionará durante el momento de arranque.

Se usan los siguientes valores:

  • BOOTUP=<valor>, donde <valor> es uno de los siguientes:

    • color — El color estándar de la visualización, cuando la falla o éxito de un dispositivo se muestra en colores diferentes al momento de arranque, donde el éxito o falla de dispositivos y servicios al iniciarse es mostrado en diferentes colores.

    • verbose — Es un tipo de despliegue viejo, que proporciona más información que el simple mensaje de éxito o falla.

    • Cualquier otra cosa significa un nuevo despliegue, pero sin el formato ANSI.

  • RES_COL=<valor>, donde <valor> es el número de la columna de la pantalla para comenzar las etiquetas de estado. Está predeterminado a 60.

  • MOVE_TO_COL=<valor>, donde <valor> mueve el cursor al valor en la línea RES_COL a través del comando echo -en.

  • SETCOLOR_SUCCESS=<valor>, donde <valor> configura el color a un color que indica el éxito a través del comando echo -en. El color predeterminado es verde.

  • SETCOLOR_FAILURE=<valor>, donde <valor> coloca el color para indicar falla a través del comando echo -en. Por defecto el color es rojo.

  • SETCOLOR_WARNING=<valor>, donde <valor> coloca el color para indicar advertencia a través del comando echo -en. Por defecto el color es amarillo.

  • SETCOLOR_NORMAL=<valor>, donde <valor> reconfigura el color a "normal" a través de echo -en.

  • LOGLEVEL=<valor>, donde <valor> configura el nivel de conexión de la consola inicial para el kernel. El valor por defecto es 3; 8 significa cualquier cosa (incluyendo depuración); 1 significa pánico del kernel. El demonio syslogd ignora esta configuración una vez que se ha arrancado.

  • PROMPT=<valor>, donde <valor> es uno de los siguientes valores boleanos:

    • yes — Activa la verificación de claves para el modo interactivo.

    • no — Desactiva la verificación de claves para el modo interactivo.

28.1.15. /etc/sysconfig/ip6tables-config

El archivo /etc/sysconfig/ip6tables-config guarda información usada por el kernel para configurar los servicios de filtrado de paquetes IPv6 en el momento de arranque o cuando se arranque el servicio ip6tables.

No modifique este archivo manualmente a menos que esté familiarizado con la construcción de reglas ip6tables. Se pueden crear reglas manualmente también usando el comando /sbin/ip6tables. Una vez creado, añada las reglas al archivo /etc/sysconfig/ip6tables escribiendo el comando siguiente:

/sbin/service ip6tables save

Una vez que este archivo existe, cualquier regla de firewall guardadas en él, persisten a través de los reinicios del sistema o de un servicio.

28.1.16. /etc/sysconfig/iptables-config

El archivo /etc/sysconfig/iptables-config guarda información usada por el kernel para configurar los servicios de filtrado de paquetes en el momento de arranque o cuando se arranque un servicio.

Do not modify this file by hand unless you are familiar with constructing iptables rules. The easiest way to add rules is to use the Herramienta de configuración del nivel de seguridad (system-config-securitylevel) application to create a firewall. These applications automatically edit this file at the end of the process.

Las reglas también se pueden crear manualmente usando /sbin/iptables. Una vez creadas, añada la(s) regla(s) al archivo /etc/sysconfig/iptables escribiendo el comando siguiente:

/sbin/service iptables save

Una vez que este archivo existe, cualquier regla de firewall guardadas en él, persisten a través de los reinicios del sistema o de un servicio.

28.1.17. /etc/sysconfig/irda

El archivo /etc/sysconfig/irda controla cómo los dispositivos infrarojos en el sistema son configurados en el arranque.

Se usan los siguientes valores:

  • IRDA=<valor>, donde <valor> es uno de los siguientes valores boleanos:

    • yesirattach se ejecutará, lo que verifica periódicamente si hay algo tratando de conectarse al puerto infrarojo, tal como otra laptop tratando de hacer una conexión de red. Para que los dispositivos infrarojos funcionen en su sistema, se debe colocar esta línea a yes.

    • noirattach no se ejecuta, impidiendo la comunicación de dispositivos infrarojos.

  • DEVICE=<valor>, donde <valor> es el dispositivo (usualmente un puerto serial) que maneja las conexiones infrarojas. Un ejemplo de entrada de dispositivo serial podría ser /dev/ttyS2.

  • DONGLE=<valor>, donde <valor> especifica el tipo de "dongle" que está siendo usado para la comunicación infraroja. Este valor existe para los casos en que se usan dongles seriales en vez de puertos infrarojos reales. Un dongle es un dispositivo que es conectado a un puerto serial tradicional para comunicar a través de infrarojo. Esta línea se coloca en comentarios por defecto porque las computadoras portátiles con puertos infrarojos reales son mucho más populares que las que tienen dongles agregados. Una entrada de ejemplo para dongle podría ser actisys+.

  • DISCOVERY=<valor>, donde <valor> es uno de los siguientes valores boleanos:

    • yes — Arranca irattach en modo 'discovery', o de descubrimiento, lo que significa que está activamente buscando otros dispositivos infrarojos. Este valor necesita ser activado para que la máquina esté buscando activamente por una conexión infraroja (el par que no inicia la conexión).

    • no — No arranca irattach en modo discovery.

28.1.18. /etc/sysconfig/keyboard

El archivo /etc/sysconfig/keyboard controla el comportamiento del teclado. Se pueden usar los siguientes valores:

  • KEYBOARDTYPE="sun|pc", donde sun significa que un teclado Sun está conectado en /dev/kbd, o pc significa que hay un teclado PS/2 conectado al puerto PS/2.

  • KEYTABLE="<archivo>", donde <archivo> es el nombre de un archivo de tabla de teclas.

    Por ejemplo: KEYTABLE="us". Los archivos que pueden ser usados como tabla de teclas comienzan en /lib/kbd/keymaps/i386 y se extienden en diferentes disposiciones de teclados desde aquí, a todos los etiquetados <archivo>.kmap.gz. El primer archivo encontrado debajo /lib/kbd/keymaps/i386 que coincide con la configuración KEYTABLE es usado.

28.1.19. /etc/sysconfig/kudzu

El archivo /etc/sysconfig/kuzdu dispara una exploración segura del hardware del sistema mediante kudzu en el momento de arranque. time. Una exploración segura es una que desactiva el sondeo del puerto serial.

  • SAFE=<valor>, donde <valor> es uno de los siguientes:

    • yeskuzdu hace una exploración segura.

    • nokuzdu realiza una exploración normal.

28.1.20. /etc/sysconfig/named

El archivo /etc/sysconfig/named es usado para pasar argumentos al demonio named en el momento de arranque. El demonio named es un servidor Domain Name System (DNS) que implementa la distribución Berkeley Internet Name Domain (BIND) versión 9. Este servidor mantiene una tabla de cuales hosts están asociados con direcciones IP en la red.

Actualmente, sólo los valores siguientes son usados:

  • ROOTDIR="</algun/lugar>", donde </algun/lugar> se refiere a la ruta completa del directorio de un ambiente chroot bajo el cual named se ejecuta. Este ambiente chroot debe ser configurado primero. Escriba info chroot para ver más información.

  • OPTIONS="<valor>", donde <valor> es cualquier opción listada en la página del manual para named excepto -t. En lugar de -t, use la línea ROOTDIR.

Para obtener mayor información sobre los parámetros disponibles para este archivo, consulte la página man de named. Para obtener información detallada sobre cómo configurar un servidor BIND DNS, vea el Capítulo 17, Berkeley Internet Name Domain (BIND). Por defecto, el archivo no contiene parámetros.

28.1.21. /etc/sysconfig/network

El archivo /etc/sysconfig/network es usado para especificar información sobre la configuración de red deseada. Se pueden usar los valores siguientes:

  • NETWORKING=<valor>, donde <valor> es uno de los siguientes valores boleanos:

    • yes — Se debería configurar el servicio de red.

    • no — No se debería configurar el servicio de red.

  • HOSTNAME=<valor>, donde <valor> debería ser el Fully Qualified Domain Name (FQDN), nombre de dominio cualificado completo, tal como hostname.expample.com, pero puede ser cualquier nombre de host necesario.

  • GATEWAY=<valor>, donde <valor> es la dirección IP de la gateway (compuerta) de la red.

  • GATEWAYDEV=<value>, where <value> is the gateway device, such as eth0. Configure this option if you have multiple interfaces on the same subnet, and require one of those interfaces to be the preferred route to the default gateway.

  • NISDOMAIN=<valor>, donde <valor> es el nombre del dominio NIS.

  • NOZEROCONF=<valor>, si <valor> es true la ruta zeroconf es desactivada.

    Por defecto, la ruta zerocong (162.254.0.0) está activada cuando el sistema es iniciado. Para obtener mayor información sobre zeroconf consulte http://www.zeroconf.org/.

Warning

Do not use custom initscripts to configure network settings. When performing a post-boot network service restart, custom initscripts configuring network settings that are run outside of the network init script lead to unpredictable results.

28.1.22. /etc/sysconfig/nfs

NFS requires the portmap, which dynamically assigns ports for RPC services. This causes problems for configuring firewall rules. To overcome this problem, use the /etc/sysconfig/nfs file to control which ports the required RPC services run on.

The /etc/sysconfig/nfs may not exist by default on all systems. If it does not exist, create it and add the following variables (alternatively, if the file exists, un-comment and change the default entries as required):

MOUNTD_PORT="x"

control which TCP and UDP port mountd (rpc.mountd) uses. Replace x with an unused port number.

STATD_PORT="x"

control which TCP and UDP port status (rpc.statd) uses. Replace x with an unused port number.

LOCKD_TCPPORT="x"

control which TCP port nlockmgr (rpc.lockd) uses. Replace x with an unused port number.

LOCKD_UDPPORT="x"

control which UDP port nlockmgr (rpc.lockd) uses. Replace x with an unused port number.

If NFS fails to start, check /var/log/messages. Normally, NFS will fail to start if you specify a port number that is already in use. After editing /etc/sysconfig/nfs restart the NFS service by running the service nfs restart command. Run the rpcinfo -p command to confirm the changes.

To configure a firewall to allow NFS:

  1. Allow TCP and UDP port 2049 for NFS.

  2. Allow TCP and UDP port 111 (portmap/sunrpc).

  3. Allow the TCP and UDP port specified with MOUNTD_PORT="x"

  4. Allow the TCP and UDP port specified with STATD_PORT="x"

  5. Allow the TCP port specified with LOCKD_TCPPORT="x"

  6. Allow the UDP port specified with LOCKD_UDPPORT="x"

28.1.23. /etc/sysconfig/ntpd

El archivo /etc/sysconfig/ntpd es usado para pasar argumentos al demonio ntpd en el momento de arranque. El demonio ntpd configura y mantiene el reloj del sistema para sincronizar con un servidor de hora estándar de Internet. Implementa la versión 4 del protocolo de hora de red (Network Time Protocol, NTP). Para más información sobre los parámetros disponibles para este archivo, apunte su navegador al siguiente archivo: /usr/share/doc/ntp-<version>/ntpd.htm (donde <version> es el número de versión de ntpd). Por defecto, este archivo configura el propietario del proceso ntpd al usuario de ntp.

28.1.24. /etc/sysconfig/radvd

El archivo /etc/sysconfig/radvd es usado para pasar argumentos al demonio radvd en el momento de arranque. El demonio radvd escucha por peticiones del enrutador y envía notificaciones del enrutador para el protocolo IP versión 6. Este servicio permite a los host en una red cambiar dinámicamente sus enrutadores predeterminados basados en estas notificaciones del enrutador. Para más información sobre qué parámetros están disponibles para este archivo, vea la página del manual de radvd. Por defecto, este archivo coloca como propietario del proceso radvd al usuario radvd.

28.1.25. /etc/sysconfig/samba

El archivo /etc/sysconfig/samba es usado para pasar argumentos a los demonios smbd y nmbd en el momento de arranque. El demonio smbd ofrece conectividad de archivos compartidos para los clientes Windows en la red. El demonio nmbd ofrece servicios de nombres NetBIOS sobre IP. Para más información sobre los parámetros disponibles para este archivo, consulte la página de manual de smbd. Por defecto este archivo configura smbd y nmbd para que se ejecuten en modo demonio.

28.1.26. /etc/sysconfig/selinux

El archivo /etc/sysconfig/selinux contiene las opciones de configuración básicas para SELinux. Este archivo es un enlace simbólico a /etc/selinux/config.

28.1.27. /etc/sysconfig/sendmail

El archivo /etc/sysconfig/sendmail permite enviar mensajes a uno o más clientes, enrutando el mensaje sobre todas las redes que sean necesarias. El archivo configura los valores predeterminados para que la aplicación Sendmail se ejecute. Los valores predeterminados son ejecutarse como un demonio en el fondo y verificar la cola una vez cada hora en caso de que algo se haya acumulado.

Los valores incluyen:

  • DAEMON=<valor>, donde <valor> es uno de los siguientes:

    • yesSendmail debería ser configurado para escuchar en el puerto 25 para el correo entrante. yes implica el uso de las opciones -bd de Sendmail .

    • noSendmail no debería ser configurado para escuchar en el puerto 25 para el correo entrante.

  • QUEUE=1h que es entregado a Sendmail como -q$QUEUE. La opción -q no es dada a Sendmail si /etc/sysconfig/sendmail existe y QUEUE es vacío o no está definida.

28.1.28. /etc/sysconfig/spamassassin

El archivo /etc/sysconfig/spamassassin se utiliza para pasar argumentos al demonio spamd (una versión endemoniada de Spamassassin) al momento del arranque. Spamassassin es una aplicación de filtro de correo basura. Para obtener una lista de las opciones disponibles, consulte la página man de spamd. Por defecto, se configura spamd para ejecutarse en modo demonio, crear las preferencias del usuario y autocrear whitelists (permitir remitentes con envíos por montones).

Para obtener mayor información sobre Spamassassin, consulte la Sección 24.5.2.6, “Filtros de correo basura”.

28.1.29. /etc/sysconfig/squid

El archivo /etc/sysconfig/squid es usado para pasar argumentos al demonio squid al momento de arranque. El demonio squid es un servidor proxy caching para las aplicaciones cliente Web. Para más información sobre cómo configurar un servidor proxy squid, use un navegador Web para abrir el directorio /usr/share/doc/squid-<version>/ (reemplace <version> con el número de la versión de squid instalado en su sistema). Por defecto, este archivo configura squid para arrancar en modo demonio y establecer la cantidad de tiempo antes de que se cierre asímismo.

28.1.30. /etc/sysconfig/system-config-securitylevel

28.1.31. /etc/sysconfig/system-config-selinux

28.1.32. /etc/sysconfig/system-config-users

El archivo /etc/sysconfig/system-config-users es el archivo de configuración para la Administrador de usuarios. Este archivo es usado para filtrar usuarios del sistema tal como root, daemon o lp. Este archivo se edita mediante el menú desplegable Preferencias => Filtrar usuarios y grupos del sistema en la Administrador de usuarios y nunca se debería modificar manualmente. Para obtener mayor información sobre el uso de esta aplicación, consulte la Sección 33.1, “Configuración de grupos y de usuarios”

28.1.33. /etc/sysconfig/system-logviewer

El archivo /etc/sysconfig/system-logviewer es el archivo de configuración para la aplicación gráfica interactiva de visualización del registro, Visor de registros. Este archivo se puede modificar mediante el menú desplegable Editar => Preferencias en la Visor de registros y no debería ser modificado manualmente. Para obtener mayor información sobre el uso de esta aplicación, consulte el Capítulo 36, Archivos de registro.

28.1.34. /etc/sysconfig/tux

El archivo /etc/sysconfig/tux es el archivo de configuración para el Acelerador de contenidos de Red Hat, en inglés Red Hat Content Accelerator (anteriormente conocido como TUX), el servidor Web basado en el kernel. Para obtener mayor información sobre la configuración de Red Hat Content Accelerator, use un navegador de Web para abrir /usr/share/doc/tux-<versión>/tux/index.html (reemplace <versión> con el número de versión de TUX instalado en su sistema). Los parámetros disponibles para este archivo están listados en /usr/share/doc/tux-<versión>/tux/parameters.html.

28.1.35. /etc/sysconfig/vncservers

El archivo /etc/sysconfig/vncservers configura la forma en que el servidor Virtual Network Computing (VNC) arranca.

VNC es un sistema de despliegue remoto el cual permite a los usuarios ver el ambiente de escritorio no sólo en la máquina en que se está ejecutando sino también a través de las diferentes redes en una variedad de arquitecturas.

Puede contener lo siguiente:

  • VNCSERVERS=<valor>, donde <valor> está configurado a algo parecido a "1:fred", para indicar que el servidor VNC debería ser arrancado por el usuario fred en el despliegue :1. El usuario fred debe haber establecido una contraseña VNC usando el comando vncpasswd antes de intentar conectarse al servidor VNC remoto.

28.2. Directorios en el directorio /etc/sysconfig/

Los siguientes directorios se encuentran normalmente en /etc/sysconfig/.

apm-scripts/

Este directorio contiene el script para suspender/reanudar APM de Red Hat. No modifique estos archivos directamente. Si se necesita personalizar APM, cree un archivo llamado /etc/sysconfig/apm-scripts/apmcontinue. Este será ejecutado al final del script. También es posible controlar el script editando /etc/sysconfig/apmd.

cbq/

Este directorio contiene los archivos de configuración necesarios para hacer Class Based Queuing para la administración del ancho de banda en las interfaces de red. CBQ divide el tráfico en una jerarquía de clases basada en cualquier combinación de direcciones IP, protocolos y tipos de aplicación.

networking/

Este directorio es usado por la Herramienta de administración de red (system-config-network) y sus contenidos no se deberían modificar manualmente. Para obtener mayor información sobre la configuración de interfaces de red usando la Herramienta de administración de red, consulte el Capítulo 15, Configuración de la red.

network-scripts/

Este directorio contiene los siguientes archivos de configuración relacionados con la red:

  • Archivos de configuración de red para cada interfaz de red configurada, tal como ifcfg-eth0 para la interfaz de red Ethernet eth0.

  • Scripts usado para activar y desactivar interfaces de red, tales como ifup e ifdown.

  • Scripts usados para activar y desactivar las interfaces ISDN, tales como ifup-isdn e ifdown-isdn.

  • Varios scripts de funciones de red compartidas los cuales no deberían ser modificados manualmente.

Para obtener mayor información sobre el directorio network-scripts, consulte el Capítulo 14, Interfaces de red.

rhn/

Este directorio contiene los archivos de configuración y claves GPG para Red Hat Network. Ningún archivo en este directorio debería ser modificado manualmente. Para obtener mayor información sobre Red Hat Network, consulte el sitio web de Red Hat Network en https://rhn.redhat.com/.

28.3. Recursos adicionales

Este capítulo sólo tiene la intención de servir de introducción para los archivos en el directorio /etc/sysconfig/. Las siguientes fuentes contienen información más detallada.

28.3.1. Documentación instalada

  • /usr/share/doc/initscripts-<numero-version>/sysconfig.txt — Este archivo contiene un listado autorizado de los archivos encontrados en el directorio /etc/sysconfig/ y de las opciones de configuración disponibles para ellos. El <numero-version> en la ruta a este archivo corresponde a la versión del paquete initscripts instalado.

Capítulo 29. Configuración de la fecha y hora

La Herramienta de propiedades de fecha y hora le permite al usuario cambiar la fecha y la hora del sistema para configurar la zona horaria utilizada en el sistema. Además le permite definir el demonio NTP (Network Time Protocol) para sincronizar el reloj del sistema con un servidor horario.

Para utilizar esta herramienta, usted debe tener privilegios de root y debe estar utilizando el sistema de ventanas X. Hay tres maneras para iniciar la aplicación.

  • Desde el escritorio, vaya a Applications (the main menu on the panel) => Configuración del sistema => Fecha & Hora

  • Desde el escritorio, haga clic con el botón derecho del ratón sobre la fecha y seleccione Ajustar fecha y hora.

  • Escriba el comando system-config-date, system-config-time, o dateconfig en el interprete de comandos (por ejemplo, en una terminal XTerm o una terminal GNOME).

29.1. Propiedades de hora y fecha

Como se muestra en la Figura 29.1, “Propiedades de hora y fecha”, la primera ventana que aparece es para configurar la fecha y la hora del sistema.

Propiedades de hora y fecha

Propiedades de hora y fecha

Figura 29.1. Propiedades de hora y fecha

Para cambiar la fecha, utilice las flechas a izquierda y derecha del mes que desea cambiar, utilice las flechas a izquierda y derecha del año y pulse en el día de la semana a establecer.

Para cambiar la hora, use las flechas arriba y abajo situadas junto a Hora, Minuto y Segundos en la sección Hora.

Haciendo clic sobre OK aplicará cualquier cambio que haya realizado a la fecha y a la hora, a las configuraciones del demonio NTP y a las configuraciones de zona horaria. Tras esta acción se saldrá del programa.

29.2. Propiedades del protocolo de tiempo de red (NTP)

Como se muestra en la Figura 29.1, “Propiedades de hora y fecha”, la segunda ventana que aparece es para configurar NTP.

Propiedades de NTP

Propiedades de NTP

Figura 29.2. Propiedades de NTP

El demonio Network Time Protocol (NTP) sincroniza el reloj del sistema con un servidor horario remoto o con una fuente horaria. La aplicación le permite configurar el demonio NTP para sincronizar el reloj del sistema con un servidor remoto. Para activar esta función, haga clic en el botón Activar el Protocolo de tiempo de red. Esto activará la lista deServidores NTP y otras opciones. Puede seleccionar uno de los servidores predefinidos, editar un servidor predefinido haciendo clic en Editar o añadir un nuevo servidor haciendo clic en Añadir. El sistema no iniciará la sincronización con el servidor NTP hasta que haga clic en OK. Después de hacer clic en OK, se guardará la configuración y se iniciará (o reiniciará si ya se está ejecutando) el demonio NTP.

Haciendo clic sobre OK aplicará cualquier cambio que haya realizado a la fecha y a la hora, a las configuraciones del demonio NTP y a las configuraciones de zona horaria. Tras esta acción se saldrá del programa.

29.3. Configuración de la zona horaria

Como se muestra en la Figura 29.1, “Propiedades de hora y fecha”, la tercera ventana que aparece es para configurar la zona horaria del sistema.

Para configurar la zona horaria del sistema, haga clic en la pestaña Zona horaria. La zona horaria se puede cambiar utilizando el mapa interactivo o seleccionando la zona horaria deseada en la lista situada debajo del mapa. Para usar el mapa, haga clic en la ciudad que representa la zona horaria deseada. Aparecerá una X de color rojo y la selección de la zona horaria cambiará en la lista situada debajo del mapa.

Además, puede utilizar la lista ubicada bajo el mapa. De la misma manera, la región es escogida antes de la ciudad. La lista de zonas horarias está ahora construida como una lista de árbol, en donde las ciudades y países están agrupados por continentes específicos. Zonas horarias no geográficas también han sido añadidas para resolver necesidades en la comunidad científica.

Haga clic sobre OK para aplicar cualquier cambio que haya realizado y para salir del programa.

Propiedades de la zona horaria

Propiedades de la zona horaria

Figura 29.3. Propiedades de la zona horaria

Si su sistema está configurado para usar UTC, seleccione la opción El reloj del sistema utiliza UTC. UTC proviene de Universal Time zone, también conocido como Greenwich mean time (GMT). Las otras zonas horarias son determinadas sumando o restando de la hora UTC.

Capítulo 30. Configuración del Teclado

El programa de instalación le permite configurar una distribución del teclado para su sistema. Para configurar una distribución del teclado diferente después de la instalación utilice la Herramienta de configuración del teclado.

Para iniciar la Herramienta de configuración del teclado, seleccione System (on the panel) => Administración => Teclado o escriba el comando system-config-keyboard en el intérprete de comandos de shell.

Herramienta de Configuración del Teclado

Herramienta de Configuración del Teclado

Figura 30.1. Herramienta de Configuración del Teclado

Seleccione una distribución de teclado de la lista (por ejemplo, U.S. English) y pulse OK.

Los cambios se efectúan inmediatamente.

Capítulo 31. El Sistema X Window

Mientras que el corazón de Red Hat Enterprise Linux es el kernel, para muchos usuarios, la cara del sistema operativo es el entorno gráfico proporcionando por el Sistema de ventanas X, también llamado simplemente X.

Han existido otros entornos de ventanas en UNIX, algunos de ellos precursores del sistema de ventanas X lanzado en Junio de 1984. Por mucho tiempo, X ha sido el entorno gráfico predeterminado de muchos sistemas operativos tipo UNIX, incluyendo Red Hat Enterprise Linux.

El entorno gráfico de Red Hat Enterprise Linux es suministrado por la Fundación X.Org, una organización de código abierto creada para manejar el desarrollo del sistema de ventanas X y otras tecnologías asociadas. X.Org es un proyecto a gran escala con un gran número de desarrolladores en todo el mundo. Presenta una amplia gama de soporte para diferentes dispositivos de hardware y arquitecturas. Puede ser ejecutado en diferentes sistemas operativos y plataformas. Este lanzamiento de Red Hat Enterprise Linux incluye específicamente el lanzamiento X11R7.1 del sistema de ventanas X.

El sistema X Window utiliza una arquitectura cliente-servidor. El servidor de X (el binario Xorg) escucha por conexiones desde las aplicaciones cliente X a través de la red o una interfaz local de loopback. El servidor gestiona la comunicación con el hardware, que puede ser una tarjeta gráfica, un monitor, un teclado o un ratón. Las aplicaciones cliente de X existen en el espacio del usuario, creando una interfaz gráfica del usuario (GUI) y pasando peticiones al servidor de X.

31.1. El lanzamiento X11R7.1

Red Hat Enterprise Linux 5.0.0 utiliza el lanzamiento X11R7.1 del sistema de ventanas X. Este lanzamiento incluye varios controladores de vídeo, EXA, soporte mejorado de plataformas en comparación con versiones anteriores y otras características. Además, este lanzamiento incluye varias funciones de configuración automática para el servidor X.

X11R7.1 is the first release to take specific advantage of the modularization of the X Window System. This modularization, which splits X into logically distinct modules, makes it easier for open source developers to contribute code to the system.

Importante

ya noRed Hat Enterprise Linux proporciona los paquetes del servidor XFree86™. Antes de actualizar un sistema con la última versión de Red Hat Enterprise Linux, verifique la lista de compatibilidad de hardware de Red Hat localizada en http://hardware.redhat.com/ para asegurar que la tarjeta de vídeo es compatible con el lanzamiento X11R7.1.

En el lanzamiento X11R7.1, todas las bibliotecas, archivos de cabecera, y archivos binarios se encuentran en /usr/ y no en /usr/X11R6. El directorio /etc/X11/ contiene archivos de configuración para los clientes X y las aplicaciones del servidor. Entre estos archivos se encuentran los archivos de configuración del servidor mismo, del servidor de fuentes xfs, de los administradores de visualización X y de otros componentes base.

El archivo de configuración para la nueva arquitectura de fuentes basado en Fontconfig es /etc/fonts/fonts.conf. Para obtener mayor información sobre la configuración y sobre los modos de añadir fuentes tipográficas, vea la Sección 31.4, “Fuentes”.

Ya que el servidor X ejecuta tareas avanzadas sobre una amplia variedad de hardware, éste requiere información detallada sobre el hardware sobre el cual trabaja. El servidor X detecta automáticamente gran parte de esta información. Sin embargo, algunos detalles deben ser configurados.

El programa de instalación instala y configura X automáticamente, a menos que los paquetes del lanzamiento X11R7.1 no sean seleccionados para la instalación. Sin embargo, si la tarjeta de vídeo o el monitor cambian, X debe ser reconfigurado. La manera más apropiada de reconfigurar el servidor es a través de Herramienta de configuración X (system-config-display), particularmente para dispositivos que no se detectan automáticamente.

En el entorno gráfico predeterminado de Red Hat Enterprise Linux, la Herramienta de configuración X está disponible en System (on the panel) => Administración => Visualización.

Los cambios hechos a Herramienta de configuración X, surten efecto después de terminar e iniciar una sesión.

Para obtener mayor información sobre Herramienta de configuración X, consulte el Capítulo 32, Configuración del Sistema X Window.

En algunas circunstancias, la reconfiguración del servidor X puede requerir la edición manual del archivo de configuración, /etc/X11/xorg.conf. Para mayor información sobre la estructura de este archivo, consulte la Sección 31.3, “Archivos de configuración del servidor X”.

31.2. Entornos de escritorio y gestores de ventanas

Una vez que un servidor X está siendo ejecutando, las aplicaciones cliente X pueden conectarse a éste y crear interfaces gráficas para el usuario. En Red Hat Enterprise Linux existe un amplio rango de GUIs, desde el rudimentario Administrador de pestañas de ventanas hasta un entorno de escritorio altamente desarrollado e interactivo como GNOME, con el que la mayoría de los usuarios de Red Hat Enterprise Linux están familiarizados.

Para crear éste último, una GUI más completa, se deben conectar dos clases principales de aplicaciones clientes X al servidor X: un entorno de escritorio y un gestor de ventanas.

31.2.1. Entornos de escritorio

Un entorno de escritorio integra diferentes clientes X para crear un entorno gráfico común de usuario y una plataforma de desarrollo.

Los entornos de escritorio tienen características avanzadas las cuales permiten a los clientes X y a otros procesos en ejecución, comunicarse unos con otros a la vez que se permite a todas las aplicaciones escritas para funcionar en ese ambiente a que realicen tareas avanzadas, tales como operaciones de arrastrar y soltar.

Red Hat Enterprise Linux proporciona dos entornos de escritorio:

  • GNOME — Es el entorno de escritorio predeterminado de Red Hat Enterprise Linux. Está basado en el conjunto de herramientas gráficas GTK+ 2.

  • KDE — Un entorno de escritorio alternativo basado en el conjunto de herramientas gráficas Qt 3.

Tanto GNOME como KDE tienen aplicaciones de productividad avanzadas, tales como procesadores de palabras, hojas de cálculo y navegadores Web. Los dos contienen herramientas para personalizar la apariencia de la GUI. Adicionalmente, si ambas bibliotecas están presentes, GTK+ 2 y Qt, las aplicaciones KDE pueden ejecutarse en GNOME y viceversa.

31.2.2. Gestores de ventanas

Los gestores de ventanas son programas clientes de X que pueden ser parte del entorno de escritorio o pueden ser programas independientes. Su propósito principal es controlar la forma en que las ventanas gráficas son posicionadas, redimensionadas o desplazadas. Los gestores de ventanas controlan las barras de títulos, el comportamiento del foco, los vínculos del botón del ratón y teclas especificadas por el usuario.

Se incluyen cuatro gestores de ventanas con Red Hat Enterprise Linux:

kwin

El gestor de ventanas KWin es el gestor predeterminado de KDE. Es un gestor de ventanas eficiente que soporta temas personalizados.

metacity

El gestor de ventanas Metacity es el gestor de ventanas predeterminado del entorno GNOME. Es un gestor de ventanas sencillo y eficiente que también soporta temas personalizados. Para ejecutar este gestor de ventanas necesitará instalar el paquete metacity.

mwm

El gestor de ventanas Motif (mwm) es un gestor básico e independiente. Puesto que está diseñado para ser un gestor que se ejecuta de forma independiente, no se debería utilizar en conjunto con los entornos de escritorios GNOME o KDE. Para ejecutar este gestor de ventanas, tendrá que instalar el paquete openmotif.

twm

El minimalista Administrador de pestañas de ventanas (twm), el cual proporciona el conjunto de herramientas básicas de cualquier gestor de ventanas, puede ser usado bien sea de forma independiente o con un entorno de escritorio. Es instalado como parte del lanzamiento X11R7.1.

Para ejecutar cualquiera de los gestores de ventanas anteriormente mencionados, tendrá que iniciar el nivel de ejecución 3. Para obtener instrucciones sobre cómo cambiar el nivel de ejecución, consulte la Sección 16.1, “Niveles de ejecución”.

Una vez haya iniciado una sesión en el nivel de ejecución 3, verá un intérprete de comandos en vez de un entorno gráfico. Para iniciar un gestor de ventanas, escriba xinit -e <ruta-al-gestor-ventanas> en el intérprete de comandos.

<ruta-al-gestor-ventanas> es la ubicación del archivo binario de gestor de ventanas. Se puede encontrar el archivo binario escribiendo which <nombre-de-gestor-ventanas>, donde <nombre-de-gestor-ventanas> es el nombre del gestor de ventanas que desea ejecutar.

Por ejemplo:

user@host# which twm/usr/bin/twm
user@host# xinit -e /usr/bin/twm

El primer comando retorna la ruta absoluta del gestor de ventanas twm, el segundo comando inicia twm.

Para salir de un gestor de ventanas, cierra la última ventana o presione Ctrl-Alt-Backspace. Una vez haya salido del gestor de ventanas, puede regresar al nivel de ejecución 5 escribiendo startx en el intérprete de comandos.

31.3. Archivos de configuración del servidor X

El servidor X es un binario ejecutable (/usr/bin/Xorg). Los archivos de configuración asociados se almacenan en el directorio /etc/X11/ (es un enlace simbólico — X — que apunta a /usr/bin/Xorg). El archivo de configuración para el servidor X es /etc/X11/xorg.conf.

El directorio /usr/lib/xorg/modules/ contiene los módulos del servidor X que pueden ser cargados dinámicamente en tiempo de ejecución. Por defecto, el servidor X sólo carga algunos de los módulos en /usr/lib/xorg/modules/.

Para cargar módulos opcionales, éstos deben ser especificados en el archivo de configuración del servidor X, /etc/X11/xorg.conf. Para mayor información sobre cómo cargar los módulos, consulte la Sección 31.3.1.5, “Module.

When Red Hat Enterprise Linux 5.2 is installed, the configuration files for X are created using information gathered about the system hardware during the installation process.

31.3.1. xorg.conf

Mientras que casi nunca se necesita editar manualmente el /etc/X11/xorg.conf, es muy útil conocer sobre las diferentes secciones y los parámetros opcionales disponibles, especialmente cuando se estén solucionando problemas.

31.3.1.1. La estructura de XFree86

El archivo /etc/X11/xorg.conf está formado de muchas secciones diferentes las cuales hacen referencia a aspectos específicos del hardware del sistema.

Cada sección comienza con una línea Section "<nombre-de-sección>" (donde <nombre-de-sección> es el título para la sección) y termina con una línea EndSection. Dentro de cada sección hay líneas que contienen los nombres de las opciones y uno o más valores para la opción. Estos últimos van, ocasionalmente, entre comillas (").

Las líneas que comienzan con un símbolo de almohadilla (#) no son leídas por el servidor X y son usadas como comentarios legibles.

Algunas opciones dentro del archivo /etc/X11/xorg.conf aceptan un interruptor boleano el cual activa o desactiva la característica. Los valores boleanos aceptados son:

  • 1, on, true, o yes — Activa la opción.

  • 0, off, false, o no — Desactiva la opción.

Lo siguiente son algunas de las secciones más importantes ordenadas como aparecen en un archivo /etc/X11/xorg.conf típico. Se puede encontrar más información detallada sobre el archivo de configuración del servidor X en la página man de xorg.conf.

31.3.1.2. ServerFlags

La sección opcional ServerFlags contiene varios parámetros globales del servidor X. Cualquier parámetro en esta sección puede ser sobreescrito por las opciones ubicadas en la sección ServerLayout (consulte la Sección 31.3.1.3, “ServerLayout para obtener mayor información).

Cada entrada dentro de la sección ServerFlags están en sus propias líneas y comienzan con el término Option seguido por una opción encerrada en dobles comillas ".

A continuación un ejemplo de la sección ServerFlags:

Section "ServerFlags" Option "DontZap" "true" EndSection

La siguiente es una lista de las opciones más útiles:

  • "DontZap" "<boleano>" — Cuando el valor de <boleano> está configurado a verdadero, esta configuración previene el uso de la combinación de teclas Ctrl-Alt-Retroceso para terminar inmediatamente el servidor X.

  • "DontZoom" "<boleano>" — Cuando el valor de <boleano> está colocado a verdadero, esta configuración previene moverse a lo largo de las resoluciones de vídeo configuradas usando las combinaciones de teclas Ctrl-Alt-Keypad-Plus y Ctrl-Alt-Keypad-Minus.

31.3.1.3. ServerLayout

La sección ServerLayout vincula los dispositivos de entrada y salida controlados por el servidor X. Como mínimo, esta sección debe especificar un dispositivo de salida y un dispositivo de entrada. Por defecto se especifica un monitor (dispositivo de salida) y un teclado (dispositivo de entrada).

El ejemplo siguiente ilustra una sección ServerLayout típica:

Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection

Las entradas siguientes son usadas a menudo en la sección ServerLayout:

  • Identifier — Especifica un nombre único para esta sección ServerLayout.

  • Screen — Especifica el nombre de la sección Screen a ser usado con el servidor X. Pueden estar presentes más de una opción Screen.

    Lo siguiente es un ejemplo de una entrada Screen típica:

    Screen 0 "Screen0" 0 0
    

    El primer número en esta entrada de ejemplo Screen (0) indica que el primer conector del monitor o head en la tarjeta de vídeo usa la configuración especificada en la sección Screen con el identificador "Screen0".

    Un ejemplo de la sección Screen con el identificador "Screen0" se puede encontrar en la Sección 31.3.1.9, “Screen.

    Si la tarjeta de vídeo tiene más de una cabeza, será necesaria otra entrada Screen con un número diferente y un identificador de sección Screen.

    Los números a la derecha de "Screen0" proporcionan las coordenadas absolutas X y Y para la esquina superior izquierda de la pantalla (0 0 por defecto).

  • InputDevice — Especifica el nombre de una sección InputDevice a ser usada con el servidor X.

    Se recomienda utilizar al menos dos entradas InputDevice: una para el ratón y una para el teclado. Las opciones CorePointer y CoreKeyboard indican que estos son el ratón y el teclado principal.

  • Option "<nombre-opcion>" — Una entrada opcional que especifica parámetros extra para esta sección. Cualquier sección listada aquí sobreescriben aquellas listadas en la sección ServerFlags.

    Reemplace <nombre-opcion> con una opción válida listada para esta sección en la página man de xorg.conf.

Es posible crear más de una sección ServerLayout en el archivo /etc/X11/xorg.conf. Sin embargo, el servidor sólo leerá la primera sección que aparezca.

Si hay una sección ServerLayout alternativa, ésta se puede especificar como argumento en la línea de comandos cuando inicie la sesión X.

31.3.1.4. Files

La sección Archivos establece rutas importantes para el funcionamiento del servidor X (como por ejemplo la ruta de las fuentes tipográficas). Esta sección es opcional, estas rutas son normalmente detectadas de forma automática. Esta sección puede ser usada para sobreescribir las rutas detectadas automáticamente.

El siguiente ejemplo ilustra una sección Files:

Section "Files" RgbPath "/usr/share/X11/rgb.txt" FontPath "unix/:7100" EndSection

Las siguientes entradas son usadas comúnmente en la sección Files:

  • RgbPath — Especifica la ubicación de la base de datos de colores RGB. Esta base de datos define todos los esquemas de color en X y los junta para valores RGB especificos.

  • FontPath — Especifica dónde el servidor X debe ser conectado para obtener las fuentes tipográficas desde el servidor de fuentes xfs.

    Por defecto, la FontPath es unix/:7100. Esto le dice al servidor X que obtenga información de fuentes usando sockets de dominio UNIX para la comunicación entre procesos (IPC) en el puerto 7100.

    Consulte la Sección 31.4, “Fuentes” para obtener mayor información concerniente a X y fuentes tipográficas.

  • ModulePath — Un parámetro opcional el cual especifica directorios alternativos que almacenan módulos de servidor X.

31.3.1.5. Module

Por defecto, el servidor X carga automáticamente los siguientes módulos desde el directorio /usr/lib/xorg/modules/:

  • extmod

  • dbe

  • glx

  • freetype

  • type1

  • record

  • dri

El directorio predeterminado para cargar estos módulos puede modificarse a través del parámetro opcional ModulePath en la sección Files. Consulte la Sección 31.3.1.4, “Files para obtener mayor información sobre esta sección.

Si se añade una sección Module a /etc/X11/xorg.conf, el servidor X cargará los módulos listados en esta sección en vez de los módulos predeterminados.

Por ejemplo, la siguiente sección Module:

Section "Module" Load "fbdevhw" EndSection

indica al servidor X que cargue fbdevhw en vez de los módulos predeterminados.

Por lo cual, si añade una sección Module a /etc/X11/xorg.conf, deberá especificar cualquier módulo predeterminado que desea cargar además de los módulos adicionales.

31.3.1.6. InputDevice

Cada sección InputDevice configura un dispositivo de entrada para el servidor X. Los sistemas típicamente tienen al menos una sección InputDevice para el teclado. Es normal no tener una entrada para el ratón. La mayoría de parámetros del ratón son detectados automáticamente.

El siguiente ejemplo ilustra una sección InputDevice típica para el teclado:

Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection

Las entradas siguientes son comúnmente usadas en la sección InputDevice:

  • Identifier — Especifica un nombre único para esta sección InputDevice. Esto es una entrada requerida.

  • Driver — Especifica el nombre del controlador del dispositivo que X debe cargar para el dispositivo.

  • Option — Especifica las opciones necesarias pertinentes al dispositivo.

    Un ratón puede ser especificado para sobrescribir cualquier parámetro predeterminado para el dispositivo. Las siguientes opciones son normalmente incluidas cuando se añade un ratón en xorg.conf:

    • Protocol — Indica el protocolo usado por el ratón, tal como IMPS/2.

    • Device — Indica la ubicación del dispositivo físico.

    • Emulate3Buttons — Especifica si se permite que un ratón de dos botones se comporte como uno de tres cuando se presionan ambos botones simultáneamente.

    Consulte la página man de xorg.conf para una lista de las opciones válidas para esta sección.

31.3.1.7. Monitor

Cada sección Monitor configura un tipo de monitor utilizado por el sistema. Esta también es una entrada opcional, ya que la mayoría de monitores son detectados automáticamente.

La forma más sencilla de configurar un monitor es durante el proceso de instalación o usando la Herramienta de configuración X. Para obtener mayor información sobre el uso de la Herramienta de configuración X, consulte el Capítulo 32, Configuración del Sistema X Window.

Este ejemplo muestra una sección de Monitor típica:

Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DDC Probed Monitor - ViewSonic G773-2" DisplaySize 320 240 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 180.0 EndSection

Aviso

Tenga cuidado si está modificando manualmente los valores en la sección Monitor de /etc/X11/xorg.conf. Valores inapropiados pueden dañar o destruir su monitor. Consulte la documentación de su monitor para un listado de parámetros seguros.

A continuación se muestran entradas comunes usadas en la sección Monitor:

  • Identifier — Proporciona un nombre único para esta sección Monitor. Esta es una entrada requerida.

  • VendorName — Parámetro opcional que muestra el nombre del fabricante del monitor.

  • ModelName — Parámetro opcional que muestra el nombre del modelo del monitor.

  • DisplaySize — Un parámetro opcional que especifica, en milímetros, el tamaño físico del área de dibujo del monitor.

  • HorizSync — Especifica el rango de la frecuencia de sincronización horizontal compatible con el monitor, en kHz. Estos valores ayudan al servidor X a determinar la validez de las entradas Modeline especificadas o incorporadas para el monitor.

  • VertRefresh — Especifica los rangos de frecuencias de actualización verticales soportados por el monitor, en Hz. Estos valores ayudan a que el servidor X determine la validez de las entradas incorporadas o especificadas en Modeline para este monitor.

  • Modeline — Un parámetro opcional el cual especifica los modos de vídeo adicionales para el monitor en resoluciones particulares, con ciertas resoluciones de refrescamiento vertical y sincronización horizontal. Vea la página man de xorg.conf para una explicación más detallada de las entradas Modeline.

  • Option "<nombre-opcion>" — Una entrada opcional que especifica parámetros extra para la sección. Reemplace <nombre-opcion> con una opción válida listada para esta sección en la página man de xorg.conf.

31.3.1.8. Device

Cada sección Device configura una tarjeta de vídeo en el sistema. Aunque una sección Device es lo mínimo, también se pueden tener instancias adicionales para cada tarjeta de vídeo instalada en la máquina.

La mejor forma de configurar una tarjeta de vídeo es configurando X durante el proceso de instalación o usando la Herramienta de configuración X. Para obtener mayor información sobre el uso de la Herramienta de configuración X consulte el Capítulo 32, Configuración del Sistema X Window.

El siguiente ejemplo ilustra una sección Device típica para una tarjeta de vídeo:

Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" VideoRam 8192 Option "dpms" EndSection

Las siguientes entradas son usadas comúnmente en la sección Device:

  • Identifier — Especifica un nombre único para esta sección Device. Esta es una entrada requerida.

  • Driver — Especifica cuál controlador debe cargar el servidor X para poder utilizar la tarjeta de vídeo. Se puede encontrar una lista de los controladores en /usr/share/hwdata/videodrivers, el cual es instalado con el paquete hwdata.

  • VendorName — Un parámetro opcional el cual especifica el fabricante de la tarjeta de vídeo.

  • BoardName — Un parámetro opcional el cual especifica el nombre de la tarjeta de vídeo.

  • VideoRam — Un parámetro opcional el cual especifica la cantidad de RAM disponible en la tarjeta de vídeo en kilobytes. Este valor sólo es necesario para tarjetas de vídeo que el servidor X no puede probar para detectar la cantidad de RAM.

  • BusID — Una entrada que especifica la ubicación del bus de la tarjeta de vídeo. En sistemas con tan sólo una tarjeta de vídeo, la entrada BusID es opcional y puede no aparecer en el archivo /etc/X11/xorg.conf predeterminado. Sin embargo, en sistemas con más de una tarjeta de vídeo, la entrada BusID debe estar presente.

  • Screen — Una entrada opcional la cual especifica que conector de monitor o cabezal en la tarjeta de vídeo configura la sección Device. Esta opción es útil solamente para tarjetas de vídeo con múltiples cabezales.

    Si múltiples monitores son conectados a diferentes cabezales en la misma tarjeta de vídeo, deben existir secciones Device separadas y cada una de estas secciones debe tener un valor Screen diferente.

    Los valores para la entrada Screen deben ser enteros. El primer cabezal en la tarjeta de vídeo tiene un valor de 0. El valor para cada cabezal adicional incrementa este valor en uno.

  • Option "<nombre-opcion>" — Una entrada opcional que especifica parámetros extra para la sección. Reemplace <nombre-opcion> con una opción válida listada para esta sección en la página man de xorg.conf.

    Una de las opciones más comunes es "dpms" (del ingés Display Power Management Signaling, un estándar VESA). Esta opción activa la configuración de conformidad de energía Service Star para el monitor.

31.3.1.9. Screen

Cada sección Screen vincula una tarjeta de vídeo (o cabezal) a un monitor referenciando la sección Device y la sección Monitor para cada uno. Mientras que una sección Screen es lo mínimo, pueden ocurrir instancias adicionales para cada combinación de tarjeta de vídeo y monitor presente en la máquina.

El ejemplo siguiente ilustra una sección Screen típica:

Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection

Las siguientes entradas son usadas a menudo en la sección Screen:

  • Identifier — Especifica un nombre único para esta sección Screen. Esta es una entrada requerida.

  • Device — Especifica el nombre único de una sección Device. Esta es una entrada requerida.

  • Monitor — Especifica el nombre único de la sección Monitor. Esto sólo es requerido si se especifica una sección Monitor en el archivo xorg.conf. Normalmente, los monitores son detectados automáticamente.

  • DefaultDepth — Especifica la profundidad del color por defecto en bits. En el ejemplo anterior, el valor por defecto es 16 (lo cual proporciona miles de colores). Sólo una entrada DefaultDepth es permitida, pero ésta puede ser sobrescrita por la opción de la línea de comandos -depth <n>, en donde <n> es cualquier profundidad adicional especificada.

  • SubSection "Display" — Especifica los modos de la pantalla disponibles en una profundidad de color particular. Una sección Screen puede tener múltiples subsecciones Display. Éstas son opcionales ya que los modos de la pantalla son automáticamente detectados.

    Esta subsección es generalmente usada para sobrescribir modos automáticamente detectados.

  • Option "<nombre-opcion>" — Una entrada opcional que especifica parámetros extra para la sección. Reemplace <nombre-opcion> con una opción válida listada para esta sección en la página man de xorg.conf.

31.3.1.10. DRI

La sección opcional DRI especifica parámetros para Direct Rendering Infrastructure (DRI). DRI es una interfaz que permite a las aplicaciones de software 3D sacar provecho de las capacidades de aceleración de hardware 3D incorporadas en la mayoría del hardware moderno de vídeo. Además, DRI puede mejorar el rendimiento de 2D a través de la aceleración de hardware, si es soportado por el controlador de la tarjeta.

Esta sección aparece raramente ya que el grupo y el modo DRI son automáticamente inicializados a sus valores predeterminados. Si se desea un grupo o modo diferente, los valores añadidos a esta sección en xorg.conf sobreescribirán los valores predeterminados.

El ejemplo siguiente muestra una sección DRI típica:

Section "DRI" Group 0 Mode 0666 EndSection

Puesto que tarjetas de vídeo diferentes utilizan DRI de formas diferentes, no modifique estos valores para esta sección sin primero consultar http://dri.sourceforge.net/.

31.4. Fuentes

Red Hat Enterprise Linux utiliza dos sistemas para administrar y visualizar fuentes tipográficas bajo X: Fontconfig y xfs

El subsistema de fuentes Fontconfig simplifica la gestión de fuentes y proporciona características de visualización avanzadas, tales como anti-aliasing. Este sistema es usado automáticamente para aplicaciones programadas usando el conjunto de herramientas gráficas Qt 3 o GTK+ 2.

Por compatibilidad, Red Hat Enterprise Linux incluye el subsistema de fuentes original, llamado el subsistema de fuentes núcleo de X. Este sistema, el cual tiene más de 15 años, está basado en el Servidor de fuentes de X (xfs).

Esta sección discute cómo configurar fuentes para X usando ambos sistemas.

31.4.1. Fontconfig

El subsistema de fuentes Fontconfig permite a las aplicaciones accesar directamente fuentes en el sistema y usar Xft u otros mecanismos de traducción de fuentes para interpretar fuentes Fontconfig con anti-aliasing avanzados. Las aplicaciones gráficas pueden usar la librería Xft con Fontconfig para dibujar texto a la pantalla.

Con el tiempo, el subsistema de fuentes Fontconfig/Xft reemplazará el subsistema de fuentes base de X.

Importante

El subsistema de fuentes Fontconfig aún no funciona para OpenOffice.org, el cual tiene sus propias tecnologías de interpretación de fuentes tipográficas.

Es importante resaltar que Fontconfig utiliza el archivo de configuración /etc/fonts/fonts.conf el cual no se debería modificar manualmente.

Sugerencia

Debido a la transición al nuevo sistema de fuentes, las aplicaciones GTK+ 1.2 no son afectadas por ningún cambio realizado a través del diálogo Preferencias de tipografía (al cual se accede a través de System (on the panel) => Preferencias => Tipografía). Para estas aplicaciones, se puede configurar una fuente añadiendo las líneas siguientes al archivo ~/.gtkrc.mine:

style "user-font" { fontset = "<font-specification>" } widget_class "*" style "user-font"

Sustituya <font-specification> con una especificación de fuente en el estilo utilizado por las aplicaciones X tradicionales, tales como -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*. Se puede obtener una lista completa de las fuentes base ejecutando xlsfonts o creándolas interactivamente usando el comando xfontsel.

31.4.1.1. Añadir fuentes a Fontconfig

Añadir fuentes al subsistema Fontconfig es un proceso bastante directo.

  1. Para añadir fuentes tipográficas globales al sistema, copie las fuentes al directorio /usr/share/fonts/. Es una buena idea crear un nuevo subdirectorio, tal como local/ o similar, para ayudar a distinguir entre las fuentes del usuario y las instaladas por defecto.

    Para añadir fuentes para un usuario individual, copie las nuevas fuentes en el directorio .fonts/ en el directorio principal del usuario.

  2. Utilice el comando fc-cache para actualizar la información caché de la fuente, como en el ejemplo siguiente:

    fc-cache <ruta-directorio-fuentes>
    

    En este comando, sustituya <path-to-font-directory> con el directorio conteniendo las nuevas fuentes (bien sea /usr/share/fonts/local/ o /home/<user>/.fonts/).

Sugerencia

Usuarios individuales también pueden instalar fuentes tipográficas gráficamente, escribiendo fonts:/// en la barra de direcciones de Nautilus y arrastrando los nuevos archivos de fuentes allí.

Importante

Si el nombre del archivo de fuentes termina con una extensión .gz, está comprimido y no puede ser usado hasta que se descomprima. Para hacer esto, utilice el comando gunzip o haga doble-clic sobre el archivo y arrastre la fuente a un directorio en Nautilus.

31.4.2. Sistema de fuentes base de X

Por compatibilidad, Red Hat Enterprise Linux proporciona el subsistema de fuentes tipográficas núcleo de X, el cual utiliza el servidor de fuentes X (xfs) para proporcionar fuentes tipográficas a las aplicaciones clientes X.

El servidor X busca un servidor de fuentes tipográficas especificado en la directiva FontPath bajo la sección Files del archivo de configuración /etc/X11/xorg.conf. Consulte la Sección 31.3.1.4, “Files para obtener mayor información sobre la entrada FontPath.

El servidor X se conecta al servidor xfs en un puerto especificado para adquirir la información sobre las fuentes tipográficas. Por esta razón, el servicio xfs debe estar ejecutándose para que X pueda arrancar. Para obtener mayor información sobre cómo configurar servicios en los diferentes niveles de ejecución, consulte Capítulo 16, Control de acceso a servicios.

31.4.2.1. Configuración de xfs

El script /etc/rc.d/init.d/xfs inicia el servidor xfs. Se pueden configurar muchas opciones dentro del archivo /etc/X11/fs/config.

La siguiente es una lista de algunas opciones comunes:

  • alternate-servers — Especifica una lista de servidores alternativos de fuentes tipográficas que podrán ser utilizados en el caso de que el servidor actual no esté disponible. Los diferentes servidores deberán estar separados por comas.

  • catalogue — Especifica una lista ordenada de rutas que contienen las fuentes tipográficas a utilizar. Cada ruta hacia las fuentes deberá estar separada por una coma en la lista.

    Puede utilizar la cadena :unscaled inmediatamente después de la ruta hacia las fuentes para hacer que las fuentes no escalables se carguen primero. Entonces, podrá especificar la ruta completa de nuevo de tal forma que las otras fuentes que sean escalables puedan ser cargadas también.

  • client-limit — Configura el número máximo de clientes que el servidor de fuentes podrá servir. El número por defecto es 10.

  • clone-self — Permite al servidor de fuentes clonar una nueva versión de sí mismo si se llega al límite definido por el parámetro client-limit. Por defecto, esta opción está configurada como on.

  • default-point-size — Configura el tamaño de punto por defecto para cualquier fuente que no especifique este valor. El valor de esta opción está estimado en décimas de puntos. El valor por defecto de 120 se corresponde a fuentes de 12 puntos.

  • default-resolutions — Especifica una lista de las resoluciones soportadas por el servidor X. Cada resolución de la lista debe estar separada por una coma.

  • deferglyphs — Especifica si retrasar la carga de glyphs (el gráfico usado para visualmente representar una fuente). Para desactivar esta característica utilice none, para activarla para todas las fuentes utilice all, o para activar esta característica solamente para fuentes de 16-bit use 16.

  • error-file — Le permite especificar la ruta y el nombre de archivo donde se almacenarán los informes de error de xfs.

  • no-listen — Dice a xfs que no escuche determinados protocolos. Por defecto, esta opción está configurada con tcp para evitar que xfs escuche utilizando puertos TCP, por motivos de seguridad.

    Sugerencia

    Si está utilizando xfs para servir fuentes sobre la red, elimine esta línea.

  • port — Especifica el puerto TCP en el cual xfs escuchará si no-listen no existe o está entre comentarios.

  • use-syslog — Especifica si utilizar el registro de errores del sistema.

31.4.2.2. Añadir fuentes a xfs

Para añadir fuentes al subsistema base de fuentes de X (xfs), siga los pasos siguientes:

  1. Si aún no existe, cree un directorio llamado /usr/share/fonts/local/ usando el comando siguiente como usuario root:

    mkdir /usr/share/fonts/local/
    

    Si es necesario la creación del directorio /usr/share/fonts/local/, se debe añadir a la ruta xfs usando el comando siguiente como root:

    chkfontpath --add /usr/share/fonts/local/ 
    
  2. Copie el nuevo archivo de fuente en el directorio /usr/share/fonts/local/

  3. Actualice la información de la fuente emitiendo el siguiente comando como root:

    ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale
    
  4. Vuelva a cargar el archivo de configuración del servidor de fuentes xfs, utilizando el comando siguiente como root:

    service xfs reload
    

31.5. Niveles de ejecución y X

En la mayoría de los casos, la instalación por defecto de Red Hat Enterprise Linux configura una máquina para iniciar en un entorno de conexión gráfico, conocido como nivel de ejecución 5. Es posible, sin embargo, arrancar en el modo multiusuario de sólo texto llamado nivel de ejecución 3 y comenzar una sesión X desde allí.

Para obtener mayor información sobre los niveles de ejecución, consulte la Sección 16.1, “Niveles de ejecución”.

Las siguientes subsecciones revisan cómo inicia X en los niveles de ejecución 3 y 5.

31.5.1. Nivel de ejecución 3

Cuando estamos en el nivel de ejecución 3, la forma habitual de iniciar una sesión X es escribiendo el comando startx. El comando startx es una interfaz del programa xinit el cual lanza el servidor X (Xorg) y conecta aplicaciones clientes X al mismo. Puesto que el usuario ya está conectado al sistema en el nivel de ejecución 3, startx no lanzará un gestor de visualización o autenticará al usuario. Consulte la Sección 31.5.2, “Nivel de ejecución 5” para obtener mayor información sobre los gestores de visualización.

Cuando se ejecuta el comando startx, se busca el archivo .xinitrc en el directorio principal del usuario para definir el entorno de escritorio y posiblemente otras aplicaciones clientes X a ejecutar. Si este archivo .xinitrc no se encuentra, se utilizará el archivo por defecto /etc/X11/xinit/xinitrc.

El script xinitrc predeterminado buscará luego los archivos definidos por el usuario y archivos de sistema por defecto, incluyendo .Xresources, .Xmodmap y .Xkbmap en el directorio principal del usuario y Xresources, Xmodmap y Xkbmap en el directorio /etc/X11/. Si existen los archivos Xmodmap y Xkbmap, estos son usados por la utilidad xmodmap para configurar el teclado. El archivo Xresources es leído para asignar valores de preferencia específicos a las aplicaciones.

Después de configurar estas opciones, el script xinitrc ejecuta todos los scripts localizados en el directorio /etc/X11/xinit/xinitrc.d/. Un script muy importante en este directorio es xinput.sh, el cual configura parámetros como el idioma por defecto.

Luego, el script xinitrc intenta ejecutar .Xclients en el directorio principal del usuario y cambia a /etc/X11/xinit/Xclients si no lo puede encontrar. El propósito del archivo Xclients es arrancar el entorno de escritorio o, posiblemente, sólo un gestor de ventanas básico. El script .Xclients en el directorio principal del usuario inicia el entorno de escritorio especificado por el usuario en el archivo .Xclients-default. Si .Xclients no existe en el directorio principal del usuario, el script estándar /etc/X11/init/Xclients intenta iniciar otro entorno de escritorio, intentando primero con GNOME y luego con KDE seguido por twm.

Cuando se está en el nivel de ejecución 3, el usuario es devuelto a una sesión en modo texto después de desconectarse de X.

31.5.2. Nivel de ejecución 5

Cuando el sistema arranca en el nivel de ejecución 5, se lanza una aplicación cliente de X especial llamada gestor de visualización. El usuario debe autenticarse usando el gestor de visualización antes de que se inicien cualquier entorno de escritorio o gestores de ventanas.

Dependiendo de los entornos de escritorio instalados en su máquina, están disponibles tres gestores de visualización diferentes para manejar la autenticación de los usuarios.

  • GNOME — Es el gestor de visualización por defecto para Red Hat Enterprise Linux y permite que el usuario configure los parámetros de idioma, cierre del sistema, reinicio o conexión al sistema.

  • KDE — El gestor de visualización de KDE que permite a los usuarios apagar, reiniciar o conectarse al sistema.

  • xdm — Este es un gestor de visualización muy básico que sólo permite que el usuario se conecte al sistema.

Cuando arranque en el nivel de ejecución 5, el script prefdm determina el gestor de visualización preferido haciendo referencia al archivo /etc/sysconfig/desktop. Una lista de opciones para este archivo está disponible en:

/usr/share/doc/initscripts-<número-versión>/sysconfig.txt

en donde <número-versión> es el número de la versión del paquete initscripts.

Cada uno de los gestores de visualización hace referencia al archivo /etc/X11/xdm/Xsetup_0 para configurar la pantalla de conexión. Una vez que el usuario se conecte al sistema, el script /etc/X11/xdm/GiveConsole corre para asignar la propiedad de la consola al usuario. Luego, el script /etc/X11/xdm/Xsession se ejecuta para llevar a cabo muchas de las tareas que son normalmente realizadas por el script xinitrc cuando arranca X desde el nivel de ejecución 3, incluyendo la configuración del sistema y los recursos del usuario, así como también ejecutar los scripts en el directorio /etc/X11/xinit/xinitrc.d/.

El usuario puede especificar cuál entorno de escritorio desea utilizar cuando se autentican usando los gestores de visualización GNOME o KDE, seleccionándolo desde el menú Sesiones (a través de System (on the panel) => Preferencias => Más preferencias => Sesiones). Si el entorno de escritorio no es especificado en el gestor de visualización, el script /etc/X11/xdm/Xsession verificará los archivos .xsession y .Xclients en el directorio principal del usuario para decidir cuál entorno de escritorio cargar. Como último recurso, se utiliza el archivo /etc/X11/xinit/Xclients para seleccionar un entorno de escritorio o gestor de ventanas para usarse de la misma forma que en el nivel de ejecución 3.

Cuando el usuario termina una sesión X en la visualización por defecto (:0) y se desconecta, el script /etc/X11/xdm/TakeConsole se ejecuta y vuelve a asignar la propiedad de la consola al usuario root. El gestor de visualización original, que continúa ejecutándose después de que el usuario se conecta, toma el control al liberar un nuevo gestor de visualización. Esto reinicia el servidor X, despliega una nueva ventana de conexión y reinicia el proceso completo otra vez.

El usuario es devuelto al gestor de visualización después de desconectarse de X desde el nivel de ejecución 5.

Para obtener mayor información sobre cómo los gestores de visualización controlan la autenticación de los usuarios, consulte /usr/share/doc/gdm-<número-versión>/README (donde <número-versión> es el número de la versión para el paquete gdm instalado) y la página man de xdm.

31.6. Recursos adicionales

Se podría decir mucho más sobre el servidor X, los clientes que se conectan a él y la variada gama de entornos de escritorio y gestores de ventanas.

31.6.1. Documentación instalada

  • /usr/share/X11/doc/ — Contiene documentación detallada sobre la arquitectura del sistema de ventanas X, así como la manera de obtener información adicional como nuevo usuario.

  • man xorg.conf — Contiene información sobre los archivos de configuración xorg.conf incluyendo el significado y la sintaxis para las diversas secciones dentro de los archivos.

  • man Xorg — Describe el servidor de visualización Xorg.

31.6.2. Sitios Web útiles

  • http://www.X.org/ — Página principal de la Fundación X.Org, que produce el lanzamiento X11R7.1 del sistema de ventanas X. El lanzamiento X11R6.8 se proporciona junto con Red Hat Enterprise Linux para controlar el hardware necesario y proporcionar un entorno gráfico.

  • http://dri.sourceforge.net/ — Página principal del proyecto DRI (Direct Rendering Infrastructure). DRI es el corazón del componente de aceleración 3D de X.

  • http://www.gnome.org/ — Página principal del proyecto GNOME.

  • http://www.kde.org/ — Página principal del entorno de escritorio KDE.

Capítulo 32. Configuración del Sistema X Window

Durante la instalación se configura el monitor del sistema, la tarjeta de vídeo y los parámetros de la visualización. Para cambiar cualquiera de estos valores después de la instalación, utilice la Herramienta de configuración X.

Para arrancar la Herramienta de configuración X, vaya al System (on the panel) => Administración => Visualización, o escriba el comando system-config-display en un intérprete de comandos de shell (por ejemplo, en un XTerm o en una terminal GNOME). Si el Sistema X Window no se está en ejecución, se iniciará una pequeña versión de X para ejecutar el programa.

Después de cambiar cualquiera de estas configuraciones, cierre la sesión del escritorio gráfico y vuelva a conectarse para activar los cambios.

32.1. Configuraciones de la visualización

La pestaña Configuración le permite a los usuarios cambiar la resolución y la profundidad del color. La visualización de un monitor consiste en pequeños puntos llamados píxeles. El número de píxeles desplegados a la vez es llamado resolución. Por ejemplo, la resolución de 1024x768 significa que se utilizan 1024 píxeles horizontales y 768 píxeles verticales. Mientras más alto los números de resolución, más imágenes el monitor puede mostrar en un momento.

La profundidad del color de una visualización determina cuántos colores posibles son mostrados. Mientras más alto sea la profundidad del color, habrá más contraste entre colores.

Configuraciones de la visualización

Configuraciones de la visualización

Figura 32.1. Configuraciones de la visualización

32.2. Configuraciones del hardware de visualización

La aplicación Herramienta de configuración X prueba el monitor y la tarjeta de vídeo una vez iniciada. Si el hardware es probado adecuadamente, la información es mostrada en la pestaña Hardware como se muestra en la Figura 32.2, “Configuraciones del hardware de visualización”.

Configuraciones del hardware de visualización

Configuraciones de hardware de visualización

Figura 32.2. Configuraciones del hardware de visualización

Para cambiar el tipo de monitor o cualquiera de sus propiedades, haga click en el botón Configurar correspondiente. Para cambiar el tipo de tarjeta de vídeo o cualquiera de sus valores, haga click en el botón Configurar al lado de sus configuraciones.

32.3. Configuraciones de visualización en dos pantallas

Si varias tarjetas de vídeo son instaladas en el sistema, el soporte de dos pantallas estará disponible y podrá ser configurado a través de la pestaña Dos pantallas como se muestra en la Figura 32.3, “Configuraciones de visualización en dos pantallas”.

Configuraciones de visualización en dos pantallas

Configuraciones de visualización en dos pantallas

Figura 32.3. Configuraciones de visualización en dos pantallas

Para activar el uso de dos pantallas, seleccione la casilla de verificación Utilizar dos pantallas.

Para configurar el segundo tipo de monitor, haga clic en el botón Configurar correspondiente. También puede configurar los otros parámetros de visualización en dos pantallas si utiliza la lista en el menú desplegable.

Para la opción Disposición del escritorio, seleccione Extendiendo escritorios para que ambas pantallas utilicen un espacio de trabajo extendido. Seleccione Escritorios individuales para compartir el ratón y el teclado en las diferentes pantallas. Esta última opción restringe las ventanas a una sola pantalla.

Capítulo 33. Usuarios y grupos

El control de los usuarios y grupos es un elemento clave en la administración de sistemas de Red Hat Enterprise Linux.

Los Usuarios pueden ser gente real, es decir, cuentas ligadas a un usuario físico en particular, o cuentas que existen para ser usadas por aplicaciones específicas.

Los Grupos son expresiones lógicas de organización, reuniendo usuarios para un propósito común. Los usuarios dentro de un mismo grupo pueden leer, escribir o ejecutar archivos que pertenecen a ese grupo.

Cada usuario y grupo tiene un número de identificación único llamado identificador de usuario (UID) y un identificador de grupo (GID) respectivamente.

Un usuario que crea un archivo se convierte en el propietario y el grupo propietario de ese archivo. Al archivo también se le asignan permisos separados de lectura, escritura y ejecución para el propietario del archivo, para el grupo y para cualquier otro usuario. Solamente el superusuario (root) puede cambiar el propietario de un archivo. Los permisos de acceso pueden ser cambiados tanto por el superusuario como por el creador del archivo.

33.1. Configuración de grupos y de usuarios

El Administrador de usuarios le permite ver, modificar, añadir y borrar los usuarios y grupos locales.

Para usar el Administrador de usuarios, debe estar ejecutando el sistema de ventanas X, tener privilegios de root y tener el paquete RPM system-config-users instalado. Para iniciar el Administrador de usuarios desde el escritorio, vaya a System (on the panel) => Administración => Usuarios y grupos. También puede escribir el comando system-config-users en el intérprete del comandos (en un terminal XTerm o GNOME, por ejemplo).

Administrador de usuarios

Administrador de usuarios

Figura 33.1. Administrador de usuarios

Para ver una lista de los usuarios locales del sistema, haga click en la pestaña Usuarios. Para visualizar una lista de los grupos locales del sistema, haga click en la pestaña Grupos.

Si necesita encontrar un usuario o grupo específico, teclee las primeras letras del nombre en el campo Filtro de búsqueda. Pulse Intro o pulse en el botón Aplicar filtro. Aparecerá la lista filtrada.

Para ordenar los usuarios o grupos, haga click en el nombre de la columna. Los usuarios o grupos son clasificados por el valor en esa columna.

Red Hat Enterprise Linux reserva los IDs de usuario por debajo de 500 para los usuarios del sistema. Por defecto, la Administrador de usuarios no muestra los usuarios del sistema. Para ver todos los usuarios, incluyendo los usuarios del sistema, vaya a Editar => Preferencias y anule la selección de Ocultar usuarios y grupos del sistema

33.1.1. Añadir un nuevo usuario

Para añadir un nuevo usuario, haga clic en el botón Añadir usuario. Aparecerá una ventana como la mostrada en la Figura 33.2, “Nuevo usuario”. Escriba el nombre de usuario y el nombre completo para el nuevo usuario en los campos apropiados. Teclee la contraseña de usuario en los campos Contraseña y Confirmar contraseña. La contraseña debe tener al menos seis caracteres.

Sugerencia

Cuanto más larga sea una contraseña, más difícil es que alguien la adivine y se registre en la cuenta de usuario sin permiso. Es aconsejable que la contraseña no sea una palabra basada en un término del diccionario sino una combinación de letras, números y caracteres especiales.

Seleccione una shell de registro. Si no está seguro de qué shell seleccionar, acepte el valor por defecto de /bin/bash. El directorio principal por defecto es /home/<nombredeusuario>. Puede cambiar el directorio principal que se ha creado para el usuario o puede escoger no crear el directorio principal anulando la selección Crear directorio principal.

Si seleccionó crear el directorio principal, los archivos de configuración por defecto son copiados desde el directorio /etc/skel en el nuevo directorio principal.

Red Hat Enterprise Linux utiliza un esquema grupo de usuario privado (UPG). El esquema UPG no añade ni cambia nada en el modo estándar de UNIX de gestionar grupos; simplemente ofrece una nueva convención. Siempre que cree un nuevo usuario, por defecto, se crea un grupo único con el mismo nombre que el del usuario. Si no desea crear este grupo, anule la selección Crear un grupo privado para este usuario.

Para especificar el ID del usuario, seleccione Especificar el ID del usuario manualmente. Si la opción no ha sido seleccionada, se asignará al nuevo usuario el próximo ID del usuario disponible que empiece con el número 500. Red Hat Enterprise Linux se reserva los IDs de usuario por debajo de 500 para los usuarios de sistemas; no es aconsejable usar números menores a 500.

Haga clic en OK para crear el usuario.

Nuevo usuario

Creación de un nuevo usuario

Figura 33.2. Nuevo usuario

Para configurar las propiedades de usuario más avanzadas como la caducidad de la contraseña, modifique las propiedades del usuario tras añadir el usuario. Remítase a la Sección 33.1.2, “Modificar las propiedades del usuario” para más información.

33.1.2. Modificar las propiedades del usuario

Para ver las propiedades de un usuario ya existente, haga clic en la pestaña Usuarios, seleccione el usuario de la lista de usuarios y haga clic en Propiedades desde el menú (o escoja Fichero = > Propiedades desde el menú desplegable). Aparecerá una ventana parecida a la Figura 33.3, “Propiedades del usuario”.

Propiedades del usuario

Modificar las propiedades del usuario

Figura 33.3. Propiedades del usuario

La ventana Propiedades de los usuarios está dividida en múltiples páginas:

  • Datos de Usuario — Información básica del usuario configurada cuando ha añadido el usuario. Utilice esta pestaña para cambiar el nombre completo del usuario, la contraseña, el directorio principal o la shell de registro.

  • Información de la cuenta Seleccione Activar expiración de cuenta si quiere que la cuenta caduque en una fecha determinada. Introduzca la fecha en los campos pertinentes. Seleccione La cuenta del usuario está bloqueada para bloquear la cuenta de usuario de manera que el usuario no pueda entrar en el sistema.

  • Información de la contraseña — Esta pestaña muestra la fecha en que el usuario cambió la contraseña por última vez. Para hacer que el usuario cambie la contraseña después de unos cuantos días, seleccione Activar expiración de contraseña e introduzca un valor en el campo Días requeridos antes de cambiar. Podrá establecer el número de días antes de que la contraseña del usuario caduque, el número de días previos al aviso al usuario para que cambie su contraseña y los días anteriores a que la cuenta pase a ser inactiva.

  • Grupos — Le permite ver y configurar el Grupo primario del usuario y los otros grupos a los cuales desea que el usuario pertenezca.

33.1.3. Añadir un nuevo grupo

Para añadir un nuevo grupo de usuarios, pulse el botón Añadir Grupo. Aparecerá una ventana parecida a la Figura 33.4, “Nuevo grupo”. Escriba el nombre del nuevo grupo que desea crear. Para especificar un ID de grupo para el nuevo grupo seleccione Especificar el ID de grupo manualmente y seleccione el GID. Red Hat Enterprise Linux reserva los IDs de grupo menores de 500 para los grupos de sistemas.

Nuevo grupo

Crear un nuevo grupo

Figura 33.4. Nuevo grupo

Haga clic en OK para crear el grupo. Aparecerá un grupo nuevo en la lista.

33.1.4. Modificar las propiedades del grupo

Para ver las propiedades de un grupo ya existente, seleccione el grupo desde la lista de grupos y pulse Propiedades desde el menú (o seleccione Archivo => Propiedades desde el menú desplegable). Aparecerá una ventana similar a la Figura 33.5, “Propiedades del grupo”.

Propiedades del grupo

Modificar las propiedades del grupo

Figura 33.5. Propiedades del grupo

La pestaña Usuarios del grupo visualiza qué usuarios son miembros del grupo. Utilice esta pestaña para añadir o borrar usuarios del grupo. Haga clic en OK para guardar las modificaciones.

33.2. Herramientas de administración de usuarios y grupos

La gestión de usuarios y grupos puede llegar a ser una tarea tediosa; es por esto que Red Hat Enterprise Linux proporciona herramientas y convenciones que facilitan su gestión.

La forma más fácil de manejar usuarios y grupos es a través de la aplicación gráfica, Administrador de usuarios (system-config-users). Para obtener mayor información sobre la Administrador de usuarios, consulte la Sección 33.1, “Configuración de grupos y de usuarios”.

Las siguientes herramientas de línea de comandos también se pueden utilizar para manejar usuarios y grupos:

  • useradd, usermod y userdel — Métodos estándar de la industria para añadir, eliminar y modificar cuentas de usuarios.

  • groupadd, groupmod y groupdel — Métodos estándar de la industria para añadir, eliminar y modificar grupos de usuarios.

  • gpasswd — Un comando para administrar el archivo /etc/group.

  • pwck, grpck — Herramientas para la verificación de contraseñas, grupo y archivos shadow asociados.

  • pwconv, pwunconv — Herramientas para la conversión de contraseñas a contraseñas shadow y de vuelta a contraseñas estándar.

33.2.1. Configuración desde la línea de comandos

Si prefiere las herramientas de línea de comandos o no tiene el sistema X Window instalado, use esta sección para configurar usuarios y grupos.

33.2.2. Añadir un usuario

Para añadir un usuario al sistema:

  1. Ejecute el comando useradd para crear una cuenta de usuario bloqueada:

    useradd <nombre-usuario>
    
  2. Desbloquee la cuenta ejecutando el comando passwd para asignar una contraseña y configurar el vencimiento de la misma:

    passwd <nombre-usuario>
    

Las opciones de línea de comandos para useradd están detalladas en la Tabla 33.1, “Opciones de línea de comandos para useradd.

Opciones Descripción
-c '<comentario>' donde <comentario> puede ser cualquier cadena de caracteres. Esta opción es generalmente usada para especificar el nombre completo del usuario.
-d<directorio-principal> El directorio principal a ser usado en vez del directorio predeterminado /home/<nombre-usuario>
-e<fecha> Fecha en que la cuenta será desactivada usando el formato de fecha AAAA-MM-DD
-f<días> Número de días que pasarán después de que la contraseña ha caducado hasta que la cuenta se desactive. Si se especifica 0, la cuenta será desactivada inmediatamente después de que la contraseña expire. Si se especifica -1, la cuenta no se desactivará después de que la contraseña caduque.
-g<nombre-grupo> Nombre o número del grupo para el grupo predeterminado del usuario. El grupo debe existir antes de que sea especificado aquí.
-G<lista-grupos> Lista de nombres de los grupos adicionales (además del predeterminado), separados por comas, de los cuales el usuario es miembro. Los grupos deben existir antes que sea especificado aquí.
-m Crea el directorio principal si no existe
-M No crea el directorio principal.
-n No crea un grupo privado de usuario para el usuario
-r Crea una cuenta de sistema con un UID menor que 500 y sin un directorio principal
-p<contraseña> La contraseña encriptada con crypt
-s Shell de registro del usuario, predeterminada a /bin/bash
-u<uid> ID del usuario, el cual debe ser único y mayor que 499
Tabla 33.1. Opciones de línea de comandos para useradd

33.2.3. Añadir un grupo

Para agregar un grupo al sistema, use el comando groupadd:

groupadd <nombre-grupo>

Las opciones de la línea de comando para groupadd están detalladas en la Tabla 33.2, “Opciones de línea de comando para groupadd.

Opciones Descripción
-g<gid> ID para el grupo, el cual debe ser único y mayor que 499
-r Crea un grupo de sistema con un GID menor que 500
-f Cuando se utiliza con -g<gid> y <gid> ya existe, groupadd escogerá otro <gid> único para el grupo.
Tabla 33.2. Opciones de línea de comando para groupadd

33.2.4. Vencimiento de la contraseña

Por razones de seguridad, se aconseja que los usuarios cambien sus contraseñas periódicamente. Esto se puede realizar añadiendo o editando un usuario en la pestaña Información de la contraseña en la Administrador de usuarios.

Para configurar el vencimiento de la contraseña para un usuario desde el intérprete de comandos, use el comando chage, seguido de una de las opciones de la Tabla 33.3, “Opciones de línea de comando de chage, seguido por el nombre del usuario.

Importante

La contraseña oculta debe estar activada para poder usar el comando chage.

Opciones Descripción
-m<días> Especifica el número mínimo de días entre los cuales el usuario debe cambiar su contraseña. Si el valor es 0, la contraseña no caduca.
-M<días> Especifica el número máximo de días durante los cuales la contraseña es válida. Cuando el número de días especificado por esta opción más el número de días especificado con la opción -d es menor que el día actual, el usuario debe cambiar su contraseña antes de usar la cuenta.
-d<días> Especifica el número de días desde el 1 de enero de 1970 que la contraseña fué cambiada.
-I<días> Especifica el número de días inactivos después de la expiración de la contraseña antes de bloquear la cuenta. Si el valor es 0, la cuenta no es bloqueada después que la contraseña caduca.
-E<fecha> Especifica la fecha en la cual la cuenta es bloqueada, en el formato AAAA-MM-DD. También se puede usar el número de días transcurridos desde el 1 de enero de 1970 en lugar de la fecha.
-W<días> Especifica el número de días antes de la fecha de expiración de la contraseña para advertir al usuario.
Tabla 33.3. Opciones de línea de comando de chage

Sugerencia

Si el comando chage está seguido directamente por un nombre de usuario (sin opciones), mostrará los valores de vencimiento de la contraseña actual y permitirá cambiar estos valores.

Usted puede configurar una contraseña para que caduque la primera vez que el usuario inicie una sesión. Esto obliga al usuario a cambiar la contraseña la primera vez que se registre.

Nota

Este proceso no funcionará si el usuario inicia la sesión a través del protocolo SSH.

  1. Bloquear la contraseña del usuario — Si el usuario no existe, use el comando useradd para crear la cuenta del usuario. No establezca ninguna contraseña para que la cuenta permanezca bloqueada.

    Si la contraseña ya está activa, bloquéela con el comando:

    usermod -L <nombre-usuario>
    
  2. Obligar el vencimiento inmediato de la contraseña — Escriba el comando siguiente:

    chage -d 0 <nombre-usuario>
    

    Este comando coloca el valor para la fecha en que la contraseña fué cambiada la última vez (Enero 1, 1970). Este valor obliga a la expiración inmediata de la contraseña sin tomar en cuenta la política de vencimiento, si existe alguna.

  3. Desbloquear la cuenta — Hay dos formas comunes para realizar este paso. El administrador puede asignar una contraseña inicial o puede asignar una contraseña nula.

    Aviso

    No use passwd para configurar una contraseña porque desactivará el vencimiento inmediato que se acaba de configurar.

    Para asignar una contraseña inicial, siga los pasos siguientes:

    • Arranque el intérprete de Python con el comando python. Se mostrará lo siguiente:

       Python 2.4.3 (#1, Jul 21 2006, 08:46:09) [GCC 4.1.1 20060718 (Red Hat 4.1.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>
      
    • En la línea de comandos, escriba lo siguiente. Reemplace <contraseña> con la contraseña a encriptar y <sal> con una combinación de exáctamente 2 caracteres en mayúsculas o minúsculas, números, el carácter punto (.) o la barra (/):

      import crypt; print crypt.crypt("<contraseña>","<sal>")
      

      La salida es la contraseña encriptada, similar a 12CsGd8FRcMSM.

    • Presione Ctrl-D para salir del intérprete de Python.

    • En la shell, introduzca el siguiente comando (reemplazando <contraseña-encriptada> con el resultado dado en el intérprete de Python):

      usermod -p "<contraseña-encriptada>" <nombre-usuario>
      

    Alternativamente, usted puede asignar una contraseña vacía en vez de la contraseña inicial. Para hacerlo, utilice el siguiente comando:

    usermod -p "" <nombre-usuario>
    

    Atención

    A pesar de que el uso de una contraseña nula es conveniente tanto para el administrador como para el usuario, es una práctica insegura. Un tercero puede conectarse primero y acceder al sistema usando el número de usuario inseguro. Asegúrese de que el usuario está listo para registrarse antes de desbloquear una cuenta con una contraseña vacía.

    En cualquier caso, luego de la conexión inicial, se le pedirá al usuario una nueva contraseña.

33.2.5. Explicación del proceso

Los siguientes pasos describen lo que ocurre si se ejecuta el comando useradd juan en un sistema que tiene contraseñas ocultas activadas:

  1. Se crea una nueva línea para juan en /etc/passwd. La línea tiene las características siguientes:

    • Comienza con el nombre del usuario, juan.

    • Hay una x para el campo de contraseña indicando que el sistema está usando contraseñas ocultas.

    • Se crea un UID igual o mayor que 499. (Bajo Red Hat Enterprise Linux UIDs y GIDs debajo de 500 se reservan para uso del sistema.)

    • Se crea un GID por encima de 499.

    • La información para el GECOS óptimo se deja en blanco.

    • El directorio principal para juan se establece en /home/juan/.

    • El intérprete de comandos predeterminado se establece a /bin/bash.

  2. Se crea una nueva línea para juan en /etc/shadow. La línea tiene las características siguientes:

    • Comienza con el nombre del usuario, juan.

    • Aparecen dos símbolos de exclamación (!!) en el campo de la contraseña del archivo /etc/shadow, lo cual bloquea la cuenta.

      Nota

      Si se pasa una contraseña encriptada usando la opción -p, se colocará en el archivo /etc/shadow en la nueva línea para el usuario.

    • Se configura la contraseña para que no caduque nunca.

  3. Se crea una nueva línea para un grupo llamado juan en /etc/group. Un grupo con el mismo nombre del usuario se conoce como un grupo de usuario privado. Para obtener mayor información sobre los grupos de usuario privados, consulte la Sección 33.1.1, “Añadir un nuevo usuario”.

    La línea creada en /etc/group tiene las características siguientes:

    • Comienza con el nombre del grupo, juan.

    • Aparece una x en el campo de contraseña indicando que el sistema está usando contraseñas de grupo oculta.

    • El GID coincide con el listado para el usuario juan en /etc/passwd.

  4. Se crea una nueva línea para un grupo llamado juan en /etc/gshadow. La línea tiene las siguientes características:

    • Comienza con el nombre del grupo, juan.

    • Aparece un símbolo de exclamación (!) en el campo de contraseña del archivo /etc/gshadow, lo cual bloquea el grupo.

    • Todos los otros campos quedan en blanco.

  5. Se crea un directorio para el usuario juan en el directorio /home/. Este directorio tiene como dueño al usuario juan y al grupo juan. Sin embargo, tiene privilegios para leer, escribir y ejecutar sólo para el usuario juan. Todos los demás permisos son denegados.

  6. Los archivos dentro del directorio /etc/skel/ (el cual contiene la configuración predeterminadas del usuario) se copian en el nuevo directorio /home/juan/.

En este punto, existe una cuenta bloqueada llamada juan en el sistema. Para activarla, el administrador debe asignar una contraseña a la cuenta usando el comando passwd y, opcionalmente, especificar las pautas de vencimiento de la misma.

33.3. Usuarios estándar

Tabla 33.4, “Usuarios estándar” lista los usuarios estándar configurados en el archivo /etc/passwd por una instalación con Todo. El groupid (GID) en esta tabla es el grupo primario para el usuario. Vea la Sección 33.4, “Grupos estándar” para una lista de los grupos estándar.

Usuario UID GID Directorio principal Shell
root 0 0 /root /bin/bash
bin 1 1 /bin /sbin/nologin
daemon 2 2 /sbin /sbin/nologin
adm 3 4 /var/adm /sbin/nologin
lp 4 7 /var/spool/lpd /sbin/nologin
sync 5 0 /sbin /bin/sync
shutdown 6 0 /sbin /sbin/shutdown
halt 7 0 /sbin /sbin/halt
mail 8 12 /var/spool/mail /sbin/nologin
news 9 13 /etc/news
uucp 10 14 /var/spool/uucp /sbin/nologin
operator 11 0 /root /sbin/nologin
games 12 100 /usr/games /sbin/nologin
gopher 13 30 /var/gopher /sbin/nologin
ftp 14 50 /var/ftp /sbin/nologin
nobody 99 99 / /sbin/nologin
rpm 37 37 /var/lib/rpm /sbin/nologin
vcsa 69 69 /dev /sbin/nologin
dbus 81 81 / /sbin/nologin
ntp 38 38 /etc/ntp /sbin/nologin
canna 39 39 /var/lib/canna /sbin/nologin
nscd 28 28 / /sbin/nologin
rpc 32 32 / /sbin/nologin
postfix 89 89 /var/spool/postfix /sbin/nologin
mailman 41 41 /var/mailman /sbin/nologin
named 25 25 /var/named /bin/false
amanda 33 6 var/lib/amanda/ /bin/bash
postgres 26 26 /var/lib/pgsql /bin/bash
exim 93 93 /var/spool/exim /sbin/nologin
sshd 74 74 /var/empty/sshd /sbin/nologin
rpcuser 29 29 /var/lib/nfs /sbin/nologin
nsfnobody 65534 65534 /var/lib/nfs /sbin/nologin
pvm 24 24 /usr/share/pvm3 /bin/bash
apache 48 48 /var/www /sbin/nologin
xfs 43 43 /etc/X11/fs /sbin/nologin
gdm 42 42 /var/gdm /sbin/nologin
htt 100 101 /usr/lib/im /sbin/nologin
mysql 27 27 /var/lib/mysql /bin/bash
webalizer 67 67 /var/www/usage /sbin/nologin
mailnull 47 47 /var/spool/mqueue /sbin/nologin
smmsp 51 51 /var/spool/mqueue /sbin/nologin
squid 23 23 /var/spool/squid /sbin/nologin
ldap 55 55 /var/lib/ldap /bin/false
netdump 34 34 /var/crash /bin/bash
pcap 77 77 /var/arpwatch /sbin/nologin
radiusd 95 95 / /bin/false
radvd 75 75 / /sbin/nologin
quagga 92 92 /var/run/quagga /sbin/login
wnn 49 49 /var/lib/wnn /sbin/nologin
dovecot 97 97 /usr/libexec/dovecot /sbin/nologin
Tabla 33.4. Usuarios estándar

33.4. Grupos estándar

Tabla 33.5, “Grupos estándar” lista los grupos estándar configurados por una instalación con Todo. Los grupos son almacenados en el archivo /etc/group.

Grupo GID Miembros
root 0 root
bin 1 root, bin, daemon
daemon 2 root, bin, daemon
sys 3 root, bin, adm
adm 4 root, adm, daemon
tty 5
disk 6 root
lp 7 daemon, lp
mem 8
kmem 9
wheel 10 root
mail 12 mail, postfix, exim
news 13 news
uucp 14 uucp
man 15
games 20
gopher 30
dip 40
ftp 50
lock 54
nobody 99
usuarios 100
rpm 37
utmp 22
floppy 19
vcsa 69
dbus 81
ntp 38
canna 39
nscd 28
rpc 32
postdrop 90
postfix 89
mailman 41
exim 93
named 25
postgres 26
sshd 74
rpcuser 29
nfsnobody 65534
pvm 24
apache 48
xfs 43
gdm 42
htt 101
mysql 27
webalizer 67
mailnull 47
smmsp 51
squid 23
ldap 55
netdump 34
pcap 77
quaggavt 102
quagga 92
radvd 75
slocate 21
wnn 49
dovecot 97
radiusd 95
Tabla 33.5. Grupos estándar

33.5. Grupos de usuario privado

Red Hat Enterprise Linux utiliza un esquema de grupo privado de usuario (UPG), lo que hace más fácil de manejar los grupos de UNIX.

Se crea un UPG siempre que se añade un nuevo usuario al sistema. Un UPG tiene el mismo nombre que el usuario para el cual se crea y ese usuario es el único miembro de ese UPG.

Los UPGs hacen que sea más seguro configurar los privilegios por defecto para un nuevo archivo o directorio. Esto permite a ambos, tanto al usuario como al grupo de ese usuario hacer modificaciones al archivo o directorio.

El parámetro que determina qué permisos son aplicados a un nuevo archivo o directorio es llamado un umask y se configura en el archivo /etc/bashrc. Tradicionalmente en sistemas UNIX, el umask es configurado a 022, lo que sólo permite al usuario que creó el archivo o directorio realizar modificaciones. Bajo este esquema, todos los demás usuarios incluyendo miembros del grupo del creador no tienen derecho a realizar ninguna modificación. Sin embargo, bajo el esquema UPG, esta "protección de grupo" no es necesaria puesto que cada usuario tiene su propio grupo privado.

33.5.1. Directorios de grupos

Muchas organizaciones de Tecnologías de Información prefieren crear un grupo para cada proyecto importante y luego asignar personas al grupo si estos necesitan acceso a los archivos de ese proyecto. Usando este esquema tradicional, el manejo de archivos ha sido difícil pues cuando alguien crea un archivo, este es asociado con el grupo primario al cual ellos pertenecen. Cuando una persona individual trabaja en múltiples proyectos, se hace difícil asociar los archivos correctos con el grupo correcto. Usando el esquema UPG, sin embargo, los grupos son automáticamente asignados a archivos creados dentro de un directorio con el bit setgid configurado. El bit setgid hace muy simple el manejo de proyectos de grupos que comparten un directorio común, pues cualquier archivo creado dentro del directorio es propiedad del grupo que posee el directorio.

Digamos, por ejemplo, que un grupo de personas trabajan con archivos en el directorio /usr/lib/emacs/site-lisp/. Algunas personas son de confianza y pueden modificar el directorio, pero ciertamente no todos. Entonces, primero cree un grupo emacs, como se muestra en el siguiente comando:

/usr/sbin/groupadd emacs

Para asociar los contenidos del directorio con el grupo emacs, escriba:

chown -R root.emacs /usr/share/emacs/site-lisp

Ahora es posible añadir los usuarios adecuados al grupo con el comando gpasswd:

/usr/bin/gpasswd -a <nombre-usuario> emacs

Para permitir que los usuarios creen archivos dentro del directorio, utilice el comando siguiente:

chmod 775 /usr/share/emacs/site-lisp

Cuando un usuario crea un nuevo archivo, se le asigna el grupo del grupo por defecto privado del usuario. Luego, configure el bit setgid, el cual asigna que todo lo que se cree en el directorio la misma permisología de grupo del directorio mismo (emacs). Use el comando siguiente:

chmod 2775 /usr/share/emacs/site-lisp

En este punto, puesto que cada usuario tiene por defecto su umask en 002, todos los miembros del grupo emacs pueden crear y modificar archivos en el directorio /usr/lib/emacs/site-lisp/ sin que el administrador tenga que cambiar los permisos de los archivos cada vez que un usuario escriba nuevos archivos.

33.6. Contraseñas Shadow

En entornos multiusuario es muy importante utilizar contraseñas shadow también conocido como Oscurecimiento de contraseñas, (proporcionadas por el paquete shadow-utils). Haciendo esto se mejora la seguridad de los archivos de autenticación del sistema. Por esta razón, el programa de instalación activa por defecto las contraseñas shadow.

Lo siguiente es una lista de las ventajas de las contraseñas shadow sobre el método tradicional de almacenar contraseñas en los sistemas basados en UNIX:

  • Mejora la seguridad del sistema al mover las contraseñas encriptadas desde el archivo /etc/passwd que puede leer todo el mundo, a /etc/shadow, el cual sólo puede ser leído por el usuario root.

  • Almacena información sobre la vigencias de las contraseñas.

  • Permite el uso del archivo /etc/login.defs para reforzar las políticas de seguridad.

La mayoría de las utilidades proporcionadas por el paquete shadow-utils funcionan adecuadamente sin importar si las contraseñas shadow están activadas o no. Sin embargo, puesto que la información sobre la vigencia de las contraseñas es almacenada exclusivamente en el archivo /etc/shadow, cualquier comando que cree o modifique la información sobre la vigencia de las contraseñas, no funcionará.

Abajo se muestra una lista de los comandos que no funcionan a menos que se activen primero las contraseñas shadow:

  • chage

  • gpasswd

  • Las opciones /usr/sbin/usermod-e o -f

  • Las opciones /usr/sbin/useradd-e o -f

33.7. Recursos adicionales

Para más información sobre usuarios y grupos y las herramientas para administrarlos, consulte los recursos siguientes.

33.7.1. Documentación instalada

  • Páginas man relacionadas — Hay varias páginas man para las diferentes aplicaciones y archivos de configuración relacionados con el manejo de usuarios y grupos. La siguiente es una lista de algunas de las páginas más importantes:

    Aplicaciones administrativas de usuarios y grupos
    • man chage — Un comando para modificar las políticas de vigencia y expiración de las cuentas.

    • man gpasswd — Un comando para administrar el archivo /etc/group.

    • man groupadd — Un comando para añadir grupos.

    • man grpck — Un comando para verificar el archivo /etc/group.

    • man groupdel — Un comando para eliminar grupos.

    • man groupmod — Un comando para modificar la membrecía de grupos.

    • man pwck — Comando que se utiliza para verificar los archivos /etc/passwd y /etc/shadow.

    • man pwconv — Una herramienta para la conversión de contraseñas estándar a contraseñas shadow.

    • man pwunconv — Una herramienta para la conversión de contraseñas shadow a contraseñas estándar.

    • man useradd — Un comando para añadir usuarios.

    • man userdel — Un comando para eliminar usuarios.

    • man usermod — Comando para modificar usuarios.

    Archivos de configuración
    • man 5 group — El archivo que contiene información del grupo para el sistema.

    • man 5 passwd — El archivo que contiene información del usuario para el sistema.

    • man 5 shadow — El archivo que contiene información de contraseñas y vigencia de cuentas para el sistema.

Capítulo 34. Configuración de la impresora

La Herramienta de configuración de la impresora permite a los usuarios configurar una impresora. Esta herramienta ayuda a mantener el archivo de configuración de la impresora, los directorios spool de impresión y los filtros de impresión.

Red Hat Enterprise Linux 5.2 uses the Common Unix Printing System (CUPS). If a system was upgraded from a previous Red Hat Enterprise Linux version that used CUPS, the upgrade process preserves the configured queues.

Para usar la Herramienta de configuración de la impresora debe tener privilegios como root. Para iniciar la aplicación, seleccione System (on the panel) => Administración => Imprimir, o escriba el comando system-config-printer en el intérprete de comandos de shell.

Herramienta de configuración de la impresora

Ventana principal

Figura 34.1. Herramienta de configuración de la impresora

Se pueden configurar los siguientes tipos de colas de impresión:

  • AppSocket/HP JetDirect — una impresora conectada directamente a la red a través de HP JetDirect o la interfaz Appsocket en vez de a un computador.

  • Internet Printing Protocol (IPP) — una impresora que puede ser accesada sobre una red TCP/IP a través del protocolo de impresión por Internet (por ejemplo, una impresora conectada a otro sistema Red Hat Enterprise Linux ejecutando CUPS en la red).

  • LPD/LPR Host or Printer — una impresora conectada a un sistema UNIX diferente que se puede acceder sobre una red TCP/IP (por ejemplo, una impresora conectada a otro sistema Red Hat Enterprise Linux ejecutando LPD en la red).

  • Networked Windows (SMB) — una impresora conectada a un sistema diferente que está compartiendo una impresora sobre una red SMB (por ejemplo, una impresora conectada a una máquina Microsoft Windows™).

  • Networked JetDirect — una impresora connectada directamente a la red a través de HP JetDirect en vez de a un computador.

Importante

Si agrega una nueva cola de impresión o modifica una existente, usted debe aplicar los cambios para que éstos tomen efecto.

Al hacer click en el botón Aplicar le pide al demonio de impresión que reinicie con los cambios que ha configurado.

Haga click en Cancelar para que descarte los cambios aún por aplicar.

34.1. Añadir una impresora local

Para añadir una impresora local, tal como una conectada al puerto paralelo o USB en su computador, haga click en Nuevo en la ventana principal de la Configuración de la Impresora para que aparezca la ventana en la Figura 34.2, “Añadir una Impresora.

Añadir una Impresora

Añadir una impresora

Figura 34.2. Añadir una Impresora

Haga click en el botón Siguiente para continuar.

Introduzca un nombre único para la impresora en el campo de texto Nombre. El nombre de la impresora puede tener letras, números, guiones (-), y rayas (_), no debe tener ningún espacio.

También puede utilizar los campos Descripción y Ubicación para distinguir esta impresora de las otras que también puedan encontrarse configuradas en su sistema. Amos campos son opcionales y muchos incluyen espacios.

Haga click en Adelante para abrir el diálogo Nueva Impresora (refiérase a Figura 34.3, “Añadir una impresora local”). Si se ha detectado automáticamente la impresora el modelo aparecerá en Seleccionar Conexión. Seleccione el modelo de la impresora y haga click en Adelante para continuar.

Si el dispositivo no aparece automáticamente seleccione el dispositivo al cual se encuentra conectada la impresora (tal como LPT #1 o Serial Port #1) en Select Connection.

Añadir una impresora local

Añadir una impresora local

Figura 34.3. Añadir una impresora local

El próximo paso es seleccionar el tipo de impresora. Vaya a la Sección 34.5, “Selección del modelo de impresora” para obtener más detalles.

34.2. Añadir una impresora de red IPP

Una impresora IPP es una impresora conectada a un sistema diferente en la misma red TCP/IP. El sistema al cual esta impresora está conectada puede estar ejecutando CUPS o estar simplemente configurada para utilizar IPP.

Si tiene un cortafuegos configurado en el servidor de impresión, éste debe ser capaz de enviar y recibir conexiones en el puerto UDP, 631. Si tiene un cortafuego configurado en el cliente (el computador enviando la petición de impresión), éste debe poder enviar y aceptar conexiones en el puerto 631.

Puede añadir una impresora IPP en red haciendo click en el botón Impresora Nueva en la ventana principal Herramienta de configuración de la impresora para visualizar la ventana en Figura 34.2, “Añadir una Impresora. Ingrese el Nombre de Impresora (los nombres de la impresora no pueden tener espacios pero si puden incluir letras, números, guiones (-) y rayas(_)), Descripción, y Ubicación para distinguir esta impresora de las otras que se encuentran en su sistema. Haga click en Adelante para proceder.

En la ventana que aparece en Figura 34.4, “Añadir una impresora de red IPP” ingrese el nombre del host de la impesora IPP en el campo Nombre de Host así como un nombre único para la impresora en el campo Nombre de Impresora.

Añadir una impresora de red IPP

Impresora de red IPP

Figura 34.4. Añadir una impresora de red IPP

Haga clic en el botón Siguiente para continuar.

El próximo paso es seleccionar el tipo de impresora. Vaya a la Sección 34.5, “Selección del modelo de impresora” para obtener más detalles.

34.3. Añadir una impresora Samba (SMB)

Puede añadir un recurso compartido de la impresora basada en Samba (SMB) haciendo click en el botón Nueva Impresora en la ventana principal Herramienta de configuración de la impresora para visualizar la ventana en Figura 34.2, “Añadir una Impresora. Ingrese un nombre único para la impresora en el campo Nombre de Impresora. Este nombre puede incluir letras, números, guiones (-) y rayas (_), no debe incluir ningún espacio.

También puede utilizar los campos Descripción y Ubicación para distinguir esta impresora de las otras que también puedan encontrarse configuradas en su sistema. Amos campos son opcionales y muchos incluyen espacios.

Añadir una impresora SMB

Impresora SMB

Figura 34.5. Añadir una impresora SMB

Como aparece en Figura 34.5, “Añadir una impresora SMB” los recursos compartidos SMB son detectados automáticamente y son enumeradas en la columna Recurso Compartido. Haga clic en la flecha ( ) al lado de Grupo de Trabajo para expandirlo. Seleccione una impresora de esta lista.

Si la impresora que está buscando no se encuentra en la lista ingrese la dirección SMB en el campo smb://. Utilice el formato nombre de computador/recurso compartido de impresora. En Figura 34.5, “Añadir una impresora SMB”, el nombre de computador es dellbox mientras que el recurso compartido de impresora es r2.

En el campoNombre de usuario ingrese el nombre de usuario para acceder a la impresora. Este usuario debe existir en el sistema SMB y el usuario debe tener permiso para acceder a la impresora. El nombre de usuario predeterminado es típicamente guest para los servidores Windows, o nobody para los servidores Samba.

Ingrese la Contraseña (si se necesita) para el usuario especificado en el campo Nombre de usuario.

Puede probar la conexión haciendo click en Verificar. Si la verificación es exitosa aparecerá un diálogo confirmando la accesibilidad a los recursos compartidos de la impresora.

El próximo paso es seleccionar el tipo de impresora. Vaya a la Sección 34.5, “Selección del modelo de impresora” para obtener más detalles.

Aviso

Los nombres de usuarios y las contraseñas de la impresora Samba se encuentran almacenados en el servidor de la impresora como archivos encriptados que root y lpd pueden leer. Por lo tanto, los otros usuarios que tienen acceso root al servidor de la impresora pueden ver el nombre de usuario y la contraseña que usted utiliza para acceder a la impresora Samba.

Como tal, cuando escoje un nombre de usuario y una contraseña para acceder a la impresora Samba se le aconseja que escoja una contraseña diferente de la que utiliza para acceder a su sistema Red Hat Enterprise Linux local.

Si hay archivos compartidos en el servidor de la impreso Samba se recomienda que también utilicen una contraseña diferente de la que utiliza la fila de impresión.

34.4. Añadir una Impresora JetDirect

Para agregar una impresora JetDirect o un recurso compartido de impresora conectado a AppSocket haga click en el botón Impresora Nueva en la ventana principal de la Herramienta de configuración de la impresora para que aparezca la ventana en Figura 34.2, “Añadir una Impresora. Ingrese un nombre único para la impresora en el campo Nombre de Impresora. El nombre de la impresora puede tener letras, números, guiones (-) y rayas(_). No debe contener ningún espacio.

También puede utilizar los campos Descripción y Ubicación para distinguir esta impresora de las otras que también puedan encontrarse configuradas en su sistema. Amos campos son opcionales y muchos incluyen espacios.

Añadir una Impresora JetDirect

Añadir una impresora JetDirect

Figura 34.6. Añadir una Impresora JetDirect

Haga clic en el botón Siguiente para continuar.

Aparecerán los campos de texto para las siguientes opciones:

  • Hostname — El nombre del host o la dirección IP de la impresora JetDirect.

  • Número de Puerto — El puerto en la impresora JetDirect que está escuchando por trabajos de impresión. El puerto predeterminado es 9100.

El próximo paso es seleccionar el tipo de impresora. Vaya a la Sección 34.5, “Selección del modelo de impresora” para obtener más detalles.

34.5. Selección del modelo de impresora

Una vez que haya escojido el tipo de cola de impresión apropiada puede escoger cualquier opción:

  • Seleccione una impresora de la base de datos - Si escoje esta opción, seleccione la marca de su impresora de la lista de Marcas. Si la marca de su impresora no se encuentra en esa lista, seleccione Genérico.

  • Proporcione un archivo PPD - También se puede proporcionar un archivo PPD (PostScript Printer Description) con su impresora. Normalmente, este archivo lo proporciona el fabricante. Si se le proporciona un archivo PPD puede escoger esta opción y utilizar la barra del navegador debajo de la descripción de la opción para seleccionar el archivo PPD.

Vaya a la Figura 34.7, “Selección del modelo de impresora” para obtener más detalles.

Selección del modelo de impresora

Selección del modelo de impresora

Figura 34.7. Selección del modelo de impresora

Después de escoger una opción, haga click en Forward para continuar. Apareccerá Figura 34.7, “Selección del modelo de impresora”. Escoja el modelo y el controlador correspondiente para la impresora.

El controlador de la impresora recomendado es escogido automáticamnete con base en el modelo de impresora seleccionado. El controlador de la impresora procesa los datos que desea imprimir en un formato que la impresora puede entender. Puesto que hay una impresora local conectada a su computador, necesita un controlador de impresora para procesar los datos que se envian a la misma.

Si tiene un archivo PPD para el dispositivo (usualmente el fabricante lo proporciona) puede seleccionarlo al escoger Proveer archivo PPD. Después puede buscar el archivo PPD en el sistema de archivos haciendo click en Buscar.

34.5.1. Confirmación de la configuración de la impresora

El último paso es confirmar la configuración de su impresora. Haga click en Aplicar para agregar la cola de impresión si las configuraciones son correctas. Haga click en Anterior para modificar la configuración de la impresora.

Después de aplicar los cambios imprima una página de prueba para asegurarse de que la configuración es correcta. Refiérase a la Sección 34.6, “Imprimiendo una página de prueba” para más detalles.

34.6. Imprimiendo una página de prueba

Después de haber configurado su impresora, debería imprimir una página de prueba para asegurarse de que su impresora funciona perfectamente. Para imprimir una página de prueba, seleccione la impresora que desea probar de la lista de impresoras, luego haga click en Imprimir Página de Pruebade la pestaña Configuración de la impresora.

Si cambia el controlador de la impresora o modifica las opciones de la impresora, debería imprimir una página de prueba para verificar la nueva configuración.

34.7. Modificar impresoras existentes

Para borrar una impresora existente, seleccione la impresora y haga click en el botón Eliminar en la barra de herramientas. La impresora será eliminada de la lista de impresoras una vez lo confirme.

Para configurar la impresora predeterminada, seleccionela de la lista de impresoras y haga click en el botón Establecer como predeterminada en la pestaña Configuración.

34.7.1. La pestaña Configuración

Para cambiar la configuración del controlador de la impresora haga click en el nombre correspondiente en la lista Impresora y haga click en la pestaña Configuración.

Puede modificar la configuración de la impresora como por ejemplo la marca y el modelo, también puede cambiar la impresora predeterminada, puede imprimir una página de prueba, cambiar la ubicación de la ubicación del dispositivo y mucho más.

Pestaña de Configuración

Pestaña de Configuración

Figura 34.8. Pestaña de Configuración

34.7.2. La pestaña Políticas

Para cambiar la configuración en la salida de la impresora haga click en la pestaña Políticas.

Por ejemplo, para crear un mensaje (una página que describe las características del trabajo de impresión tal como la impresora desde donde se originó el trabajo y el nivel de seguridad del documento que se está imprimiendo) haga click en el menú desplegable Mensaje de Inicio o Mensaje de Finalización y seleccione la opción que mejor describe la naturaleza de los trabajos impresos (tal como secreto, clasificado, o confidencial).

Pestaña Políticas

Pestaña Políticas

Figura 34.9. Pestaña Políticas

También puede configurar la Política de Error de la impresora seleccionando una opción del menú desplegable. Tiene la opción de parar la tarea de impresión, re intentarla o pararla.

34.7.3. La Pestaña Control de Acceso

Puede cambiar el acceso a nivel de usuario de la impresora configurada haciendo click en la pestaña Control de Acceso.

Añada usuarios utilizando la casilla y haga click en el botón Añadir junto a esta. Luego tendrá la opción de permitirle el uso de la impresora sólamente a ese subgrupo de usuarios o denegar el uso a esos usuarios.

Pestaña de Control de Acceso

Pestaña de Control de Acceso

Figura 34.10. Pestaña de Control de Acceso

34.7.4. Las pestañas Opciones de la Impresora y Opciones de Trabajo

La pestaña Opciones de la Impresora tiene varias opciones de configuración para el medio y la salida de la impresora.

Pestaña de las Opciones de la Impresora

Pestaña de Trabajos de la Impresora

Figura 34.11. Pestaña de las Opciones de la Impresora

  • Tamaño del papel — le permite seleccionar el tamaño del papel. Las opciones incluyen Carta US, Legal, A3, y A4.

  • Fuente de medios — por defecto está configurado como Automático. Cambie esta opción para utilizar papel de una bandeja diferente.

  • Tipo de Medios — Le permite cambiar el tipo de papel. La opciones incluyen: simple, grueso, bond y transparente.

  • Resolución — Configure la calidad y el nivel de detalle de la impresión. Por defecto es 300 puntos por pulgada (dpi)).

  • Ahorro de Tóner — Seleccione si quiere que la impresora utilice menos tóner para ahorrar recursos.

También puede configurar las opciones de trabajo de la impresora utilizando la pestaña Opciones de Trabajo. Utilice el menú desplegable y seleccione las opciones de trabajo que desea utilizar tal como el modo de Formato Horizontal (impresión horizontal o vertical), copias, o escala (aumentar o disminuir el tamaño del área de impresión, la cual se puede utilizar para hacer caber un área de impresión demasiado grande en una hoja de papel más pequeña).

34.8. Administración de trabajos de impresión

Cuando usted envía un trabajo de impresión al demonio de impresión, tal como imprimir un archivo de texto desde Emacs o imprimir una imagen desde El GIMP, el trabajo de impresión es añadido al spool de la cola de impresión. El spool de la cola de impresión es una lista de los trabajos de impresión que han sido enviados a la impresora e información acerca de cada petición de impresión, tal como el estado de la petición, el número de trabajo, etc.

Durante el proceso de impresión, el ícono del Status de la Impresora aparece el Area de Notificación en el panel. Para verificar el status de un trabajo de impresión haga doble click en Status de la Impresora, el cual presentará una ventana similar a Figura 34.12, “Status de Impresión GNOME”.

Status de Impresión GNOME

Status de Impresión GNOME

Figura 34.12. Status de Impresión GNOME

Para cancelar un trabajo específico de impresión listado en el Status de impresión GNOME selecciónelo de la lista y pulse Modificar => Cancelar Documentos desde el menú desplegable.

Para ver una lista de los trabajos de impresión en el spool de impresión desde el intérprete de comandos escriba el comando lpq. Las últimas pocas líneas serán similares a lo siguiente:

Rank   Owner/ID              Class  Job Files       Size Time 
active user@localhost+902    A      902 sample.txt  2050 01:20:46
Ejemplo 34.1. Ejemplo de salida de lpq

Si desea cancelar un trabajo de impresión, encuentre el número del trabajo de la petición con el comando lpq y luego use el comando lprm número de trabajo. Por ejemplo, lprm 902 cancelará el trabajo en Ejemplo 34.1, “Ejemplo de salida de lpq. Debe tener los permisos adecuados para poder cancelar un trabajo de impresión. Usted no puede cancelar trabajos de impresión que fueron iniciados por otros usuarios a menos de que usted se haya conectado como root en la máquina a la cual la impresora se encuentra conectada.

También puede imprimir un archivo directamente desde el intérprete de comandos. Por ejemplo, el comando lpr sample.txt imprimirá el archivo de texto sample.txt. El filtro de impresión determina qué tipo de archivos es y lo convierte a un formato de impresión que la impresora pueda entender.

34.9. Recursos adicionales

Para saber un poco más sobre la impresión en Red Hat Enterprise Linux, puede consultar los recursos siguientes.

34.9.1. Documentación instalada

  • map lpr — La página del manual para el comando lpr que le permite imprimir archivos desde la línea de comandos.

  • man lprm — La página del manual para la utilidad de línea de comandos utilizada para eliminar los trabajos de impresión desde la cola de impresión.

  • man mpage — La página del manual para la utilidad de línea de comandos para imprimir múltiples páginas en una hoja de papel.

  • man cupsd — La página del manual para el demonio de impresión CUPS.

  • man cupsd.conf — La página del manual para el archivo de configuración del demonio de impresión CUPS.

  • man classes.conf — La página del manual para el archivo de configuración de clases para CUPS.

34.9.2. Sitios Web de utilidad

  • http://www.linuxprinting.orgGNU/Linux Printing contiene una gran cantidad de información sobre la impresión en Linux.

  • http://www.cups.org/ — Documentación, lista de preguntas más frecuentes (FAQs) y grupos de noticias sobre CUPS.

Capítulo 35. Tareas automáticas

En Linux, las tareas pueden configurarse para que se ejecuten de forma automática en un período de tiempo concreto y en las fechas indicadas o cuando el promedio de carga del sistema está por debajo de un número dado. Red Hat Enterprise Linux es preconfigurado para ejecutar determinadas tareas del sistema de modo que éste se mantenga actualizado. Por ejemplo, la base de datos slocate utilizada por el comando locate,se actualiza diariamente. Un administrador del sistema puede utilizar las tareas automáticas para realizar copias de seguridad periódicas, controlar el sistema y ejecutar scripts personalizados, entre otras tareas.

Red Hat Enterprise Linux contiene varias utilidades de tareas automáticas: cron, at y batch.

35.1. Cron

Cron es un demonio que sirve para ejecutar tareas programadas según una combinación de la hora, día del mes, mes, día de la semana y semana.

Cron asume que el sistema está encendido de forma continua. Si el sistema no está activo cuando está programada una tarea, Cron no se ejecuta. Para programar tareas que se ejecutan una sola vez, consulte la Sección 35.2, “At y Batch”.

Para usar el servicio cron, debe de tener el paquete RPM vixie-cron instalado y el servicio crond debe estar en funcionamiento. Para determinar si el paquete está instalado, use el comando rpm -q vixie-cron. Para determinar si el servicio está funcionando, utilice el comando /sbin/service crond status.

35.1.1. Configuración de una tarea Cron

El fichero de configuración principal de cron, /etc/crontab, contiene las líneas siguientes:

SHELL=/bin/bash 
PATH=/sbin:/bin:/usr/sbin:/usr/bin 
MAILTO=root HOME=/  
# run-parts 
01 * * * * root run-parts /etc/cron.hourly 
02 4 * * * root run-parts /etc/cron.daily 
22 4 * * 0 root run-parts /etc/cron.weekly 
42 4 1 * * root run-parts /etc/cron.monthly

Las primeras cuatro líneas son variables usadas para configurar el entorno en el cual se ejecutan las tareas cron. El valor de la variable SHELL indica al sistema el entorno de shell que deberá utilizarse (en este ejemplo, el shell de bash) y la variable PATH define la ruta usada para ejecutar los comandos. El resultado de las tareas cron se envía por correo electrónico al nombre de usuario definido con la variable MAILTO. Si la variable MAILTO se define como una cadena vacía (MAILTO=""), no se enviará correo electrónico. La variable HOME puede utilizarse para establecer el directorio principal que deberá usarse al ejecutar los comandos o scripts.

Cada línea del archivo /etc/crontab representa una tarea y tiene el formato siguiente:

minuto   hora   día   mes   díaDeLaSemana   comando
  • minute — número entero entre 0 y 59

  • hour — número entero entre 0 y 23

  • day — número entero entre 1 y 31 (debe ser un día válido si se especifica un mes)

  • month — número entero entre 1 y 12 (o nombre corto del mes, por ejemplo, ene, feb, etc.)

  • dayofweek — número entero entre 0 y 7, donde 0 o 7 corresponde a Domingo (o el nombre corto del día de la semana, por ejemplo, dom, lun, etc.)

  • command — el comando a ejecutar (el comando puede ser un comando propiamente dicho como ls /proc >> /tmp/proc o el comando para ejecutar un script personalizado.)

En cualquiera de los valores antes indicados, se puede utilizar un asterisco (*) para especificar todos los valores válidos. Por ejemplo, un asterisco para el valor de mes significa que el comando se ejecutará cada mes dentro de las limitaciones del resto de los valores.

Un guión (-) entre los números enteros indica un intervalo de números enteros. Por ejemplo, 1-4 significa los números enteros 1, 2, 3 y 4.

Una lista de valores separados por comas (,) especifica una lista. Por ejemplo, 3, 4, 6, 8 indica esos cuatro números enteros.

La barra oblícua (/) puede utilizarse para especificar valores de salto. El valor de un número entero se puede saltar dentro de un rango si se indica a continuación del rango con /<número entero>. Por ejemplo, 0-59/2 puede usarse para definir cada otro minuto en el campo minuto. Los valores de salto también pueden utilizarse con un asterisco. Por ejemplo, el valor */3 puede usarse en el campo de mes para ejecutar la tarea cada tercer mes.

Las líneas que empiezan por almohadilla o símbolo numeral (#) son comentarios y no se procesan.

Como se muestra en el archivo /etc/crontab, el script run-parts ejecuta los scripts en los directorios /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, y /etc/cron.monthly cada hora, diariamente, semanalmente o mensualmente, respectivamente. Los archivos en estos directorios deben ser scripts de shell.

Si las tareas cron deben ejecutarse según una programación distinta a la hora, día, semana o mes, esto puede agregarse en el directorio /etc/cron.d. Todos los ficheros de este directorio utilizan la misma sintaxis que /etc/crontab. Vaya al Ejemplo 35.1, “Ejemplos de Crontab” para ver más ejemplos.

# Registra el uso de memoria del sistema cada lunes  
# a las 3:30AM en el archivo /tmp/meminfo 
30 3 * * mon cat /proc/meminfo >> /tmp/meminfo 
# Ejecuta el script personalizado el primer día de cada mes a las 4:10AM 
10 4 1 * * /root/scripts/backup.sh
Ejemplo 35.1. Ejemplos de Crontab

Los usuarios no root pueden configurar las tareas cron tasks con la utilidad crontab. Todos los crontabs definidos por el usuario se almacenan en el directorio /var/spool/cron y se ejecutan utilizando los nombres de los usuarios que los han creado. Para crear un crontab como un usuario, inicie la sesión como ese usuario y escriba el comando crontab -e para modificar el crontab del usuario con el editor especificado por la variable de entorno VISUAL o EDITOR. El fichero usa el mismo formato que /etc/crontab. Cuando se guardan los cambios en crontab, el crontab se almacena según el nombre de usuario, y se escribe en el fichero /var/spool/cron/username.

El demonio cron controla el fichero etc/crontab, el directorio etc/cron.d/ y el directorio /var/spool/cron cada minuto para cada cambio. Si se encuentra algún cambio, estos se cargan en la memoria. De este modo, el demonio no necesita ser reiniciado si se cambia un fichero crontab.

35.1.2. Control de acceso a Cron

Los ficheros /etc/cron.allow y /etc/cron.deny se usan para restringir el acceso a cron. El formato de los dos ficheros de acceso es un nombre de usuario en cada línea. No está permitido espacio en blanco en ninguno de los ficheros. El demonio cron (crond) no deberá ser reiniciado si los ficheros de control de acceso se modifican. Los ficheros de control de acceso se leen cada vez que el usuario intenta añadir o borrar una tarea cron.

El usuario root puede utilizar siempre cron, sin prestar atención a los nombres de usuarios listados en los ficheros de control de acceso.

Si existe el fichero cron.allow, tan sólo se permitirá a los usuarios presentes en la lista utilizar cron y el fichero cron.deny se ignorará.

Si cron.allow no existe, a todos los usuarios listados en cron.deny no se les permite usar cron.

35.2. At y Batch

Mientras que cron es utilizado para programar tareas recurrentes, el comando at se usa para programar una única tarea en un tiempo específico. El comando batch se usa para programar que se ejecute una única tarea cuando la carga promedio de los sistemas esten por debajo de 0.8.

Para poder usar at o batch debe tener el paquete RPM at instalado y el servicio atd en funcionamiento. Para determinar si el paquete está instalado, utilice el comando rpm -q at. Para determinar si el servicio se está ejecutando,utilice el comando /sbin/service atd status.

35.2.1. Configuración de tareas

Para programar una tarea no repetitiva en un tiempo específico, escriba el comando at time, en el que time es el tiempo para ejecutar el comando.

El argumento time puede ser uno de los siguientes:

  • Formato HH:MM — Por ejemplo,04:00 señala las 4:00AM. Si se inserta el tiempo, se ejecuta en la hora específica del siguiente día.

  • midnight — Especifica 12:00 a.m.

  • noon — Especifica 12:00 p.m.

  • teatime — Especifica las 4:00 p.m.

  • Formato del nombre-mes, día y año — Por ejemplo, Enero 15 del año 2002. El año es opcional.

  • Formato MMDDYY, MM/DD/YY, o MM.DD.YY — Por ejemplo, 011502 para el día 15 de Enero del 2002.

  • now + time — el tiempo está en minutos, horas, días o semanas. Por ejemplo, now + 5 días, especifica que el comando debería ser ejecutado a la misma hora en 5 días.

La hora debe ser especificada en primer lugar, seguido por la fecha opcional. Para más información sobre el formato del tiempo, lea el fichero del texto /usr/share/doc/at-<version>/timespec.

Tras haber escrito el comando at con el argumento del tiempo, el prompt at> será visualizado. Escriba el comando a ejecutar, pulse Intro y escriba Ctrl-D. Se puede especificar más de un comando escribiendo cada comando seguido de la tecla Intro. Después de haber escrito todos los comandos, pulse Intro para obtener una línea en blanco y escriba Ctrl-D. Alternativamente, se puede introducir un script de shell en el intérprete de comandos y escribir Ctrl-D en una línea en blanco para salir. Si se introduce un script, la configuración de la shell usada será la configuración de la shell en la SHELL del usuario, la shell de registro del usuario o /bin/sh (el primero que se encuentre).

Si la configuración de comandos o el script intentan visualizar información, la salida de datos será enviada vía correo electrónico al usuario.

Use el comando atq para visualizar los trabajos pendientes. Remítase a la Sección 35.2.3, “Visualización de las tareas pendientes” para más información.

El uso del comando at puede ser restringido. Remítase a la Sección 35.2.5, “Control de acceso a At y Batch” para más detalles.

35.2.2. Configuración de tareas Batch

Para ejecutar una tarea no repetitiva cuando el promedio de carga está por debajo de 0.8, utilice el comando batch.

Tras haber escrito el comando batch, se visualiza el intérprete de comandos at>. Escriba el comando a ejecutar, pulse Intro y escriba Ctrl-D. Se puede especificar más de un comando al escribir cada comando seguido de la tecla Intro. Tras haber escrito todos los comandos, pulse Intro para acceder a una línea en blanco y escriba Ctrl-D. Se puede introducir de forma alternativa un script de shell en el intérprete de comandos y escribir Ctrl-D en una línea en blanco para salir. Si se introduce un script, la shell usada es la configuración de la she en el entorno SHELL del usuario, la shell de login del usuario, o /bin/sh (todo lo que se encuentre en primer lugar). Tan pronto como el promedio de carga está bajo 0.8, se ejecutará la configuración del comando o el script.

Si la configuración de comandos o el script intentan visualizar información, la salida de datos será enviada vía correo electrónico al usuario.

Use el comando atq para visualizar los trabajos pendientes. Remítase a la Sección 35.2.3, “Visualización de las tareas pendientes” para más información.

El uso del comando batch puede ser restringido. Remítase a la Sección 35.2.5, “Control de acceso a At y Batch” para más detalles.

35.2.3. Visualización de las tareas pendientes

Para visualizar las tareas pendientes at y batch, use el comando atq. Muestra una lista de las tareas pendientes, con cada trabajo en una línea. Cada línea sigue el formato de número de tarea, la fecha, la hora, el tipo de tarea y nombre de usuario. Los usuarios tan sólo pueden ver sus propias tareas. Si el usuario root ejecuta el comando atq, se visualizarán todas las tareas de todos los usuarios.

35.2.4. Opciones adicionales de la línea de comandos

Opciones adicionales de la línea de comandos para at y batch incluyen:

Opciones Descripción
-f Lee los comandos o script del shell desde un archivo en vez de ser especificados en el intérprete de comandos.
-m Envía un email al usuario cuando se ha completado la tarea.
-v Muestra la hora en la que la tarea será ejecutada.
Tabla 35.1. Opciones de línea de comandos at y batch

35.2.5. Control de acceso a At y Batch

Los ficheros /etc/at.allow y /etc/at.deny pueden ser usados para restringir el acceso a los comandos at y batch. El formato de ambos ficheros de control de acceso es un nombre de usuario en cada línea. El espacio en blanco no está permitido en ningún fichero. El (atd) demonio at no deberá ser reiniciado si los ficheros de control de acceso son modificados. Los ficheros de control de acceso se leen cada vez que un usuario intenta ejecutar los comandos at y batch.

El usuario root siempre puede ejecutar los comandos at y batch, sin tener en cuenta los ficheros de control de acceso.

Si existe el fichero at.allow tan sólo se permitirá a los usuarios listados usar at o batch y el fichero at.deny será ignorado.

Si at.allow no existe, a los usuarios listados en at.deny no se les permitirá usar at o batch.

35.3. Recursos adicionales

Para obtener más información sobre cómo configurar tareas automáticas, consulte los recursos siguientes.

35.3.1. Documentación instalada

  • Página del manual decron — descripción general de cron.

  • Páginas del manual de crontab en las secciones 1 y 5 — la página del manual de la sección 1 contiene una descripción del fichero crontab. La página del manual de la sección 5 contiene el formato del fichero y algunos ejemplos de entradas.

  • /usr/share/doc/at-<version>/timespec contiene el formato del fichero y algunos ejemplos de entradas.

  • Página de manual at — descripción de at y batch y las opciones de la línea de comandos.

Capítulo 36. Archivos de registro

Los Archivos de registro (o archivos de log) son archivos que contienen mensajes sobre el sistema, incluyendo el kernel, los servicios y las aplicaciones que se ejecutan en dicho sistema. Existen diferentes tipos de archivos de log dependiendo de la información. Por ejemplo, existe un archivo de log del sistema, un archivo de log para los mensajes de seguridad y un archivo de log para las tareas cron.

Los archivos de registro pueden ser muy útiles cuando se trate de resolver un problema con el sistema tal como cuando se trata de cargar un controlador del kernel o cuando se este buscando por intentos no autorizados de conexión al sistema. Este capítulo discute donde encontrar estos archivos de registro, cómo visualizarlos y qué buscar en ellos.

Algunos archivos de log están controlados por un demonio llamado syslogd. Encontrará una lista de mensajes de log mantenidos por syslogd en el archivo de configuración /etc/syslog.conf.

36.1. Localizar archivos de registro

La mayoría de los archivos de registro están localizados en el directorio /var/log. Algunas aplicaciones como por ejemplo httpd y samba poseen un directorio en /var/log para sus archivos de registro (log).

Encontrará multiples archivos con números en el directorio de archivos de registro. Estos se crean cuando se rotan los archivos de registro. Los archivos de registro se rotan para que los tamaños de los archivos no se vuelvan muy grandes. El paquete logrotate contiene una tarea cron que rota automáticamente los archivos de registro de acuerdo con el archivo de configuración /etc/logrotate.conf y los archivos de configuración en el directorio /etc/logrotate.d/. Por defecto se encuentra configurado para rotar todas las semanas y mantener cuatro semanasde archivos de registro previos.

36.2. Visualizar los archivos de registro

La mayoría de los archivos de registro están en formato de texto plano. Puede visualizarlos con cualquier editor de texto tal como Vi o Emacs. Algunos archivos log pueden ser leídos por todos los usuarios del sistema; sin embargo se requiere de privilegios como root para visualizar la mayoría de ellos.

Para ver los archivos de registro del sistema en una aplicación en tiempo real e interactiva utilice System Log Viewer. Para iniciar la aplicación a Aplicaciones (el menú principal en el panel) => Sistema => Registros de Sistema, o escriba el comando gnome-system-log en el intérprete de comandos.

La aplicación sólo muestra los archivos de registro que existen; por lo tanto, la lista puede ser diferente a la que aparece en la Figura 36.1, “Sistema de Registro.

Sistema de Registro

Sistema de Registro

Figura 36.1. Sistema de Registro

Para filtrar el contenido de un archivo de registro seleccionado haga click en Vista desde el menú y seleccione Filtro como se meustra a continuación.

Registro del Sistema - Menú Vista

Sistema de Registro - Menú Vista

Figura 36.2. Registro del Sistema - Menú Vista

Al seleccionar en el menú Filtro esto mostrará el campo de texto Filter en donde puede escribir las palabras que desea utilizar para su filtro. Para dejar el filtro en blanco haga click en el botón Borrar. La figura a continuación muestra un filtro de ejemplo:

Sistema de Registro - Filtro

Sistema de Registro - Filtro

Figura 36.3. Sistema de Registro - Filtro

36.3. Añadir un archivo de registro

Para añadir un archivo de registro para poder verlo en la lista seleccione Archivo => Abrir. Aparecerá la ventana Abrir Registro en donde podrá seleccionar el directorio y el nombre del archivo del archivo de registro que desea ver. La figura a continuación muestra la ventana Abrir Registro.

Añadir un archivo de registro

Añadir un archivo de registro

Figura 36.4. Añadir un archivo de registro

Haga click en el botón Abrir para abrir este archivo. El archivo es añadido inmediatamente a la lista en donde puede seleccionarlo y ver el contenido.

Observe también que el Registro de Sistema le permite abrir registros comprimidos cuyos nombres terminan en ".gz".

36.4. Control de Archivos de Registro

Registro del Sistema por defecto monitorea todos los registros abiertos. Si se le añade una línea nueva a un archivo de registro monitoreado, el nombre de registro aparece en negrilla en la lista de registros. Si el archivo de registro es seleccionado, las nuevas líneas aparecerán en negrilla al final del archivo de registro y pasados cinco minutos aparecerán en formato normal. La siguiente figura ilustra esto y muestra una nueva alerta en el archivo de registro mensajes. El archivo de registro aparece en negrilla en la lista.

Alerta del Archivo de Registro

Alerta del Archivo de Registro

Figura 36.5. Alerta del Archivo de Registro

Al hacer click en el archivo de registro de messages aparecerán los registros en el archivo con las nuevas líneas en negrilla como se muestra a continuación:

Contenido del archivo de registro

Contenido del archivo de registro

Figura 36.6. Contenido del archivo de registro

Las nuevas líneas se presentan en negrilla durante cinco segundos y después aparecen en letra normal.

Contenido del archivo de registro después de cinco segundos

Contenido del archivo de registro después de cinco segundos

Figura 36.7. Contenido del archivo de registro después de cinco segundos

Parte V. Supervisión del sistema

Capítulo 37. SystemTap

37.1. Introducción

SystemTap proporciona una interfaz de línea de comandos y un lenguaje de script que simplifica la obtención de información sobre el kernel de Linux en ejecución para que éste pueda ser analizado en profundidad. Los datos pueden ser extraidos, filtrados y resumidos de manera rápida y segura, permitiendo así el diagnóstico de problemas complejos de funcionalidad o rendimiento.

SystemTap permite que los scripts sean escritos en el lenguaje de script propio de SystemTap, el cual es luego compilado en los módulos de kernel en C e insertado en el kernel.

La principal idea tras los scripts de systemtap es nombrar eventos y darles un manejador. Cuando un evento ocurre, el Kernel de Linux ejecuta el manejador como si fuera éste una subrutina rápida, luego continúa. Hay diferentes tipos de eventos, tales como entrar o salir de una función, el vencimiento de un cronómetro o el inicio o finalización de la sesión de systemtap. El manejador consiste de una serie de declaraciones a ejecutar una vez el evento ocurra. Entre estas declaraciones puede estar la extracción de datos del contexto del evento, almacenamiento de variables internas o la impresión de resultados.

37.2. Implementación

SystemTap toma un enfoque orientado al compilador para generar instrumentación. Consulte Figura 37.1, “Flujo de Datos en SystemTap” "Flujo de datos en SystemTap" para obtener un diagrama general del SystemTap utilizado en esta discusión. En la esquina superior derecha del diagrama se encuentra el probe.stp, el script probe (de sondeo) que el desarrollador ha escrito. Esto es analizado sintácticamente por el traductor en árboles de análisis. En ese momento se revisa la entrada para detectar errores de sintaxis. Después el traductor realiza la elaboración, incorporando código adicional de la biblioteca de scripts y determinando la ubicación de puntos de sondeo y variables de la información de depuración. Después de que se ha completado la elaboración el traductor puede generar la probe.c, el módulo del kernel en C.

El archivo probe.c es compilado en un módulo de kernel regular, probe.ko, utilizando el compilador GCC. La compilación puede incorporar código soporte de la bibliotecas de ejecución. Depués de que GCC ha generado la probe.ko, se inicia el demonio de System Tap para recoger las salidas del módulo de instrumentación. Este módulo es cargado en el kernel y se da inicio a la recolección de datos. Los datos del módulo de instrumentación se transfieren a un espacio de usuario por medio de relayfs y son presentados por daemon. Cuando el usuario presiona Control-C el demonio descarga el módulo, el cual también apaga el proceso de recolección de datos.

Flujo de Datos en SystemTap

Flujo de Datos en SystemTap

Figura 37.1. Flujo de Datos en SystemTap

37.3. Utilización de System Tap

Systemtap trabaja traduciendo un script de SystemTap a C, ejecutando el compilador del sistema C para crear un módulo kernel de eso. Cuando se carga el módulo, activa todos los eventos probados conectándose al kernel. Después mientras los venetos ocurren en cualquier procesador, los manipuladores compilados ejecutan. Eventualmente, la sesión se detiene, la conexiones se deshacen y se elimina el módulo. Todo este proceso es dirigido desde un sólo programa de líneas de comandos, stap.

37.3.1. Rastreo

La manera más simple de sondear es rastrear un evento. Este es el efecto de insertar declaraciones de impresión estratégicamente ubicadas en un programa. Con frecuencia este es el primer paso para resolver un problema: explorar para ver la historia de lo que ha pasado.

Este estilo de instrumentación es el más simple. Sólo le pide a systemtap que imprima algo para cada evento. Para expresar esto en el lenguaje de scripts necesita decir donde se debe hacer el sondeo y lo que debe imprimir allí.

37.3.1.1. Donde Sondear

Systemtap soporta un número de eventos incorporados. La biblioteca de scripts que viene con systemtap, cada una llamada un "tapset", puede definir otras más en términos de la familia incorporada. Vea la página stapprobes del manual para obtener más detalles. Todos estos eventos son denominados utilizando una sintaxis unificada que se parece a los identificadores parametrizados separados por puntos:

Evento Descripción
inicio El arranque de la sesión de systemtap.
end El final de la sesión de systemtap
kernel.function("sys_open") La entrada a la función llamada sys_open en el kernel.
syscall.close.return El retorno de la llamada del sistema cerrado.
module("ext3").statement(0xdeadbeef) La instrucción dirigida en el controlador del sistema de archivos ext3.
timer.ms(200) Un temporizador que dispara cada 200 milisegundos.
Tabla 37.1. Eventos SystemTap

Como ejemplo utilizaremos un caso en el que usted quisiera rastrear todas las entradas y salidas de funciones en un archivo fuente, por ejemplo, net/socket.c en el kernel. El punto de sondeo kernel.function le permite expresar eso fácilmente debido a que systemtap examina la información de depuración del kernel para relacionar código del objeto con código fuente. Funciona como un depurador: si lo puede nombrar o ubicarlo entonces puede sondearlo. Utilice kernel.function("*@net/socket.c") para las entradas de función y kernel.function("*@net/socket.c").return para las salidas. Observe el uso de comodines en la parte del nombre de la función y la parte subsecuente @FILENAME. También puede poner comodines en el nombre del archivo e inclusive añadir dos puntos (:) y un número de línea, si quiere restringir la búsqueda con tal precisión. Debido a que systemtap pondrá una sonda separada en cada lugar que coincida con un punto de sondeo, unos pocos comodines se pueden expandir a cientos o miles de sondeos, así que tenga cuidado con lo que pide.

Una vez identifique los puntos de sondeo aparecerá el esqueleto del script de systemtap. La palabra clave probe introduce un punto de prueba o una lista de ellas separadas por comas. Los parentesis { y } encierran el manipulador para todos los puntos de sondeo enumerados.

Puede ejecutar este script tal como está aunque con manipuladores vacios no habrá salidas. Ponga las dos líneas en un archivo nuevo. Ejecute stap -v FILE. Déle fin en cualquier momento con ^C. (La opción -v le dice systemtap que imprima más mensajes verbosos durante su procesamiento. Intente la opción -h para ver más opciones.

37.3.1.2. Que Imprimir

Debido a que está interesado en cada función a la que se entró y se salió, se debería imprimir una línea para cada una que contenga el nombre de la función. Para hacer que la lista sea fácil de leer, systemtap debe indentar las líneas de manera que las funciones llamadas por otras funciones rastreadas sean anidadas más a fondo. Para distinguir un proceso de los otros que se puedan estar ejecutando en ese momento, systemtap debe imprimir el identificador del proceso en la línea.

Capítulo 38. Reunir información del sistema

Antes de aprender cómo configurar su sistema, debería aprender cómo obtener la información esencial sobre su sistema. Por ejemplo, debería saber cómo encontrar información sobre cuánta memoria libre tiene disponible, cuánto espacio libre en disco duro tiene disponible, cómo está particionado y qué procesos se están ejecutando. Este capítulo trata sobre cómo recuperar este tipo de información a partir de sus sistema Red Hat Enterprise Linux utilizando comandos fáciles y algunos programas simples.

38.1. Procesos del sistema

El comando ps ax muestra una lista de los procesos que se encuentran actualmente en el sistema, incluyendo los procesos que pertenecen a otros usuarios. Para mostrar el propietario de un proceso, utilice el comando ps aux. Esta lista es estática; es decir, es una representación instantánea de los procesos que están en ejecución en el momento de invocar el comando. Si quiere obtener una lista dinámica de los procesos en ejecución de su sistema, utilice el comando top tal y como se describe más adelante.

La salida ps puede ser larga. Para evitar que haga scroll fuera de la pantalla, puede canalizarla a través de less:

ps aux | less

Puede utilizar el comando ps en combinación con el comando grep para ver si un proceso en concreto está en ejecución. Por ejemplo, para ver si Emacs se esta ejecutando, utilice el comando:

ps ax | grep emacs

El comando top muestra los procesos que se encuentran actualmente en ejecución e información importante sobre los mismos, como la memoria que utilizan y el tiempo de CPU que consumen. El resultado se muestra en una lista en tiempo real e interactiva. Un ejemplo de la salida en pantalla de top sería:

 top - 15:02:46 up 35 min, 4 users, load average: 0.17, 0.65, 1.00 Tasks: 110 total, 1 running, 107 sleeping, 0 stopped, 2 zombie Cpu(s): 41.1% us, 2.0% sy, 0.0% ni, 56.6% id, 0.0% wa, 0.3% hi, 0.0% si Mem: 775024k total, 772028k used, 2996k free, 68468k buffers Swap: 1048568k total, 176k used, 1048392k free, 441172k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4624 root 15 0 40192 18m 7228 S 28.4 2.4 1:23.21 X 4926 mhideo 15 0 55564 33m 9784 S 13.5 4.4 0:25.96 gnome-terminal 6475 mhideo 16 0 3612 968 760 R 0.7 0.1 0:00.11 top 4920 mhideo 15 0 20872 10m 7808 S 0.3 1.4 0:01.61 wnck-applet 1 root 16 0 1732 548 472 S 0.0 0.1 0:00.23 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 3 root 5 -10 0 0 0 S 0.0 0.0 0:00.03 events/0 4 root 6 -10 0 0 0 S 0.0 0.0 0:00.02 khelper 5 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid 29 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/0 47 root 16 0 0 0 0 S 0.0 0.0 0:01.74 pdflush 50 root 11 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0 30 root 15 0 0 0 0 S 0.0 0.0 0:00.05 khubd 49 root 16 0 0 0 0 S 0.0 0.0 0:01.44 kswapd0 

Para salir de top, presione la tecla q.

Tabla 38.1, “Comando interactivos de top contiene comandos interactivos útiles que puede utilizar con top. Para mayor información, consulte la página del manual de top(1).

Comando Descripción
Espacio Realiza un refresco de la pantalla
h Muestra la pantalla de ayuda
k Mata un proceso. Se le pedirá que introduzca el ID del proceso y la señal a enviarle.
n Cambia el número de procesos que se muestran en pantalla. Se le pedirá que introduzca el número.
u Ordena por usuario.
M Ordena por uso de memoria.
P Ordena por uso del CPU.
Tabla 38.1. Comando interactivos de top

Si prefiere una interfaz gráfica para top, puede usar el Monitor del sistema de GNOME. Para iniciar esta aplicación desde el escritorio, seleccione Sistema => Administración => Monitor del sistema o escriba gnome-system-monitor en un interprete de comandos (como XTerm). Seleccione la pestaña Listado de Procesos.

El Monitor del sistema GNOME le permite buscar un proceso en la lista de procesos en ejecución así como visualizar todos los procesos, sus procesos o los procesos activos.

El menú Editar le permitirá:

  • Detener un proceso.

  • Continuar o iniciar un proceso.

  • Finalizar un proceso.

  • Matar un proceso.

  • Cambiar la prioridad de un proceso seleccionado.

  • Editar las preferencias del Monitor del sistema. Entre éstas se incluye el cambio de intervalo en segundos en que la lista de procesos será recargada y la selección de los campos a mostrar en la ventana del Monitor del sistema.

El menú Ver le permitirá:

  • Ver sólo los procesos activos.

  • Ver todos los procesos.

  • Ver mis procesos.

  • Ver dependencias de los procesos.

  • Ocultar un proceso.

  • Ver proceso oculto.

  • Ver mapas de memoria.

  • Ver los archivos abiertos por el proceso seleccionado.

Para detener un proceso, selecciónelo y haga clic en Finalizar Proceso. Asimismo, usted puede seleccionar el proceso en la lista, hacer clic en Editar y seleccionar Finalizar proceso.

Para ordenar la información según una columna específica, haga clic en el nombre de la columna. Esta acción ordenará la información en orden ascendente. Haga clic nuevamente sobre el nombre de la columna para obtener una lista en orden descendente.

El Monitor del sistema de GNOME

Listado de procesos del Monitor del sistema de GNOME

Figura 38.1. El Monitor del sistema de GNOME

38.2. Utilización de memoria

El comando free muestra el total de la memoria física y swap del sistema así como las cantidades de memoria que estamos utilizando, que queda libre, que está siendo compartida en buffers del kernel y cacheada.

 total used free shared buffers cached Mem: 645712 549720 95992 0 176248 224452 -/+ buffers/cache: 149020 496692 Swap: 1310712 0 1310712 

El comando free -m muestra la misma información, pero en megabytes, lo cual es más fácil de leer.

 total used free shared buffers cached Mem: 630 536 93 0 172 219 -/+ buffers/cache: 145 485 Swap: 1279 0 1279 

Si prefiere utilizar una interfaz gráfica para free, puede usar el Monitor del sistema de GNOME. Para iniciar esta aplicación desde el escritorio, vaya a Sistema => Administración => Monitor del sistema o escriba gnome-system-monitor en un interprete de comandos (como XTerm). Escoja la pestaña Recursos.

Monitor del sistema de GNOME - Pestaña Recursos

Pestañas de recursos de gnome-system-monitor

Figura 38.2. Monitor del sistema de GNOME - Pestaña Recursos

38.3. Sistemas de archivos

El comando df le informa sobre la ocupación de disco que realiza el sistema. Si teclea el comando df en la línea del indicador de comandos, obtendrá la siguiente salida en pantalla:

 Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 11675568 6272120 4810348 57% / /dev/sda1 100691 9281 86211 10% /boot none 322856 0 322856 0% /dev/shm 

Por defecto, esta utilidad muestra el tamaño de las particiones en bloques de 1 kilobyte y el tamaño del espacio libre en kilobytes. Para ver esta información en megabytes y gigabytes, utilice el comando df -h. El argumento -h se utiliza para especificar un formato "legible" (human-readable format). La salida que obtendríamos en este caso sería tal y como se muestra a continuación:

 Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 12G 6.0G 4.6G 57% / /dev/sda1 99M 9.1M 85M 10% /boot none 316M 0 316M 0% /dev/shm

En la lista de particiones, existe una entrada para /dev/shm. Esta entrada representa el sistema de archivos de memoria virtual del sistema.

El comando du muestra la cantidad estimada de espacio que está siendo utilizado por los ficheros de un directorio. Si teclea du en la línea de comandos, el uso de disco de cada uno de los subdirectorios se mostrará en una lista. Se mostrará también el espacio total ocupado en el directorio actual y en los subdirectorios del mismo en la última línea de la lista. Si no quiere ver los totales para todos los subdirectorios, teclee du -hs y verá tan sólo el espacio total ocupado por el directorio. Use el comando du --help para ver más opciones.

Para ver las particiones del sistema y el uso de espacio de disco en un formato gráfico, utilice el Monitor del sistema GNOME. Para iniciar esta aplicación desde el escritorio, seleccione Sistema => Administración => Monitor del sistema o escriba gnome-system-monitor en un interprete de comandos (como XTerm). Seleccione la pestaña Sistemas de archivos para ver las particiones del sistema. La siguiente figura ilustra la pestaña Sistema de archivos.

Monitor del sistema de GNOME - Sistemas de archivos

Pestaña de Sistemas de archivos de gnome-system-monitor

Figura 38.3. Monitor del sistema de GNOME - Sistemas de archivos

38.4. Hardware

Si tiene problemas con la configuración de su hardware o simplemente desea conocer qué hardware hay en su sistema, puede utilizar la aplicación Navegador de Hardware para ver el hardware que puede ser probado. Para iniciar el programa desde el escritorio, seleccione Sistema (el menú principal en el panel) => Herramientas del sistema => Navegador de hardware o escriba hwbrowser en el intérprete de comandos. Como se muestra en la Figura 38.4, “Navegador de Hardware, se visualizarán los dispositivos de CD-ROM, los disquetes, los discos duros y sus particiones, los dispositivos de red, dispositivos puntero y las tarjetas de vídeo. Haga clic en el nombre de la categoría en el menú de la izquierda y verá toda la información.

Navegador de Hardware

hwbrowser

Figura 38.4. Navegador de Hardware

La aplicación Administrador de dispositivos también puede ser utilizada para mostrar el hardware de su sistema. Esta aplicación puede ser iniciada desde Sistema (el menú principal en el panel) => Administración => Hardware. Para iniciar la aplicación desde una terminal, escriba hal-device-manager. Dependiendo de las preferencias de la instalación, el menú gráfico puede mostrar esta aplicación o el Navegador de hardware. La figura dada a continuación muestra la ventana del Administrador de dispositivos.

Administrador de dispositivos

Administrador de dispositivos

Figura 38.5. Administrador de dispositivos

También puede utilizar el comando lspci para listar todos los dispositivos PCI. Use el comando lspci -v para ver información ampliada o lspci -vv para una salida de pantalla muy ampliada.

Por ejemplo, lspci puede usarse para determinar el fabricante, el modelo y el tamaño de la memoria de una tarjeta de vídeo:

 00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) 00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) 00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04) 00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) 01:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02) 01:05.0 RAID bus controller: IBM ServeRAID Controller 

lspci es útil a la hora de determinar la tarjeta de red de su sistema si no conoce el fabricante o el número de modelo.

38.5. Recursos adicionales

Para aprender más sobre cómo obtener información del sistema, consulte los siguientes recursos.

38.5.1. Documentación instalada

  • ps --help — Despliega una lista de opciones que pueden utilizarse con ps.

  • Página del manual de top — Escriba man top para aprender más de top y sus muchas opciones.

  • Página del manual de free — escriba man free para más detalles sobre free y sus opciones.

  • Página del manual df — Escriba man df para más detalles sobre df y sus otras opciones.

  • Página del manual de du — Utilice el comando man du para más información sobre du y sus opciones.

  • Página del manual de lspci — Utilice el comando man lspci para ver más información sobre lspci y sus opciones.

  • Directorio /proc/ — El contenido del directorio /proc/ se puede utilizar para reunir información detallada del sistema.

Capítulo 39. OProfile

OProfile es una herramienta de supervisión de rendimiento que se ejecuta a lo largo de todo el sistema. Utiliza el hardware de supervisión de rendimiento en el procesador para recuperar información sobre el kernel y los ejecutables en el sistema, tal como cuando la memoria es referenciada, el número de peticiones caché L2 y el número de interrupciones de hardware recibidas. En un sistema Red Hat Enterprise Linux, el paquete RPM oprofile debe estar instalado para poder utilizar esta herramienta.

Muchos procesadores incluyen hardware dedicado a la supervisión. Este hardware hace posible detectar la ocurrencia de ciertos eventos (tal como que los datos solicitados no estén en caché). El harware normalmente toma la forma de uno o más contadores que se incrementan cada vez que ocurre un evento. Cuando el valor del contador llega al "máximo," se genera una interrupción, haciendo posible controlar la cantidad de detalles (y por tanto, la sobrecarga) producida por la supervisión del rendimiento.

OProfile utiliza este hardware (o un substituto basado en temporizadores en casos donde no está presente el hardware de supervisión) para reunir muestras de datos relacionados al rendimiento cada vez que un contador genera una interrupción. Estas muestras son escritas periódicamente al disco; luego los datos contenidos en estas muestras pueden ser usados para generar informes de rendimiento a nivel del sistema y de las aplicaciones.

Oprofile es una herramienta útil, pero tenga en cuenta ciertas limitaciones cuando lo esté utilizando:

  • Uso de bibliotecas compartidas — Las muestras de código en las bibliotecas compartidas no son atribuídos a una aplicación particular a menos que se utilice la opción --separate=library.

  • Las muestras de supervisión de rendimiento son inexactas — Cuando un registro de supervisión de rendimiento lanza una muestra, el manejo de la interrupción no es preciso como una excepción de división por cero. Debido a la ejecución de instrucciones fuera de orden por el procesador, la muestra puede que se grabe en una instrucción cercana.

  • opreport no asocia adecuadamente las muestras para las funciones incorporadas o 'inline'opreport utiliza un mecanismo de intervalo de direcciones simples para determinar en cuál función se encuentra una dirección. Las muestras de funciones incorporadas no son atribuídas a la función incorporada sino a la función en la que fue insertada la función incorporada.

  • OProfile acumula datos desde múltiples ejecuciones — Oprofile es un perfilador extendido a todo el sistema y que espera que los procesos se inicien y terminen en tiempos diferentes. Por tanto, se acumulan muestras de múltiples ejecuciones. Utilice el comando opcontrol --reset para limpiar las muestras de ejecuciones anteriores.

  • Problemas de rendimiento no limitados al CPU — OProfile está orientado a encontrar problemas con procesos limitados al CPU. Oprofile no identifica procesos que estén dormidos porque estos estan esperando por bloqueos o porque ocurra algún otro evento (por ejemplo, que un dispositivo de E/S termine una operación).

39.1. Descripción general de las herramientas

Tabla 39.1, “Comandos OProfile” proporciona una breve descripción de las herramientas suministradas con el paquete oprofile.

Comando Descripción
ophelp

Muestra los eventos disponibles para el procesador del sistema junto con una breve descripción para cada uno.

opimport

Convierte archivos de la base de datos de muestras de un formato binario extraño al formato nativo para el sistema. Solamente utilice esta opción cuando esté analizando una base de datos de muestras desde una arquitectura diferente.

opannotate Crea un código fuente con notas para un ejecutable si la aplicación fue compilada con símbolos de depuración. Consulte la Sección 39.5.4, “Utilizando opannotate para obtener más detalles.
opcontrol

Configura qué datos son reunidos. Consulte la Sección 39.2, “Configuración de Oprofile” para obtener más detalles.

opreport

Recupera datos del perfil. Vea la Sección 39.5.1, “Utilizando opreport para más detalles.

oprofiled

Se ejecuta como un demonio para escribir periódicamente datos de muestra al disco.

Tabla 39.1. Comandos OProfile

39.2. Configuración de Oprofile

Antes de que pueda ejecutar Oprofile, debe configurarlo. Como mínimo, se requiere seleccionar supervisar el kernel (o seleccionar no supervisar el kernel). Las secciones siguientes describen cómo utilizar la utilidad opcontrol para configurar Oprofile. A medida que se ejecutan los comandos opcontrol, las opciones de configuración son guardadas al archivo /root/.oprofile/daemonrc.

39.2.1. Especificar el Kernel

Primero, configure si Oprofile debería supervisar el kernel. Esta es la única opción de configuración que se requiere antes de iniciar Oprofile. Todas las otras opciones son opcionales.

Para supervisar el kernel, ejecute el comando siguiente como root:

opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux

Nota

El paquete debuginfo (el cual contiene el kernel sin comprimir) debe ser instalado para poder monitorear el kernel.

Para configurar Oprofile para que no controle el kernel, ejecute el comando siguiente como root:

opcontrol --setup --no-vmlinux

Este comando también carga el módulo del kernel oprofile, si aún no ha sido cargado y crea el directorio /dev/oprofile/ si aún no existe. Consulte la Sección 39.6, “Comprender /dev/oprofile/ para obtener más detalles sobre este directorio.

Nota

Aún si se configura Oprofile para que no perfile el kernel, el kernel de SMP debe estar ejecutándose para que el módulo oprofile se pueda cargar a partir de este.

El configurar si las muestras deberían ser reunidas dentro del kernel sólo cambia los datos que son reunidos y no el cómo o dónde se almacenan estos datos. Para generar archivos de muestras diferentes para el kernel y las bibliotecas de aplicaciones consulte la Sección 39.2.3, “Separar perfiles del Kernel y del espacio del usuario”.

39.2.2. Configurar los eventos a supervisar

La mayoría de los procesadores contienen contadores, los cuales Oprofile utiliza para supervisar eventos específicos. Como se muestra en la Tabla 39.2, “Procesadores y contadores de Oprofile” el número de contadores disponibles depende del procesador.

Procesador cpu_type Número de contadores
Pentium Pro i386/ppro 2
Pentium II i386/pii 2
Pentium III i386/piii 2
Pentium 4 (sin hilos múltiples) i386/p4 8
Pentium 4 (múltiples hilos o hyper-threaded) i386/p4-ht 4
Athlon i386/athlon 4
AMD64 x86-64/hammer 4
Itanium ia64/itanium 4
Itanium 2 ia64/itanium2 4
TIMER_INT timer 1
IBM eServer iSeries y pSeries timer 1
ppc64/power4 8
ppc64/power5 6
ppc64/970 8
IBM eServer S/390 y S/390x timer 1
IBM eServer zSeries timer 1
Tabla 39.2. Procesadores y contadores de Oprofile

Utilice la Tabla 39.2, “Procesadores y contadores de Oprofile” para verificar que fue detectado el tipo correcto de procesador y para determinar el número de eventos que se pueden monitorear simultáneamente. Se utiliza timer como el tipo de procesador si el procesador no tiene hardware de supervisión del rendimiento soportado.

Si se utiliza timer, los eventos no se pueden configurar para ningún procesador porque el hardware no tiene el soporte para el hardware de contadores de rendimiento. En su lugar, se utilizan las interrupciones del temporizador para crear perfiles.

Si no se utiliza timer como el tipo de procesador, se pueden cambiar los eventos supervisados y el contador 0 para el procesador, es configurado por defecto a un evento con base en tiempo. Si existe más de un contador en el procesador, los contadores diferentes del contador 0, no se configuran a un evento por defecto. Los eventos controlados por defecto se muestran en la Tabla 39.3, “Eventos predeterminados”.

Procesador Evento Predeterminado para el Contador Descripción
Pentium Pro, Pentium II, Pentium III, Athlon, AMD64 CPU_CLK_UNHALTED El reloj del procesador no está detenido
Pentium 4 (HT y no-HT) GLOBAL_POWER_EVENTS El tiempo durante el cual el procesador no está detenido
Itanium 2 CPU_CYCLES CPU Cycles
TIMER_INT (ninguno) Muestra para cada interrupción del temporizador
ppc64/power4 CICLOS Ciclos del Procesador
ppc64/power5 CICLOS Ciclos del Procesador
ppc64/970 CICLOS Ciclos del Procesador
Tabla 39.3. Eventos predeterminados

El número de eventos que se pueden supervisar a la vez, es determinado por el número de contadores para el procesador. Sin embargo, no es una relación de uno a uno; en algunos procesadores, se deben mapear ciertos eventos a contadores específicos. Para determinar el número de contadores disponibles, ejecute el comando siguiente:

ls -d /dev/oprofile/[0-9]*

Los eventos disponibles varían dependiendo del tipo de procesador. Para determinar los eventos disponibles para el perfilamiento, ejecute el comando siguiente como root (la lista es específica al tipo de procesador):

ophelp

Se pueden configurar los eventos para cada contador a través de la línea de comandos o con una interfaz gráfica. Para obtener mayor información sobre la interfaz gráfica consulte Sección 39.8, “Interfaz gráfica”. Si el contador no se puede configurar para un evento específico, aparece un mensaje de error.

Para configurar el evento para cada contador configurable a través de la línea de comandos, utilice opcontrol:

opcontrol --event=<event-name>:<sample-rate>

Reemplace <nombre-del-evento> con el número exacto del evento comenzando desde ophelp y reemplazando <muestra-ejemplo> con el número de eventos entre los ejemplos.

39.2.2.1. Velocidad de muestreo

Por defecto, se selecciona un evento basado en tiempo. Esto crea aproximadamente 100,000 muestras por segundo por procesador. Si se utilizan las interrupciones del temporizador, el temporizador es configurado a la velocidad instantánea que sea y no el usuario no la puede configurar. Si el cpu_type no es timer, cada evento puede tener una velocidad de muestreo configurada. La velocidad de muestreo es el número de eventos entre cada instantánea de muestra.

Cuando configure el evento para el contador, también se puede especificar una velocidad de muestreo:

opcontrol --event=<event-name>:<sample-rate>

Reemplace <muestra-ejemplo> con el número de eventos a esperar antes de tomar muestras otra vez. Mientras más pequeña la cuenta, más frecuentes seran los muestreos. Para aquellos eventos que no ocurren frecuentemente, se necesita una cuenta más pequeña para capturar las instancias del evento.

Atención

Tenga extremo cuidado cuando configure las velocidades de muestreo. Si se toman muestras con demasiada frecuencia puede sobrecargar al sistema, causando que el sistema parezca congelado o que en verdad el sistema se congele.

39.2.2.2. Máscaras de unidades

Algunos eventos de monitoriamiento del desempeño pueden necesitar máscaras de unidades para definir aún más el evento.

Las máscaras de unidades para cada evento son enumeradas con el comando ophelp. Los valores para cada máscara de unidad son listados en formato hexadecimal. Para especificar más de una máscara de unidad, los valores hexadecimales deben estar combinados usando una operación de bits or.

opcontrol --event=<nombre-evento>:<muestra-ejemplo>:<máscara-unidad>

39.2.3. Separar perfiles del Kernel y del espacio del usuario

Por defecto, se reune información del modo del kernel y del modo del usuario por cada evento. Para configurar Oprofile para que ignore los eventos en modo del kernel para un contador en particular, ejecute el siguiente comando:

opcontrol --event=<nombre-evento>:<muestra-ejemplo>:<máscara-unidad>:0

Ejecute el comando siguiente para comenzar a perfilar otra vez en modo kernel para el contador:

opcontrol --event=<nombre-evento>:<muestra-ejemplo>:<máscara-unidad>:1

Para configurar Oprofile para que ignore eventos en modo usuario para un contador específico, ejecute el siguiente comando:

opcontrol --event=<nombre-evento>:<muestra-evento>:<máscara-unidad>:<kernel>:0

Ejecute el comando siguiente para comenzar a perfilar nuevamente en modo usuario para el contador:

opcontrol --event=<nombre-evento>:<muestra-ejemplo>:<máscara-unidad>:<kernel>:1

Cuando el demonio Oprofile escribe datos del perfil a los archivos de muestras, puede separar los datos del perfil de kernel y de la biblioteca en archivos separados. Para configurar la forma en que el demonio escribe a los archivos de muestra, ejecute el comando siguiente como root:

opcontrol --separate=<opción>

<choice> puede ser alguno de los siguientes:

  • none — no separa los perfiles (predeterminado)

  • library — genera perfiles por aplicación para las bibliotecas

  • kernel — genera perfiles por aplicación para el kernel y sus módulos

  • all — genera perfiles por aplicación para las bibliotecas y perfiles por aplicación para el kernel y los módulos del kernel

Si se utiliza --separate=library, el nombre del archivo de muestras incluye el nombre del ejecutable así como también el nombre de la biblioteca.

Nota

Estos cambios en la configuración tendrán lugar cuando se reinicie oprofile.

39.3. Iniciar y detener Oprofile

Para comenzar a supervisar el sistema con Oprofile, ejecute el comando siguiente como root:

opcontrol --start

Se muestra una salida similar a la siguiente:

Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.

Se utilizan las configuraciones en /root/.oprofile/daemonrc.

El demonio Oprofile, oprofiled, es iniciado; este escribe periódicamente los datos de muestra al directorio /var/lib/oprofile/samples/. El archivo de registro para el demonio está ubicado en /var/lib/oprofile/oprofiled.log.

Para detener el perfilador, ejecute el siguiente comando como root:

opcontrol --shutdown

39.4. Guardar los datos

Algunas veces es útil guardar las muestras a una hora específica. Por ejemplo, cuando se esté perfilando un ejecutable, puede ser útil reunir muestras diferentes basadas en diferentes conjuntos de datos de entrada. Si el número de eventos a monitorear excede el número de contadores disponibles para el procesador, se puede ejecutar varias veces Oprofile para reunir los datos, guardando los datos de muestra a archivos diferentes cada vez.

Para guardar el conjunto actual de archivos de muestra, ejecute el comando siguiente, reemplazando <name> con un nombre descriptivo único para la sesión actual.

opcontrol --save=<nombre>

Se crea el directorio /var/lib/oprofile/samples/name/ y los archivos de muestras actuales son copiados a él.

39.5. Análisis de los datos

Periódicamente, el demonio Oprofile, oprofiled colecciona las muestras y las escribe al directorio /var/lib/oprofile/samples/. Antes de leer los datos, asegúrese de que todos los datos han sido escritos a este directorio ejecutando el siguiente comando como root:

opcontrol --dump

Cada archivo de muestra se basa en el nombre del ejecutable. Por ejemplo, las muestras para el evento predeterminado en un procesador Pentium III para /bin/bash se convierte en:

\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000

Las herramientas siguientes están disponibles para perfilar los datos de muestra una vez que se han reunido:

  • opreport

  • opannotate

Utilice estas herramientas, junto con los binarios perfilados para generar informes que pueden ser analizados más aún.

Aviso

El ejecutable que está siendo perfilado se debe usar con estas herramientas para analizar los datos. Si se debe cambiar luego de que los datos son recogidos, haga una copia de seguridad del ejecutable usado para crear las muestras así como también los archivos de muestra. Observe que el archivo muestra y el binario tienen que concordar. El realizar una copia de seguridad no sirve de nada si no coinciden. oparchive se puede utilizar para resolver este problema.

Las muestras para cada ejecutable son escritas a un archivo de muestras único. Las muestras de cada biblioteca de enlace dinámica también son escritas a un archivo de muestras único. Mientras que Oprofile se esté ejecutando, si el ejecutable que está siendo supervisado cambia y existe un archivo de muestras para este ejecutable, el archivo existente es borrado automáticamente. Por tanto, si se necesita el archivo de muestras existente, se debe realizar una copia de seguridad de este junto con el ejecutable que se utilizó para crearlo antes de reemplazarlo con una nueva versión. Las herramientas de analisis oprofile utilizan el archivo ejecutable que creó las muestras durante el análisis. Si el ejecutable cambia las herramientas de análisis no podrán analizar las muestras asociadas. Consulte la Sección 39.4, “Guardar los datos” para obtener más detalles sobre cómo hacer una copia de seguridad del archivo de muestra.

39.5.1. Utilizando opreport

La herramienta opreport proporciona una descripción general de todos los ejecutables que se están perfilando.

Lo siguiente forma parte de una salida de ejemplo:

 Profiling through timer interrupt TIMER:0| samples| %| ------------------ 25926 97.5212 no-vmlinux 359 1.3504 pi 65 0.2445 Xorg 62 0.2332 libvte.so.4.4.0 56 0.2106 libc-2.3.4.so 34 0.1279 libglib-2.0.so.0.400.7 19 0.0715 libXft.so.2.1.2 17 0.0639 bash 8 0.0301 ld-2.3.4.so 8 0.0301 libgdk-x11-2.0.so.0.400.13 6 0.0226 libgobject-2.0.so.0.400.7 5 0.0188 oprofiled 4 0.0150 libpthread-2.3.4.so 4 0.0150 libgtk-x11-2.0.so.0.400.13 3 0.0113 libXrender.so.1.2.2 3 0.0113 du 1 0.0038 libcrypto.so.0.9.7a 1 0.0038 libpam.so.0.77 1 0.0038 libtermcap.so.2.0.8 1 0.0038 libX11.so.6.2 1 0.0038 libgthread-2.0.so.0.400.7 1 0.0038 libwnck-1.so.4.9.0 

Cada ejecutable es listado en su propia línea. La primera columna es el número de muestras registradas para el ejecutable. La segunda columna es el porcentaje de muestras relativo al número total de muestras. La tercera columna es el nombre del ejecutable.

Consulte la página man de opreport para ver una lista de las opciones de línea de comandos disponibles, tales como la opción -r utilizada para ordenar la salida desde el ejecutable con el que tiene menos muestras hasta el que tiene el mayor número.

39.5.2. Utilizando opreport en un Ejecutable Unico

Para recuperar más información detallada sobre un ejecutable en particular utilice opreport:

opreport <modo><ejecutable>

<executable> debe ser la ruta completa al ejecutable a analizar. <mode> debe ser uno de los siguientes:

-l

Lista los datos de muestra por símbolos. Por ejemplo, lo siguiente es parte de la salida al ejecutar el comando opreport -l /lib/tls/libc-<version>.so:

 samples % symbol name 12 21.4286 __gconv_transform_utf8_internal 5 8.9286 _int_malloc 4 7.1429 malloc 3 5.3571 __i686.get_pc_thunk.bx 3 5.3571 _dl_mcount_wrapper_check 3 5.3571 mbrtowc 3 5.3571 memcpy 2 3.5714 _int_realloc 2 3.5714 _nl_intern_locale_data 2 3.5714 free 2 3.5714 strcmp 1 1.7857 __ctype_get_mb_cur_max 1 1.7857 __unregister_atfork 1 1.7857 __write_nocancel 1 1.7857 _dl_addr 1 1.7857 _int_free 1 1.7857 _itoa_word 1 1.7857 calc_eclosure_iter 1 1.7857 fopen@@GLIBC_2.1 1 1.7857 getpid 1 1.7857 memmove 1 1.7857 msort_with_tmp 1 1.7857 strcpy 1 1.7857 strlen 1 1.7857 vfprintf 1 1.7857 write 

La primera columna es el número de muestras para el símbolo, la segunda columna es el porcentaje de muestras para este símbolo con relación a las muestras en general para el ejecutable y la tercera columna es el nombre del símbolo.

Para ordenar la salida desde el número más grande de muestras al más pequeño (orden inverso), utilice la opción -r en conjunto con la opción -l.

-i <nombre-símbolo>

Lista datos de muestra específicos al nombre del símbolo. Por ejemplo, la salida siguiente es del comando opreport -l -i __gconv_transform_utf8_internal /lib/tls/libc-<version>.so:

 samples % symbol name 12 100.000 __gconv_transform_utf8_internal 

La primera línea es un resúmen para la combinación símbolo/ejecutable.

La primera columna es el número de muestras para el símbolo de memoria. La segunda columna es el número el porcentaje de muestras para la dirección de memoria relativa al número total de muestras para el símbolo. La tercera columna es el nombre del símbolo.

-d

Lista datos de muestra para símbolos con más detalles que -l. Por ejemplo, la siguiente salida es del comando opreport -l -d __gconv_transform_utf8_internal /lib/tls/libc-<versión>.so:

 vma samples % symbol name 00a98640 12 100.000 __gconv_transform_utf8_internal 00a98640 1 8.3333 00a9868c 2 16.6667 00a9869a 1 8.3333 00a986c1 1 8.3333 00a98720 1 8.3333 00a98749 1 8.3333 00a98753 1 8.3333 00a98789 1 8.3333 00a98864 1 8.3333 00a98869 1 8.3333 00a98b08 1 8.3333 

Los datos son los mismos que con la opción -l excepto que para cada símbolo, se muestra cada dirección virtual de memoria utilizada. Para cada dirección virtual de memoria se despliegan, el número de muestras y los porcentajes de las muestras relativos al número de muestras para el símbolo.

-x <nombre-símbolo>

Excluye la lista de símbolos separada por comas de la salida.

--session <nombre>

Especifica la ruta completa a la sesión o un directorio relativo al directorio /var/lib/oprofile/samples/.

39.5.3. Obtener salidas más detalladas sobre los módulos

OProfile recopila datos a nivel del sistema para código de espacio de usuario y de kernel que se ejecuta en la máquina. Sin embargo, una vez que se carga un módulo en el kernel, la información sobre el origen del módulo del kernel se pierde. Elo módulo puedo haber provenido del archivo initrd durante el arranque, el directorio con varios módulos de kernel o un módulo de kernel creado localmente. Por consiguiente, cuando OProfile graba muestras para un módulo sólamente enumera las muestras para los módulos para un ejecutable el el directorio root, pero no es muy probable que sea el lugar con el código real para el módulo. Necesitará seguir ciertos pasos para asegurarse de que las herramientas de análisis obtengan el ejecutable.

Por ejemplo en una máquina AMD64 el muestreo está configurado para grabar "Acceso de datos caché" y "Pérdida de datos de caché" y asumiendo que le gustaría ver los datos para el módulo ext3:

$ opreport /ext3
CPU: AMD64 processors, speed 797.948 MHz (estimated)
Counted DATA_CACHE_ACCESSES events (Data cache accesses) with a unit mask of 0x00 (No unit mask) count 500000
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 500000
DATA_CACHE_ACC...|DATA_CACHE_MIS...|
samples|      %|  samples|      %|
------------------------------------
148721 100.000      1493 100.000 ext3

Para obtener una vista más detallada de las acciones del módulo necesitará tener el módulo montado (por ejemplo, instalado desde una cosntrcción personalizada) o tener el RPM debuginfo instalado para el kernel.

Descubra que kernel está ejecutando "uname -a", e instalelo en la máquina.

Después cree un vínculo simbólico para que oprofile encuentre el código para el módulo en el lugar correcto:

# ln -s /lib/modules/`uname -r`/kernel/fs/ext3/ext3.ko /ext3

. Después la información detallada se puede obtener con:

# opreport image:/ext3 -l|more
warning: could not check that the binary file /ext3 has not been modified since the profile was taken. Results may be inaccurate.
CPU: AMD64 processors, speed 797.948 MHz (estimated)
Counted DATA_CACHE_ACCESSES events (Data cache accesses) with a unit mask of 0x00 (No unit mask) count 500000
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 500000
samples  %        samples  %        symbol name
16728    11.2479  7         0.4689  ext3_group_sparse
16454    11.0637  4         0.2679  ext3_count_free_blocks
14583     9.8056  51        3.4159  ext3_fill_super
8281      5.5681  129       8.6403  ext3_ioctl
7810      5.2514  62        4.1527  ext3_write_info
7286      4.8991  67        4.4876  ext3_ordered_writepage
6509      4.3767  130       8.7073  ext3_new_inode
6378      4.2886  156      10.4488  ext3_new_block
5932      3.9887  87        5.8272  ext3_xattr_block_list
...

39.5.4. Utilizando opannotate

La herramienta opannotate trata de poner juntas las muestras para instrucciones particulares con sus líneas correspondientes en el código fuente. Los archivos que resultan deberían tener las muestras para las líneas a la izquierda. También coloca un comentario al comienzo de cada función listando las muestras totales para la función.

Para que esta utilidad funcione, el ejecutable debe ser compilado con la opción -g de GCC. Por defecto, los paquetes deRed Hat Enterprise Linux no son compilados con esta opción.

La sintaxis general para opannotate es la siguiente:

opannotate --search-dirs <src-dir> --source <executable>

Se debe especificar el directorio que contiene el código fuente y el ejecutable a analizar. Consulte la página del manual de opannotate para obtener una lista con las opciones de línea de comandos adicionales.

39.6. Comprender /dev/oprofile/

El directorio /dev/oprofile/ contiene los archivos para Oprofile. Utilice el comando cat para mostrar los valores de los archivos virtuales en este sistema de archivos. Por ejemplo, el comando siguiente muestra el tipo de procesador que Oprofile detectó:

cat /dev/oprofile/cpu_type

Existe un directorio en /dev/oprofile/ para cada contador. Por ejemplo, si hay dos contadores, existen los directorios /dev/oprofile/0/ y dev/oprofile/1/.

Cada directorio de contadores contiene los archivos siguientes:

  • count — El intervalo entre las muestras.

  • enabled — Si es 0, el contador está desactivado y no se reúnen muestras para este; si es 1, el contador está activado y se están recogiendo las muestras.

  • event — El evento a supervisar

  • kernel — Si es 0, las muestras no son reunidas para este contador de eventos cuando el procesador está en el espacio del kernel; si es 1, las muestras son reunidas aún si el procesador está en el espacio del kernel.

  • unit_mask — Define cuáles máscaras de unidades son activadas para el contador.

  • user — Si es 0, las muestras no son reunidas para el contador cuando el procesador está en el espacio del usuario; si es 1, las muestras son reunidas aún si el procesador está en el espacio del usuario

Los valores de estos archivos se pueden obtener con el comando cat. Por ejemplo:

cat /dev/oprofile/0/count

39.7. Ejemplo de uso

Mientras que Oprofile puede ser usado por desarrolladores para analizar el rendimiento de una aplicación, también puede ser usado por los administradores de sistemas para analizar el rendimiento del sistema. Por ejemplo:

  • Determina cuáles aplicaciones y servicios son los más usados en un sistemaopreport se puede usar para determinar cuánto tiempo de procesador utiliza una aplicación o servicio. Si el sistema es usado para múltiples servicios pero no está rindiendo bien, los servicios que consuman más tiempo de procesamiento se pueden mover a sistemas dedicados.

  • Determinar el uso del procesador — El evento CPU_CLK_UNHALTED se puede monitorear para determinar la carga del procesador durante un tiempo determinado. Estos datos luego se pueden usar para determinar si la implementación de procesadores adicionales o más rápidos pueden mejorar el rendimiento del sistema.

39.8. Interfaz gráfica

Algunas preferencias de Oprofile se pueden configurar con una interfaz gráfica. Para iniciarla, ejecute el comando oprof_start como root en el indicador de comandos. Para utilizar la interfaz gráfica necesitará tener instalado el paquete oprofile-gui.

Después de cambiar cualquiera de las opciones, las puede guardar pulsando el botón Guardar y salir. Las preferencias son escritas al /root/.oprofile/daemonrc y la aplicación termina. Al salir de la aplicación no detiene a Oprofile de seguir tomando muestras.

En la pestaña Disposición, para configurar los eventos para los contadores del procesador como se discutió en la Sección 39.2.2, “Configurar los eventos a supervisar”, seleccione el contador desde el menú desplegable y seleccione el evento de la lista. Aparecerá una breve descripción del evento en la caja de texto debajo de la lista. Solamente se muestran los eventos disponibles para el contador y la arquitectura específica. La interfaz también muestra si el perfilador está ejecutándose y algunas breves estadísticas sobre el mismo.

Disposición de Oprofile

Interfaz oprof_start

Figura 39.1. Disposición de Oprofile

En el lado derecho de la pestaña, seleccione la opción Perfilar kernel para contar eventos en modo kernel para el evento seleccionado actualmente, como se discutió en la Sección 39.2.3, “Separar perfiles del Kernel y del espacio del usuario”. Si no se selecciona esta opción entonces no se recogen muestras para el kernel.

Seleccione la opción Perfilar binarios del usuario para contar eventos en el modo usuario para el evento seleccionado, como se discutió en la Sección 39.2.3, “Separar perfiles del Kernel y del espacio del usuario”. Si no se selecciona esta opción, no se recogen opciones para las aplicaciones de usuarios.

Utilice el campo de texto Contador para configurar la velocidad de muestreo para el evento seleccionado como se discutió en la Sección 39.2.2.1, “Velocidad de muestreo”.

Si existen máscaras de unidades disponibles para el evento seleccionado actualmente como se discutió en Sección 39.2.2.2, “Máscaras de unidades”, estas se mostrarán en el área Máscaras de unidades en el lado derecho de la pestaña Configuración. Seleccione la casilla de verificación al lado de la máscara de unidad para activarla para el evento.

En la pestaña Configuración, para perfilar el kernel, ingrese el nombre y ubicación del archivo vmlinux del kernel para supervisar en el campo de texto Archivo de imagen del kernel. Para configurar Oprofile para que no supervise el kernel, seleccione No kernel image.

Configuración de Oprofile

Configuración de Oprofile

Figura 39.2. Configuración de Oprofile

Si la opción Verbose está seleccionada, el demonio de registro de oprofiled incluye más información.

Si se selecciona Archivos de muestras del kernel por aplicación, Oprofile genera perfiles por aplicación para el kernel y los módulos del kernel como se discutió en la Sección 39.2.3, “Separar perfiles del Kernel y del espacio del usuario”. Esto es equivalente al comando opcontrol --separate=kernel. Si está seleccionado Archivos de muestras de bibliotecas compartidas por aplicación, Oprofile genera perfiles por aplicación para las bibliotecas. Esto es equivalente al comando opcontrol --separate=library.

Para forzar a que los datos sean escritos a los archivos de muestras como se discutió en la Sección 39.5, “Análisis de los datos”, pulse el botón Vaciar datos del perfil. Esto es equivalente al comando opcontrol --dump.

Para iniciar Oprofile desde la interfaz gráfica, pulse en Iniciar perfilador. Para detener el perfilador, pulse en Detener perfilador. Al salir de la aplicación no se detiene Oprofile de continuar tomando muestras.

39.9. Recursos adicionales

Este capítulo solamente resalta Oprofile y cómo configurarlo y utilizarlo. Para aprender un poco más, consulte los recursos siguientes.

39.9.1. Documentos instalados

  • /usr/share/doc/oprofile-<versión>/oprofile.htmlOProfile Manual

  • oprofile man page — Discusses opcontrol, opreport, opannotate, y ophelp

39.9.2. Sitios Web útiles

Parte VI. Configuración del Kernel y los dispositivos

Capítulo 40. Actualización Manual del Kernel

El kernel que viene junto con Red Hat Enterprise Linux está personalizado por el equipo de desarrollo del kernel de Red Hat Enterprise Linux para asegurar su integridad y compatibilidad con el hardware soportado. Antes que Red Hat libere un kernel, este debe pasar un conjunto de evaluaciones rigurosas para asegurar su calidad.

Los kernels de Red Hat Enterprise Linux se encuentran empacados en un formato RPM para que seán fáciles de actualizar y verificar utilizando el comando Herramienta de administración de paquetes o yum. Herramienta de administración de paquetes automáticamente le consulta a los servidores de Red Hat Enterprise Linux y determina que paquetes deben ser actualizados en su máquina, incluyendo el kernel. Este capítulo sólo es útil para aquellos individuos que necesitan una actualización manual de los paquetes del kernel sin utilizar el comando yum.

Aviso

El grupo de soporte de servicios a nivel global de Red Hat no soporta la construcción de un kernel personalizado y por lo tanto esto no se cubre en este manual.

Sugerencia

Red Hat recomienda la utilización del comando yum para instalar kernel actualizados.

Para obtener más información sobre Red Hat Network, la Herramienta de administración de paquetes y yum consulte Capítulo 13, Red Hat Network.

40.1. Descripción general de los Paquetes del Kernel

Red Hat Enterprise Linux contiene los siguientes paquetes del kernel (algunos puede que no se apliquen a su arquitectura):

  • kernel — Contiene el kernel para sistemas multiprocesos. Para el sistema x86 sólamente se utilizan los primeros 4GB de RAM. Como tal, los sistemas x86 con más de 4GB de RAM deben utilizar el kernel-PAE.

  • kernel-devel — Contiene las cabeceras del kernel y los makefiles suficientes para construir módulos contra el paquete kernel.

  • kernel-PAE (sólo para sistemas i686) — Este paquete ofrece las siguientes opciones calve de configuración (además de las opciones que ya han sido habilitadas para el paquete kernel):

    • Soporte para más de 4GB de RAM (hasta 64GB para x86)

    • PAE (Extensión de Dirección Física o Physical Address Extension, en inglés), o paginado de nivel 3 en procesadores x86 que soportan PAE

    • División 4GB/4GB — 4GB de espacio de direcciones virtuales para el kernel y casi 4GB para cada proceso de usuario en sistemas x86

  • kernel-PAE-devel — Contiene las cabeceras de kernel y makefiles requeridos para construir módulos contra el paquete kernel-PAE

  • kernel-doc — Contiene los archivos de documentación de la fuente del kernel. Varias partes del kernel de Linux y los controladores de dispositivos enviados con este se encuentran documentados en estos archivos. La instalación de este paquete proporciona una referencia de las opciones que se pueden pasar a la módulos de kernel de Linux al ser cargado.

    Por defecto, estos archivos se encuentran en el directorio /usr/share/doc/kernel-doc-<version>/.

  • kernel-headers — Incluye los archivos de cabecera de C que especifican la interfaz entre el kernel de Linux y las bibliotecas del espacio de usuario y los programas. Los archivos de cabecera definen estructuras y constantes que se necesitan para construir la mayoría de los programas estándares.

  • kernel-xen — Incluye una versión del kernel de Linux la cual se necesita para ejecutar Virtualización.

  • kernel-xen-devel — Contiene las cabeceras del kernel y los makefiles requeridos para construir módulos contra el paquete kernel-xen.

Nota

El paquete kernel-source ha sido eliminado y reemplazado con un RPM que sólo se puede recuperar desde Red Hat Network. Este paquete *.src.rpm debe ser recontruido localmente utilizando el comando rpmbuild. Para obtener mayor información sobre como obtener e instalar el paquete fuente del kernel consulte las últimas Notas de Lanzamiento (incluyendo las actualizaciones) en http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/index.html.

40.2. Preparación para la actualización

Antes de actualizar el kernel, tome algunas precauciones. La primera es asegurarse que tiene un disco de arranque funcional en caso de que se presenten problemas. Si el gestor de arranque no está configurado apropiadamente para arrancar el nuevo kernel, no será capaz de arrancar su sistema en Red Hat Enterprise Linux a menos que tenga un disquete de arranque.

Para crear un disco de arranque, conéctese como usuario root y en el intérprete de comandos ejecute el comando /sbin/mkbootdisk `uname -r`.

Sugerencia

Consulte la página del manual mkbootdisk para obtener más opciones. Puede crear medios de arranque por medio de CD-Rs, CD-RWs y dispositivos de memoria USB dado que su sistema BIOS también lo soporte.

Reinicie la máquina con el medio de arranque y verifique que funciona antes de continuar.

Para determinar cuáles paquetes del kernel están instalados, ejecute el comando rpm -qa | grep kernel en el intérprete de comandos:

La salida contendrá alguno o todos los siguientes paquetes, dependiendo de la arquitectura del sistema (el número de la versión y los paquetes pueden variar):

kernel-2.6.9-5.EL 
kernel-devel-2.6.9-5.EL 
kernel-utils-2.6.9-5.EL 
kernel-doc-2.6.9-5.EL 
kernel-smp-2.6.9-5.EL 
kernel-smp-devel-2.6.9-5.EL 
kernel-hugemem-devel-2.6.9-5.EL

De la salida puede determinar qué paquetes necesita descargar para actualizar el kernel. El único paquete necesario para un sistema con un único procesador es el kernel. Para ver las descripciones de los diferentes paquetes refiérase a la Sección 40.1, “Descripción general de los Paquetes del Kernel”.

En el nombre del archivo cada paquete kernel contiene la arquitectura para la cual fue construido el paquete. El formato es kernel<variante>-<versión>.<arch>.rpm, en donde <variante> es PAE, xen etcetera. La <arch> es una de las siguientes:

  • x86_64 para las arquitecturas AMD64 e Intel EM64T

  • ia64 para la arquitectura Intel®Itanium™.

  • ppc64pseries para la arquitectura IBM®eServerpSeries™.

  • s390 para la arquitectura IBM®S/390®.

  • s390x para la arquitectura IBM®eServerSystem z®.

  • i686 para sistemas Intel®Pentium® II, Intel®Pentium® III, Intel®Pentium® 4, AMD Athlon® y sistemas AMD Duron®.

40.3. Descarga

Hay varias maneras de saber si hay un kernel actualizado disponible para su sistema.

  • Errata de Seguridad — Consulte http://www.redhat.com/security/updates/ para obtener información sobre errata de seguridad, incluyendo actualizaciones del kernel que reparan problemas de seguridad.

  • Use Red Hat Network — para descargar los paquetes RPM del kernel e instalarlos. Red Hat Network puede descargar el kernel más reciente, actualizarlo en el sistema, crear una imagen de disco RAM inicial si se necesita y configurar el gestor de arranque para arrancar el nuevo kernel. Para obtener mayor información consulte http://www.redhat.com/docs/manuals/RHNetwork/.

Si se usó Red Hat Network para descargar e instalar el kernel actualizado siguiendo las instrucciones en Sección 40.5, “Verificación de la imagen de disco RAM inicial” y Sección 40.6, “Configuración del gestor de arranque” excepto que no cambie el kernel para arrancar por defecto puesto que Red Hat Network cambia automáticamente el kernel a la versión más reciente. Para instalar el kernel manualmente continue con Sección 40.4, “Realizando la actualización”.

40.4. Realizando la actualización

Después de obtener todos los paquetes necesarios, es hora de actualizar el kernel existente.

Importante

Se recomienda guardar el kernel anterior por si tiene problemas con el kernel nuevo.

En el intérprete de comandos cambie el directorio que contiene los paquetes RPM del kernel.Utilice el argumento -i con el comando rpm para mantener el viejo kernel. No utilice la opción -U ya que sobreescribirá el kernel instalado actualmente, lo cual genera problemas con el gestor de arranque. Por ejemplo:

rpm -ivh kernel-<versión kernel >.<arch>.rpm

El próximo paso es verificar que la imagen del disco inicial RAM ha sido creada. Refiérase a la Sección 40.5, “Verificación de la imagen de disco RAM inicial” para obtener más detalles.

40.5. Verificación de la imagen de disco RAM inicial

Si el sistema usa un sistema de archivos ext3, un controlador SCSI, o etiquetas para referenciar particiones en /etc/fstab, necesitará un disco RAM inicial. Este disco permite a un kernel modular tener acceso a los módulos desde donde puede necesitar arrancar antes de que el kernel tenga acceso a los dispositivos donde normalmente residen los módulos.

En las arquitecturas diferentes a IBM eServer iSeries, el disco RAM inicial puede ser creado con el comando mkinitrd. Sin embargo, este paso es ejecutado automáticamente si el kernel y sus paquetes asociados son instalados o actualizados desde los paquetes RPM distribuidos por Red Hat; en tales casos no necesita crear el disco RAM inicial manualmente. Para verificar que sí fue creado, use el comando ls -l /boot para asegurarse de que el archivo initrd-<version>.img fue creado (la versión debería coincidir con la versión del kernel que acaba de instalar).

En sistemas iSeries, el disco RAM inicial y el archivo vmlinux se combinan en un solo archivo, el cual es creado con el comando addRamDisk. Este paso es ejecutado automáticamente si el kernel y sus paquetes asociados son instalados o actualizados desde los paquetes RPM distribuidos por Red Hat, Inc.; por lo tanto, no necesita ser ejecutado manualmente. Para verificar que fue creado use el comando ls -l /boot para asegurarse de que el archivo /boot/vmlinitrd-<kernel-version> ya exitste (<kernel-version> debería coincidir con la versión del kernel que acaba de instalar).

El próximo paso es verificar que el gestor de arranque está configurado para cargar el nuevo kernel. Vea la Sección 40.6, “Configuración del gestor de arranque” para obtener más detalles.

40.6. Configuración del gestor de arranque

El paquete RPM kernel configura el gestor de arranque para arrancar el nuevo kernel (excepto para sistemas IBM eServer iSeries). Sin embargo, no configura el gestor de arranque para cargar el nuevo kernel por defecto.

Es una buena idea confirmar que el gestor de arranque se ha configurado correctamente. Esto es un paso crucial. Si el gestor de arranque está configurado de forma incorrecta, no podrán arrancar Red Hat Enterprise Linux correctamente. Si esto ocurre, arranque el sistema con el disquete de arranque que creó anteriormente e intente configurar de nuevo el gestor de arranque.

40.6.1. Sistemas x86

Todos los sistemas x86 (incluyendo todos los sistemas AMD64) utilizan GRUB como gestor de arranque.

40.6.1.1. GRUB

Confirme que el archivo /boot/grub/grub.conf contiene una sección title con la misma versión que el paquete kernel que acaba de instalar

# Note that you do not have to rerun grub after making changes to this file 
# NOTICE:  You have a /boot partition.  This means that 
#          all kernel and initrd paths are relative to /boot/, eg. 
#          root (hd0,0) 
#          kernel /vmlinuz-version ro root=/dev/hda2 
#          initrd /initrd-version.img 
#boot=/dev/hda 
default=1 timeout=10 
splashimage=(hd0,0)/grub/splash.xpm.gz 
title Red Hat Enterprise Linux (2.6.9-5.EL)
         root (hd0,0)
         kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/         
         initrd /initrd-2.6.9-5.EL.img 
title Red Hat Enterprise Linux (2.6.9-1.906_EL)
         root (hd0,0)         
         kernel /vmlinuz-2.6.9-1.906_EL ro root=LABEL=/         
         initrd /initrd-2.6.9-1.906_EL.img

Si ha creado una partición separada para /boot/ la ruta al kernel y la imagen initrd serán relativas a /boot/.

Observe que el nuevo kernel no está configurado para ser el kernel por defecto. Para configurar GRUB para que arranque el nuevo kernel por defecto, cambie el valor de la variable default al número del título de la sección que contiene el nuevo kernel. La cuenta comienza con 0. Por ejemplo, si el nuevo kernel es el primer título en la sección, configure default a 0.

Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarase de que el hardware es detectado adecuadamente.

40.6.2. Sistemas Itanium

Los sistemas Itanium utilizan ELILO como el gestor de arranque, que usa /boot/efi/EFI/redhat/elilo.conf como archivo de configuración. Confirme que este archivo contiene una sección image con la misma versión que el paquete kernel que acaba de instalar:

prompt timeout=50 default=old  image=vmlinuz-2.6.9-5.EL
         label=linux         
         initrd=initrd-2.6.9-5.EL.img         read-only         
         append="root=LABEL=/" image=vmlinuz-2.6.9-1.906_EL         
         label=old         
         initrd=initrd-2.6.9-1.906.img         read-only         
         append="root=LABEL=/"

Observe que el nuevo kernel no está configurado para ser el kernel por defecto. Para configurar ELILO para que arranque el nuevo kernel por defecto, cambie el valor de la variable default al valor de label de la sección image del nuevo kernel. Debe ejecutar el comando /sbin/lilo como root para activar los cambios. Después de ejecutarlo, verá un resultado similar al siguiente:

Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarase de que el hardware es detectado adecuadamente.

40.6.3. Sistemas IBM S/390 e IBM System z

Los sistemas IBM S/390 e IBM System z utilizan z/IPL como gestor de arranque, el cual usa /etc/zipl.conf como archivo de configuración. Confirme que el archivo contiene una sección con la misma versión que el paquete kernel que acaba de instalar:

[defaultboot] default=old target=/boot/ 
[linux]
         image=/boot/vmlinuz-2.6.9-5.EL         
         ramdisk=/boot/initrd-2.6.9-5.EL.img         
         parameters="root=LABEL=/" 
[old]
         image=/boot/vmlinuz-2.6.9-1.906_EL         
         ramdisk=/boot/initrd-2.6.9-1.906_EL.img         
         parameters="root=LABEL=/"

Observe que el nuevo kernel no está configurado para ser el kernel predeterminado. Para configurar z/IPL para que arranque el nuevo kernel por defecto, cambie el valor de la variable default al número de la sección que contiene el nuevo kernel. La primera línea de cada sección contiene el nombre en corchetes.

Después de modificar el archivo de configuración ejecute el comando /sbin/zipl como root para activar los cambios.

Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarase de que el hardware es detectado adecuadamente.

40.6.4. Sistemas IBM eServer iSeries

El archivo /boot/vmlinitrd-<kernel-version> es instalado cuando actualiza el kernel. Sin embargo, debe utilizar el comando dd para configurar el sistema para arrancar el nuevo kernel:

  1. Como root, escriba el comando cat /proc/iSeries/mf/side para determinar el lado por defecto (bien sea A, B, o C).

  2. Como root, ejecute el comando siguiente, donde <kernel-version> es la versión del nuevo kernel y <side> es el lado obtenido del comando anterior:

    dd if=/boot/vmlinitrd-<kernel-version> of=/proc/iSeries/mf/<side>/vmlinux bs=8k

Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarase de que el hardware es detectado adecuadamente.

40.6.5. Sistemas IBM eServer pSeries

Los sistemar IBM eServer pSeries utiliza YABOOT como el gestor de arranque, el cual usa /etc/aboot.conf como archivo de configuración.Confirme que el archivo contiene una sección image con la misma versión que el paquete kernel que acaba de instalar:

boot=/dev/sda1 init-message=Welcome to Red Hat Enterprise Linux! Hit <TAB> for boot options   
partition=2 timeout=30 install=/usr/lib/yaboot/yaboot delay=10 nonvram  
image=/vmlinux--2.6.9-5.EL
         label=old         
         read-only       
         initrd=/initrd--2.6.9-5.EL.img        
         append="root=LABEL=/"   
image=/vmlinux-2.6.9-5.EL         
         label=linux       
         read-only       
         initrd=/initrd-2.6.9-5.EL.img         
         append="root=LABEL=/"

Observe que el kernel no esta configurado para arrancarse por defecto. El kernel en la primera imagen es arrancado por defecto. Para cambiar el kernel a arrancar por defecto, mueva su estrofa imagen para que sea la primera listada o añada la directiva default y configurelo a la etiqueta de la estrofa imagen que contiene el nuevo kernel.

Comience evaluando el nuevo kernel reiniciando el computador y vigilando los mensajes para asegurarase de que el hardware es detectado adecuadamente.

Capítulo 41. Parámetros y Módulos Generales

Este capítulo ilustra algunos de los posibles parámetros disponibles para ciertos controladores[9], los cuales bajo Red Hat Enterprise Linux se llaman módulos del kernel. En la mayoría de casos, los parámetros por defecto funcionarán bien. Sin embargo, habrá ocasiones en las que se necesitará parámetros de módulos extra para que un dispositivo funcione correctamente o se necesita ignorar los parámetros predeterminados del módulo para el dispositivo.

Durante la instalación, Red Hat Enterprise Linux utiliza un subconjunto limitado de controladores de dispositivos para crear un ambiente de instalación estable. Aún cuando el programa de instalación soporta muchos tipos de hardware diferente, algunos controladores (incluyendo aquellos para adaptadores SCSI y tarjetas de red) no son incluidos en el kernel de instalación. Más bien, estos deben ser cargados como módulos por el usuario en el momento del arranque.

Una vez que la instalación se haya completado, hay soporte disponible para una gran cantidad de dispositivos a través de los módulos del kernel.

Importante

Red Hat proporciona un gran número de controladores de dispositivos no compatibles en un grupo de paquetes llamado kernel-smp-unsupported-<versión-kernel> y kernel-hugemem-unsupported-<versión-kernel>. . Reemplace <versión-kernel> con el número de versión del kernel instalado en su sistema. Estos paquetes no son instalados por el programa de instalación de Red Hat Enterprise Linux y los módulos suministrados no son respaldados por Red Hat, Inc.

41.1. Utilidades del Módulo del Kernel

Si está instalado el paquete module-init-tools, estará disponible un grupo de comandos para administrar los módulos del kernel. Utilice estos comandos para determinar si un módulo ha sido cargado exitosamente o cuando esté probando diferentes módulos para una nueva parte de hardware.

El comando /sbin/lsmod presenta una lista de módulos cargados actualmente. Por ejemplo:

Module                  Size  Used by
tun                    11585  1
autofs4                21573  1
hidp                   16193  2
rfcomm                 37849  0
l2cap                  23873  10 hidp,rfcomm
bluetooth              50085  5 hidp,rfcomm,l2cap
sunrpc                153725  1
dm_mirror              29073  0
dm_mod                 57433  1 dm_mirror
video                  17221  0
sbs                    16257  0
i2c_ec                  5569  1 sbs
container               4801  0
button                  7249  0
battery                10565  0
asus_acpi              16857  0
ac                      5701  0
ipv6                  246113  12
lp                     13065  0
parport_pc             27493  1
parport                37001  2 lp,parport_pc
uhci_hcd               23885  0
floppy                 57317  1
sg                     34653  0
snd_ens1371            26721  1
gameport               16073  1 snd_ens1371
snd_rawmidi            24897  1 snd_ens1371
snd_ac97_codec         91360  1 snd_ens1371
snd_ac97_bus            2753  1 snd_ac97_codec
snd_seq_dummy           4293  0
snd_seq_oss            32705  0
serio_raw               7493  0
snd_seq_midi_event      8001  1 snd_seq_oss
snd_seq                51633  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          8781  4 snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            42849  0
snd_mixer_oss          16833  1 snd_pcm_oss
snd_pcm                76485  3 snd_ens1371,snd_ac97_codec,snd_pcm_oss
snd_timer              23237  2 snd_seq,snd_pcm
snd                    52933  12 snd_ens1371,snd_rawmidi,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore              10145  1 snd
i2c_piix4               8909  0
ide_cd                 38625  3
snd_page_alloc         10569  1 snd_pcm
i2c_core               21697  2 i2c_ec,i2c_piix4
pcnet32                34117  0
cdrom                  34913  1 ide_cd
mii                     5825  1 pcnet32
pcspkr                  3521  0
ext3                  129737  2
jbd                    58473  1 ext3
mptspi                 17353  3
scsi_transport_spi     25025  1 mptspi
mptscsih               23361  1 mptspi
sd_mod                 20929  16
scsi_mod              134121  5 sg,mptspi,scsi_transport_spi,mptscsih,sd_mod
mptbase                52193  2 mptspi,mptscsih

Parac cada línea, la primera columna es el nombre del módulo, la segunda columna es el tamaño del módulo y la tercera es la cuenta de uso.

La salida /sbin/lsmod es menos verbosa y más fácil de leer que la salida de /proc/modules.

Para cargar un módulo de kernel utilice el comando /sbin/modprobe seguido por el nombre del módulo del kernel. Por defecto, modprobe trata de cargar el módulo desde los subdirectorios /lib/modules/<versión-kernel>/kernel/drivers/. Hay un subdirectorio para cada tipo de módulo tal como el subdirectorio net/ para controladores den interfaz de red. Algunos módulos del kernel tienen dependencias de módulos lo cual significa que los otros módulos deben cargarse primero para que este pueda ser cargado. El comando /sbin/modprobe verifica estas dependencias y carga las dependencias del módulo antes de cargar el módulo especificado.

Por ejemplo, el comando

/sbin/modprobe e100

carga cualquier dependencia de módulos y luego carga el módulo e100.

Para imprimir en la pantalla todos los comandos tal como /sbin/modprobe los ejecuta utilice la opción -v. Por ejemplo:

/sbin/modprobe -v e100

Aparecerá una salida similar a:

/sbin/insmod /lib/modules/2.6.9-5.EL/kernel/drivers/net/e100.ko
Using /lib/modules/2.6.9-5.EL/kernel/drivers/net/e100.ko 
Symbol version prefix 'smp_'

También existe el comando /sbin/insmod poara cargar módulos del kernel; sin embargo, no recuelve dependencias. Por lo tanto se recomienda utilizar el comando /sbin/modprobe.

Para descargar módulos del kernel utilice el comando /sbin/rmmod seguido por el nombre del módulo. La utilidad rmmod solamente descarga módulos que no se encuentran en uso y que no son una dependencia de otros módulos en uso.

Por ejemplo, el comando

/sbin/rmmod e100

descarga el módulo del kernel e100.

Otra utilidad bastante práctica del módulo de kernel es modinfo. Utilice el comando /sbin/modinfo para visualizar información sobre un módulo de kernel. La sintaxis general es:

/sbin/modinfo [opciones]<módulo>

Las opciones incluyen -d, el cual presenta una breve descripción del módulo y -p, el cual enumera los parámetros que el módulo soporta. Para obtener una lista completa de opciones consulte la página modinfo del manual (man modinfo).

41.2. Carga Persistente de Módulos

Los módulos del kernel usualmente son cargados directamente por la utilidad que los necesita, la cual es configurada de manera correcta en el archivo /etc/modprobe.conf. Sin embargo, a veces es necesario forzar explícitamente la carga de un módulo en el momento de arranque.

Red Hat Enterprise Linux verifica la existencia del archivo /etc/rc.modules en el momento de arranque, el cual contiene varios comandos para cargar módulos. SE debe utilizar rc.modules y norc.local ya que rc.modules es ejecutado antes durante el proceso de arranque.

Por ejemplo, los siguientes comandos configuran la carga del módulo foo en el momento de arranque (como root):

# echo modprobe foo >> /etc/rc.modules 
# chmod +x /etc/rc.modules

Sugerencia

Este enfoque no es necesario para las interfaces de red y de SCSI ya que tienen sus propios mecanismos específicos.

41.3. Especificar parámetros de módulos

Es algunas situaciones, puede ser necesario suministrar parámetros a un módulos cuando se carga, para que pueda funcionar apropiadamente.

Por ejemplo, para activar la conexión full duplex a una velocidad de 100Mbps para una tarjeta Intel Ether Express/100, cargue el controlador e100 con la opción e100_speed_duplex=4.

Atención

Cuando un parámetro tiene comas, asegúrese de no colocar un espacio luego de la coma.

Sugerencia

El comando modinfo también es útil para listar información sobre el módulo del kernel, tal como la versión, dependencias, opciones de parámetros y aliases.

41.4. Parámetros de Almacenamiento

Hardware Módulo Parámetros
Controlador de Almacenamiento 3ware y series 9000 3w-xxxx.ko, 3w-9xxx.ko
Adaptec Advanced Raid Products, Dell PERC2, 2/Si, 3/Si, 3/Di, HP NetRAID-4M, IBM ServeRAID, y ICP SCSI driver aacraid.ko

nondasd — Controla el escaneo de hba por dispositivos nondasd. 0=off, 1=on

dacmode — Controla si dma está utilizando 64 bit DAC. 0=off, 1=on

commit — Controla si se emite un COMMIT_CONFIG al adaptador para arrays foráneos. Usualmente esto se necesita en sistemas que no tienen una BIOS. 0=off, 1=on

startup_timeout — El tiempo en segundos que se debe esperar para que el adaptador tenga su kernel funcionando. Usualmente esto se ajusta para sistemas grandesque no tienen una BIOS.

aif_timeout — El tiempo en segundos que se debe esperar para que las aplicaciones reciban AIFs antes de desregistrarlas. Usualmente esto es ajustado para sistemas altamente cargados.

numacb — Pide un límite al número de bloqueos de control del adaptador (FIB) asignados. Los valores válidos son 512 y menores. Por defecto se utiliza la sugerencia de Firmware.

acbsize — Pide un tamaño especifico del bloqueo de control del adaptador. Los número válidos son 512, 2048, 4096 y 8192. Por defecto utiliza la sugerencia de Firmware.

Adaptec 28xx, R9xx, 39xx AHA-284x, AHA-29xx, AHA-394x, AHA-398x, AHA-274x, AHA-274xT, AHA-2842, AHA-2910B, AHA-2920C, AHA-2930/U/U2, AHA-2940/W/U/UW/AU/, U2W/U2/U2B/, U2BOEM, AHA-2944D/WD/UD/UWD, AHA-2950U2/W/B, AHA-3940/U/W/UW/, AUW/U2W/U2B, AHA-3950U2D, AHA-3985/U/W/UW, AIC-777x, AIC-785x, AIC-786x, AIC-787x, AIC-788x , AIC-789x, AIC-3860 aic7xxx.ko

verbose — Habilita el registro verboso de diagnóstico

allow_memio — Permite que los registros de dispositivos sean mapeados a la memoria.

debug — Activación los valores de depuración de Bitmask.

no_probe — Desactivación del sondeo del controlador de EISA/VLB.

probe_eisa_vl — Activación del sondeo del controlador EISA/VLB

no_reset — Suprimir la configuración inicial del bus.

extended — Permitir geometria extendida en todos los controladores.

periodic_otag — Envía una transacción etiquetada ordenada periódicamente para prevenir inanición de etiquetas. Algunos discos viejos o arrays RAID pueden necesitarlo.

global_tag_depth:<int> — Profundidad de etiqueta global para cada objetivo en todo bus.

seltime:<int> — Selección del tiempo de espera (0/256ms,1/128ms,2/64ms,3/32ms)

IBM ServeRAID ips.ko
Dispositivo LSI Logic MegaRAID Mailbox megaraid_mbox.ko

unconf_disks — Configurado para exponer discos no configurados al kernel (por defecto es 0).

busy_wait — Tiempo máximo de espera en microsegundos para el buzón si se encuentra ocupado (por defecto=10)

max_sectors — Número máximo de sectores por comando IO (por defecto=128)

cmd_per_lun — Número máximo de comandos por unidad lógica (por defecto=64)

fast_load — Carga más rápidadel dispositivo, ¡se salta los dispositivos físicos! (por defecto=0)

debug_level — Nivel de depuración para el controlador (por defecto=0)

Controlador Emulex LightPulse Fibre Channel SCSI lpfc.ko

lpfc_poll — control del modo de poll de la llamada FCP: 0 - ninguno, 1 - poll con interrupciones activadas, 3 - poll y desactivación de llamadas FCP.

lpfc_log_verbose — bit-mask de registro verboso

lpfc_lun_queue_depth — Número máximo de comandos FCP que se pueden poner en cola para una LUN específica.

lpfc_hba_queue_depth — Número máximo de comandos FCP que pueden hacer cola para un lpfc HBA

lpfc_scan_down — Empieza a escanear buscando dispositivos desde el ALPA más alto al más bajo

lpfc_nodev_tmo — El número de segundos que el controlador mantendrá I/O en espera de que un dispositivo vuelva

lpfc_topology — Selecciona la topología del canal de fibra

lpfc_link_speed — Selecciona la velocidad del enlace

lpfc_fcp_class — Selecciona la clase del canal de fibra del servicio para secuencias FCP

lpfc_use_adisc — Utiliza ADISC en redescubrimeinto para autenticar dispositivos FCP

lpfc_ack0 — Activa soporte ACK0

lpfc_cr_delay — Una cuenta de millisegundos después del cual se genera una respuesta de interrupción

lpfc_cr_count — Una cuenta de E/S completas después de la cual se genera una respuesta de interrupción

lpfc_multi_ring_support — Determina el número de llamadas SLI primarias para difundir entradas IOCB

lpfc_fdmi_on — Avtivas soporte FDMI

lpfc_discovery_threads — Número máximo de comandos ELS durante el descubrimiento

lpfc_max_luns — LUN máximo permitido

lpfc_poll_tmo — Los millisegundos que el controlador esperará entre polling FCP ring

HP Smart Array cciss.ko  
Fusión LSI Logic MPT mptbase.ko mptctl.ko mptfc.ko mptlan.ko mptsas.ko mptscsih.ko mptspi.ko

mpt_msi_enable — Activación del Soporte MSI

mptfc_dev_loss_tmo — Tiempo inicial en que el controlador programa el transporte en espera de un reporte para devolver el siguiente to return following a device loss event.

mpt_pt_clear — Dejar en blanco la tabla de persistencia

mpt_saf_te — Fuerza la activación del Procesador SEP

Controlador QLogic Fibre Channel qla2xxx.ko

ql2xlogintimeout — Valor en segundos antes de iniciar una sesión.

qlport_down_retry — Número máximo de intentos por comandos a un puerto que devuelve un status PORT-DOWN.

ql2xplogiabsentdevice — La opción para habilitar PLOGI para los dispositivos que no se encuentran presentes después de un escáner de Fabric.

ql2xloginretrycount — Especifica un valor alterno para la cuenta de reintentos del inicio de sesión NVRAM.

ql2xallocfwdump — La opción para habilitar la asignación de memoria a un volcado del firmware durante una inicialización HBA. Por defecto es 1 - asignar memoria.

extended_error_logging — La opción para activar el registro extendido de errores.

ql2xfdmienable — Activa registros FDMI.

NCR, Symbios y LSI 8xx y 1010 sym53c8xx

cmd_per_lun — Número máximo de etiquetas a utilizar por defecto

tag_ctrl — Control detallado sobre etiquetas por LUN

burst — Estallido máximo. 0 para deshabilitar, 255 para leer desde los registros

led — Configurado en 1 para habilitar el soporte LED

diff — 0 para modo no differencial, 1 para BIOS, 2 para siempre, 3 para no GPIO3

irqm — 0 para abrir drenaje, 1 para dejarlo tal cual, 2 para tótem

buschk — 0 para no verificar, 1 para separar ante un error, 2 para advertir ante un error

hostid — La identificación SCSI a utilizar para los adaptadores host

verb — 0 para verbosidad mínima, 1 para normal, 2 para excesiva

debug — Configura los bits para activar la depuración

settle — Selecciona el retraso en segundos. Por defecto es 3

nvram — Opción actualmente no utilizada

excl — Lista direcciones ioport para evitar que los controladores sean adjuntados

safe — Ajusta las otras configuraciones en un "modo seguro"

Tabla 41.1. Parámetros de Almacenamiento de Módulos

41.5. Parámetros Ethernet

Importante

La mayoría de las tarjetas de red basadas en Ethernet (NICs), no requieren parámetros de módulos para alterar las configuraciones. En vez de esto, ellas pueden ser configuradas usando ethtool o mii-tool. Sólo después de que estas herramientas fallen al funcionar, deberían de ajustarse los parámetros del módulo. Se pueden visualizar los parámetros del módulo usando el comando modinfo.

Nota

Para obtener información sobre el uso de estas herramientas consulte las páginas del manual para ethtool, mii-tool y modinfo.

Hardware Módulo Parámetros
3Com EtherLink PCI III/XL Vortex (3c590, 3c592, 3c595, 3c597) Boomerang (3c900, 3c905, 3c595) 3c59x.ko

debug — Nivel de depuración 3c59x (0-6)

options — 3c59x: Bits 0-3: tipo de medios, bit 4: bus mastering, bit 9: full duplex

global_options — 3c59x: lo mismo que opciones pero aplica a todos los NICs si opciones no se encuentra configurada

full_duplex — configuración(es) (1) full duplex 3c59x

global_full_duplex — 3c59x: lo mismo que full_duplex, pero aplica a todos los NICs si full_duplex no se encuentra configurado

hw_checksums — Suma de verificación 3c59x revisando adaptador(es) (0-1)

flow_ctrl — Utilización de control de flujo 3c59x 802.3x (PAUSE solamente) (0-1)

enable_wol — 3c59x: Activar Wake-on-LAN para los adaptador(es) (0-1)

global_enable_wol — 3c59x: igual que enable_wol, pero aplica a todos los NICs si enable_wol no se encuentra configurada

rx_copybreak — copie un punto de parada 3c59x para copiar- solamente-pequeñas-estructuras

max_interrupt_work — número máximo de eventos 3c59x manejados por interrupción

compaq_ioaddr — Dirección con base E/S 3c59x PCI (solución temporal del problema Compaq BIOS)

compaq_irq — número IRQ 3c59x PCI (solución temporal del problema Compaq BIOS)

compaq_device_id — Dispositivo de Identificación 3c59x PCI (solución temporal del problema Compaq BIOS)

watchdog — tiempo de espera de transmisión en milisegundos 3c59x

global_use_mmio — 3c59x: igual que use_mmio pero aplica a todos los NICs si las opciones no se encuentran configuradas

use_mmio — 3c59x: utiliza memory-mapeada PCI recurso E/S (0-1)

Tarjetas RTL8139, SMC EZ Card Fast Ethernet, RealTek usando RTL8129, o RTL8139 Fast Ethernet chipsets 8139too.ko
Controlador ethernet Broadcom 4400 10/100 PCI b44.ko

b44_debug — valor de activación del mensaje de depuración de B44 bitmapped

Controlador Broadcom NetXtreme II BCM5706/5708 bnx2.ko

disable_msi — Desactivación de las Interrupciones Señalizadas por Mensajes (MSI)

Intel Ether Express/100 driver e100.ko

debug — Nivel de depuración (0=ninguno,...,16=todo)

eeprom_bad_csum_allow — Permite malas sumas de comprobación eeprom

Intel EtherExpress/1000 Gigabit e1000.ko

TxDescriptors — Número de descriptores de transmisión

RxDescriptors — Número de descriptores recibidos

Speed — Velocidad de la configuración

Duplex — Configuración de duplex

AutoNeg — Configuración de la autonegociación publicada

FlowControl — Configuración del Control de Flujo

XsumRX — Activar o Desactivar descarga de suma de verificación recibida

TxIntDelay — Retraso de la Interrupción de la Transmisión

TxAbsIntDelay — Retraso de la Interrupción Absoluta de la Transmisión

RxIntDelay — Retraso de la Interrupción Recibida

RxAbsIntDelay — Retraso de la Interrupción Absoluta Recibida

InterruptThrottleRate — Interrupción del la Tasa de Aceleración

SmartPowerDownEnable — Activa PHY smart power down

KumeranLockLoss — Activa Kumeran lock loss workaround

Controlador Myricom 10G (10GbE) myri10ge.ko

myri10ge_fw_name — Nombre de la imagen del firmware

myri10ge_ecrc_enable — Activa CRC Extendida en PCI-E

myri10ge_max_intr_slots — Interrumpe ranuras de colas

myri10ge_small_bytes — Límite de pequeños paquetes

myri10ge_msi — Activar Interrupciones Señaladas de Mensajes

myri10ge_intr_coal_delay — Interrupción del retraso de fusionamiento

myri10ge_flow_control — Parámetro de pausa

myri10ge_deassert_wait — Espera cuando desimpone interrupciones de legado

myri10ge_force_firmware — Forza a firmware a asumir completaciones alineadas

myri10ge_skb_cross_4k — ¿Un pequeño skb puede cruzar un límite de 4KB?

myri10ge_initial_mtu — MTU Inicial

myri10ge_napi_weight — Peso asignado al NAPI

myri10ge_watchdog_timeout — Tiempo de espera por watchdog

myri10ge_max_irq_loops — Configura el límite de detección IRQ del legado incluido

NatSemi DP83815 Fast Ethernet natsemi.ko

mtu — DP8381x MTU (todos las placas)

debug — nivel de depuración DP8381x predeterminado

rx_copybreak — Punto de ruptura de copia de DP8381x para copiar-solamente-pequeñas-estructuras.

options — DP8381x: Bits 0-3: tipo de medios, bit 17: full duplex

full_duplex — configuración(es) DP8381x full duplex (1)

AMD PCnet32 y AMD PCnetPCI pcnet32.ko
PCnet32 y PCnetPCI pcnet32.ko

debug — nivel de depuración pcnet32

max_interrupt_work — Número máximo de eventos pcnet32 manejados por interrupción

rx_copybreak — Punto de ruptura de copia de pcnet32 para copiar-solamente-pequeñas-estructuras.

tx_start_pt — punto de inicio (0-3) para transmitir pcnet32

pcnet32vlb — soporte pcnet32 Vesa local bus (VLB) (0/1)

options — configuración(es) de la opción inicial pcnet32 (0-15)

full_duplex — configuración(es) pcnet32 full duplex (1)

homepna — modo pcnet32 para tarjetas 79C978 (1 para HomePNA, 0 para Ethernet, por defecto Ethernet

Controlador RealTek RTL-8169 Gigabit Ethernet r8169.ko

media — fuerza la operación de phy. Descontinuado y reemplazado por ethtool (8).

rx_copybreak — Punto de ruptura de copia para copiar-solamente-pequeñas-estructuras.

use_dac — Activa PCI DAC. No es seguro para ranuras de 32 bit PCI.

debug — Nivel de verbosidad de depuración (0=ninguna, ..., 16=toda)

Adaptador Neterion Xframe 10GbE Server s2io.ko  
Ethernet rápida SIS 900/701G PCI sis900.ko

multicast_filter_limit — Número máximo de direcciones multicast filtradas SiS 900/7016

max_interrupt_work — Número máximo de eventos manejados por interrupción SiS 900/7016

sis900_debug — nivel de mensajes de depuración de SiS 900/7016 bitmapped

Controlador Adaptec Starfire Ethernet starfire.ko

max_interrupt_work — Número máximo de eventos manejados por interrupción

mtu — MTU (todas las placas)

debug — Nivel de depuración (0-6)

rx_copybreak — Punto de ruptura de copia para copiar-solamente-pequeñas-estructuras.

intr_latency — Latencia de interrupción máxima en microsegundos

small_frames — Tamano máximo de estructuras que eluden la latencia de interrupción (0,64,128,256,512)

options — Descontinuado: Bits 0-3: tipo de medios, bit 17: full duplex

full_duplex — Descontinuado: Configuración de full-duplex forzada (0/1)

enable_hw_cksum — Activar/desactivar el soporte a la suma de verificación de hardware (0/1)

Broadcom Tigon3 tg3.ko

tg3_debug — Valor de activación de los mensajes de depuración Tigon3 bitmapped

ThunderLAN PCI tlan.ko

aui — ThunderLAN utiliza puerto(s) AUI (0-1)

duplex — configuración(es) ConThunderLAN duplex (0-predeterminado, 1-mitad, 2-completo)

speed — Configuración(es) ThunderLAN port speen (0,10,100)

debug — Máscara de depuración ThunderLAN

bbuf — ThunderLAN utiliza un buffer grande (0-1)

Tarjetas Ethernet PCI Digital 21x4x Tulip SMC EtherPower 10 PCI(8432T/8432BT) SMC EtherPower 10/100 PCI(9332DST) DEC EtherWorks 100/10 PCI(DE500-XA) DEC EtherWorks 10 PCI(DE450) DEC QSILVER's, Znyx 312 etherarray Allied Telesis LA100PCI-T Danpex EN-9400, Cogent EM110 tulip.ko ioio_port
Tarjetas Ethernet rápida PCI VIA Rhine con bien sea el VIA VT86c100A Rhine-II PCI o 3043 Rhine-I D-Link DFE-930-TX PCI 10/100 via-rhine.ko

max_interrupt_work — Número máximo de eventos VIA Rhine manejados por interrupción

debug — Nivel de depuración VIA Rhine (0-7)

rx_copybreak — punto de ruptura de copia de VIA Rhine para estructuras-solamente-pequeñas.

avoid_D3 — Evitar power state D3 (solución alternativa para BIOS dañados)

Tabla 41.2. Parámetros de módulos Ethernet

41.5.1. Utilización de Múltiples Tarjetas Ethernet

Puede utilizar múltiples tarjetas Ethernet en una sóla máquina. Para cada tarjeta debe existir un alias y posiblemente, líneas de options por cada tarjeta en /etc/modprobe.conf.

Para información adicional sobre el uso de más de una tarjeta Ethernet, consulte el Linux Ethernet-HOWTO online at http://www.redhat.com/mirrors/LDP/HOWTO/Ethernet-HOWTO.html.

41.5.2. El Módulo del canal de vinculación (Bonding)

Red Hat Enterprise Linux permite a los administradores enlazar NICs juntas en un único canal usando el módulo del kernel bonding y una interfaz de red especial, llamada una interfaz de canal de vinculación. La vinculación de canales permite que dos o más interfaces de red actúen como una incrementando simultáneamente el ancho de banda y proporcionando redundancia.

Para enlazar varias interfaces de red en un canal, el administrador debe seguir los pasos siguientes:

  1. Añada la siguiente línea a /etc/modprobe.conf:

    alias bond<N> bonding

    Reemplace <N> con el número de la interfaz, tal como 0. Para cada interfaz de canal vinculado configurado debe haber una entrada correspondiente en /etc/modprobe.conf.

  2. Configure una interfaz de canal de vinculado como se describe en la Sección 14.2.3, “Interfaces de unión de canales”.

  3. Para mejorar el rendimiento, ajuste las opciones de los módulos para asegurarse de cuál combinación funciona mejor. Preste especial atención a los parámetros miimon or arp_interval y arp_ip_target. Para obtener una lista de las opciones disponibles consulte la Sección 41.5.2.1, “Directivas del Módulo bonding.

  4. Después de probar coloque las opciones preferidas en /etc/modprobe.conf.

41.5.2.1. Directivas del Módulo bonding

Antes de terminar las configuraciones para el módulo bonding, es una buena idea evaluar cuales configuraciones funcionan mejor. Para hacer esto, abra un indicador de comandos como root y escriba:

tail -f /var/log/messages

Abra otro indicador de comandos y utilice el comando /sbin/insmod para cargar el módulo bonding con parámetros diferentes mientras se observan los mensajes del kernel para ver los errores.

El comando /sbin/insmod se emite en el formato siguiente:

 /sbin/insmod bond<N><parameter=value>

Reeplace <N> con el número para la interfaz vinculada. Reemplace <parameter=value> con una lista separada por espacios de los parámetros deseados para la interfaz.

Once satisfied with the performance of the bonding interface (and verifying that there are no errors), add the appropriate bonding module parameters to ifcfg-bond<N> (where <N> is the number of the interface). These parameters are set as BONDING_OPTS="<parameters>". For more information, refer to Sección 14.2.3, “Interfaces de unión de canales”.

Lo siguiente es una lista de los parámetros disponibles para el módulo bonding.

  • mode= — Especifica uno de cuatro políticas permitidas para el módulo bonding. Los valores aceptables para este parámetro son:

    0 — Configura una política de round-robin para la tolerancia de fallas y balanceo de cargas. Las transmisiones son recibidas y enviadas secuencialmente en cada interfaz esclava vinculada comenzando con la primera disponible.

    1 — Configura una política de respaldo activa para la tolerancia de fallas. Las transmisiones son recibidas y enviadas a través de la primera interfaz esclava vinculada disponible. Sólo se utiliza otra interfaz esclava vinculada si la interfaz esclava activa falla.

    2 — Configura una política XOR (o-exclusivo) para la tolerancia de fallas y el balanceo de cargas. Usando este método la interfaz coincide la dirección MAC de las peticiones entrantes con la dirección MAC de una de las NICs esclava. Una vez que se establece el enlace, las transmisiones son enviadas secuencialmente comenzando con la primera interfaz disponible.

    3 — Configura una política de difusión para la tolerancia de fallas. Las transmisiones son enviadas en todas las interfaces esclavas.

    4 — Configura una política de agregación de enlace dinámico IEEE 802.3ad. Crea grupos de agregación que comparten las mismas especificaciones de velocidad y duplex. Transmite y recibe en todos los esclavos en el agregador activo. Requiere de un switch que sea conforme con 802.3ad.

    5 — Configura una política de balanceo de carga de transmisión (Transmit Load Balancing, TLB) para la tolerancia de fallas y el balanceo de cargas. El tráfico saliente es distribuido de acuerdo a la carga actual en cada interfaz esclava. El esclavo actual recibe el tráfico entrante. Si el eslavo receptor falla, otro esclavo toma la dirección MAC del esclavo fallido.

    6 — Configura una política de balanceo de cargas activa (Active Load Balancing, ALB) para la tolerancia de fallas y el balanceo de cargas. Incluye el balanceo de cargas de transmisión y recepción para el tráfico IPV4. Se logra el balanceo de las cargas recibidas a través de la negociación ARP.

  • miimon= — Especifica (en milisegundos) la frecuencia en que ocurre la supervisión MII. Esto es útil si se requiere gran disponibilidad porque MII es utilizado para verificar que la NIC está activa. Para verificar que el controlador para un NIC particular es compatible con la herramienta MII, escriba el comando siguiente como root:

    ethtool <interface-name> | grep "Link detected:"

    En este comando, reemplace <interface-name> con el nombre de la interfaz del dispositivo, tal como eth0, no la interfaz bond (vinculada). Si se soporta MII, el comando devuelve:

    Enlace detectado: sí

    Si se está utilizando una interfaz vinculada para mayor disponibilidad, el módulo para cada NIC debe soportar MII.

    Colocando el valor a 0 (el valor por defecto), desactiva esta funcionalidad. Cuando configure este parámetro, un buen punto para comenzar es 100.

  • downdelay= — Especifica (en milisegundos) el tiempo a esperar después de la falla de un enlace antes de deshabilitar el enlace. El valor debe ser un múltiplo del valor especificado en el parámetro miimon. El valor es configurado a 0 por defecto, lo cual lo desactiva.

  • updelay= — Especifica (en milisegundos) la cantidad de tiempo a esperar antes de deshabilitar un enlace. El valor debe ser un múltiplo del valor especificado en el parámetro miimon. Por defecto, el valor es configurado a 0, lo cual lo desactiva.

  • arp_interval= — Especifica (en milisegundos) con qué frecuencia ocurre la supervisión ARP.

    Si utiliza esta configuración mientras se está en el mode0 o 2 (los dos modos de balanceo de cargas), el switche de la red debe estar configurado para distribuir paquetes uniformemente a través de las NICs. Para más información sobre cómo hacer esto, consulte

    /usr/share/doc/kernel-doc-<kernel-version>/Documentation/networking/ bonding.txt

    El valor es configurado a 0 por defecto, lo cual lo desactiva.

  • arp_ip_target= — Especifica la dirección IP objetivo de las peticiones ARP cuando está activado el parámetro arp_interval. Se pueden especificar hasta 16 direcciones IP en una lista separada por comas.

  • arp_validate= — validate source/distribution of ARP probes; default is none. Other valid values are active, backup, and all.

  • lacp_rate= — Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode. Possible values are:

    • slow or 0 — Default setting. This specifies that partners should transmit LACPDUs every 30 seconds.

    • fast or 1 — Specifies that partners should transmit LACPDUs every 1 second.

  • primary= — Especifica el nombre de la interfaz, tales como eth0, del dispositivo primario. El dispositivo primary es el primero de las interfaces vinculadas a utilizarse y no se abandona a menos que falle. Esta configuración es particularmente útil cuando un NIC en la interfaz vinculada es más rápido y, por lo tanto, capaz de manejar una carga más grande.

    Esta configuración sólo es válida cuando la interfaz de conexión está en el modo Copia de seguridad activa. Consulte

    /usr/share/doc/kernel-doc-<kernel-version>/Documentation/networking/ bonding.txt

    para mayor información

  • use_carrier= — Specifies whether or not miimon should use MII/ETHTOOL ioctls or netif_carrier_ok() to determine the link state. The netif_carrier_ok() relies on the device driver to maintains its state with netif_carrier_on/off; most device drivers support this function.

    The MII/ETHROOL ioctls tools utilize a deprecated calling sequence within the kernel. However, this is still configurable in case your device driver does not support netif_carrier_on/off.

    Valid values are:

    • 1 — Default setting. Enables the use of netif_carrier_ok().

    • 0 — Enables the use of MII/ETHTOOL ioctls.

    Sugerencia

    If bonding insists that the link is up when it should not be, it is possible that your network device driver does not support netif_carrier_on/off.

  • xmit_hash_policy — Selects the transmit hash policy used for slave selection in balance-xor and 802.3ad modes. Possible values are:

    • 0 or layer2 — Default setting. This option uses the XOR of hardware MAC addresses to generate the hash. The formula used is:

      (<source> <MAC> <XOR> <destination> <MAC>) <modulo slave count>
      

      This algorithm will place all traffic to a particular network peer on the same slave, and is 802.3ad compliant.

    • 1 or layer3+4 — Uses upper layer protocol information (when available) to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.

      The formula for unfragmented TCP and UDP packets used is:

      ((<source> <port> <XOR> <destination>) <XOR>
              ((<source> <IP> <XOR> <destination> <IP>) AND 0xffff)
                      <modulo slave count>
      

      For fragmented TCP or UDP packets and all other IP protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as the layer2 transmit hash policy.

      This policy intends to mimic the behavior of certain switches; particularly, Cisco switches with PFC2 as well as some Foundry and IBM products.

      The algorithm used by this policy is not 802.3ad compliant.

Importante

Es esencial que los parámetros arp_interval y arp_ip_target o miimon sean especificados. Si esto no se hace puede causar degradación del rendimiento de la red en el evento de que falle un enlace.

Consulte el siguiente archivo para obtner mayor información (observe que tiene que tener el paquete kernel-doc instalado para poder leer este archivo):

 /usr/share/doc/kernel-doc-<kernel-version>/Documentation/networking/ bonding.txt 

para instrucciones detalladas sobre las interfaces vinculadas.

41.6. Recursos adicionales

Para más información en los módulos del kernel y sus utilidades, remítase a las siguientes fuentes de información.

41.6.1. Documentación instalada

  • Página del manual de lsmod — descripción y explicación de su salida.

  • Página del manual de insmod — descripción y listado de las opciones de la línea de comandos.

  • Página del manual de modprobe — descripción y listado de las opciones de la línea de comandos.

  • Página del manual de rmmod — descripción y listado de las opciones de la línea de comandos.

  • Página del manual de modinfo — descripción y listado de las opciones de la línea de comandos.

  • /usr/share/doc/kernel-doc-<version>/Documentation/kbuild/modules.txt — como compilar y usar módulos del kernel. Observe que tiene que tener el paquete kernel-doc instalado para poder leer este archivo.

41.6.2. Sitios Web útiles



[9] Un controlador es un tipo de software que ayuda a Linux a usar un dispositivo determinado de hardware. Sin el controlador de dispositivos, el kernel no se puede comunicar con los dispositivos conectados.

Parte VII. Seguridad y autenticación

Ya sea que los administradores necesiten asegurar los sistemas de misión crítica, servicios o datos, Red Hat Enterprise Linux proporciona una variedad de herramientas y métodos que pueden formar parte de una estrategia de seguridad completa.

Este capítulo proporciona una introducción general acerca de la seguridad, especialmente en las particularidades de los sistemas Red Hat Enterprise Linux. Proporciona información conceptual sobre las áreas de evaluaciones de seguridad, vulnerabilidades comunes, intrusión y respuesta a incidentes. También proporciona información de configuración específica y conceptual para mejorar la seguridad en las estaciones de trabajo, servidores, VPN, cortafuegos y otras implementaciones utilizando SELinux.

Este capítulo asume un conocimiento básico de seguridad informática y, consecuentemente, cubre someramente prácticas comunes de seguridad como el control de acceso físico, cumplimiento de procedimientos y políticas, auditorías, etc. En donde sea apropiado, se harán referencias a recursos externos para esta y otra información relacionada.

Tabla de contenidos

42. Generalidades concernientes a la seguridad
42.1. Evaluación de vulnerabilidad
42.1.1. Pensando como el enemigo
42.1.2. Definición de la evaluación y pruebas
42.1.3. Evaluación de herramientas
42.2. Ataques y vulnerabilidades
42.2.1. Una breve historia sobre los hackers
42.2.2. Amenazas a la Seguridad de la red
42.2.3. Amenazas a la seguridad de servidores
42.2.4. Amenazas a la seguridad de estaciones de trabajo y PCs del hogar
42.3. Ataques y agresiones comunes
42.4. Actualizaciones de seguridad
42.4.1. Actualización de paquetes
43. Aseguramiento de su Red
43.1. Seguridad en las estaciones de trabajo
43.1.1. Evaluando la seguridad en la estación de trabajo
43.1.2. Seguridad del BIOS y del gestor de arranque
43.1.3. Seguridad de contraseñas
43.1.4. Controles administrativos
43.1.5. Servicios de red disponibles
43.1.6. Cortafuegos personales
43.1.7. Herramientas de mejoramiento de la seguridad
43.2. Seguridad de servidores
43.2.1. Asegurando los servicios con TCP Wrappers y xinetd
43.2.2. Protección de Portmap
43.2.3. Protección de NIS
43.2.4. Protección de NFS
43.2.5. Protegiendo el servidor Apache HTTP
43.2.6. Protección de FTP
43.2.7. Asegurando Sendmail
43.2.8. Verificar cuáles puertos están escuchando
43.3. Single Sign-on (SSO)
43.3.1. Introducción
43.3.2. Iniciando con su nueva tarjeta inteligente
43.3.3. Cómo funciona la inscripción de las tarjetas inteligentes
43.3.4. Cómo funciona el registro de las tarjetas inteligentes
43.3.5. Configuración de Firefox para utilizar Kerberos con SSO
43.4. Pluggable Authentication Modules (PAM)
43.4.1. Las ventajas de PAM
43.4.2. archivos de configuración PAM
43.4.3. Formato del archivo de configuración PAM
43.4.4. Muestras de archivos de configuración PAM
43.4.5. Creación de módulos PAM
43.4.6. PAM y el caché de credenciales administrativas
43.4.7. PAM y propiedad del dispositivo
43.4.8. Recursos adicionales
43.5. TCP Wrappers y xinetd
43.5.1. Wrappers TCP
43.5.2. Archivos de configuración de Wrappers TCP
43.5.3. xinetd
43.5.4. Archivos de configuración de xinetd
43.5.5. Recursos adicionales
43.6. Redes privadas virtuales (VPNs)
43.6.1. ¿Cómo funciona un VPN?
43.6.2. VPNs y Red Hat Enterprise Linux
43.6.3. IPsec
43.6.4. Creando una conexión IPsec
43.6.5. Instalación de IPsec
43.6.6. Configuración IPsec de host-a-host
43.6.7. Configuración de IPsec de red-a-red
43.6.8. Iniciando y deteniendo conexiones IPsec
43.7. IPTables
43.7.1. Filtrado de paquetes
43.7.2. Diferencias entre IPTables y IPChains
43.7.3. Opciones de comandos para IPTables
43.7.4. Guardando reglas IPTables
43.7.5. Scripts de control de IPTables
43.7.6. IPTables y IPv6
43.7.7. Recursos adicionales
44. Seguridad y SELinux
44.1. Mecanismos de Control de Acceso (ACMs)
44.1.1. Control de Acceso Discrecional (DAC)
44.1.2. Control de Acceso Mandatorio (MAC)
44.1.3. Control de Acceso basado en Roles (RBAC)
44.1.4. Seguridad Multi-Nivel (MLS)
44.2. Introducción a SELinux
44.2.1. Sinopsis de SELinux
44.2.2. Archivos relacionados con SELinux
44.2.3. Recursos adicionales
44.3. Antecedentes e historia de SELinux
44.4. Multi-Category Security (MCS)
44.4.1. Introducción
44.4.2. Aplicaciones para Seguridad Multi-Categoría
44.4.3. Contextos de Seguridad de SELinux
44.5. Getting Started with Multi-Category Security (MCS)
44.5.1. Introduction
44.5.2. Comparing SELinux and Standard Linux User Identities
44.5.3. Configuring Categories
44.5.4. Assigning Categories to Users
44.5.5. Assigning Categories to Files
44.6. Seguridad Multi-Nivel (MLS)
44.6.1. ¿Por qué Multi-Nivel?
44.6.2. Niveles de Seguridad, Objetos y Sujetos
44.6.3. Política MLS
44.6.4. Certificación LSPP
44.7. Sinopsis de las Políticas de SELinux
44.7.1. ¿Qué es la Política SELinux?
44.7.2. ¿Dónde se encuentra la Política?
44.7.3. El Papel de la Política durante el Proceso de Arranque
44.7.4. Clases de Objetos y Permisos
44.8. Sinopsis de la Política de Objetivos
44.8.1. ¿Qué es la Política Objetivo?
44.8.2. Archivos y Directorios de la Política Objetivo
44.8.3. Usuarios y Roles en la Política Objetivo
45. Trabajar con SELinux
45.1. Control de Usuario Final de SELinux
45.1.1. Mover y Copiar Archivos
45.1.2. Verificar el Contexto de Seguridad de un Proceso, Usuario u Objeto de Archivo
45.1.3. Nuevas Etiquetas para un Archivo o Directorio
45.1.4. Creación de Archivos que Retienen Contextos de Seguridad
45.2. Controles administrativos de SELinux
45.2.1. Ver el Estado de SELinux
45.2.2. Creación de Etiquetas Nuevas para Sistemas de Archivos
45.2.3. Administración de Directorios Principales NFS
45.2.4. Otorgar Acceso a un Directorio o a un Arbol
45.2.5. Copias de Seguridad y Restauración del Sistema
45.2.6. Activación o Desactivación del Refuerzo
45.2.7. Activar o Desactivar SELinux
45.2.8. Cambio de la Política
45.2.9. Especificación del Contexto de Seguridad del Sistema de Archivos Entero
45.2.10. Cambio de la Categoria de Seguridad de un Archivo o Usuario
45.2.11. Ejecución de un Comando en un Contexto de Seguridad Especifico
45.2.12. Comandos Utiles para Scripts
45.2.13. Cambio a un Rol Diferente
45.2.14. Cuando Reiniciar
45.3. Control Analista de SELinux
45.3.1. Activación de la Auditoría de Kernel
45.3.2. Volcado y Vista de Registros
46. Customizing SELinux Policy
46.1. Introduction
46.1.1. Modular Policy
46.2. Building a Local Policy Module
46.2.1. Using audit2allow to Build a Local Policy Module
46.2.2. Analyzing the Type Enforcement (TE) File
46.2.3. Loading the Policy Package
47. Referencias

Capítulo 42. Generalidades concernientes a la seguridad

Debido a la creciente confianza que se tiene en las poderosas computadoras conectadas en redes para ayudar a los negocios y para llevar un seguimiento de nuestra información personal, las industrias se forman alrededor de las prácticas de seguridad de la computación y de las redes. Las corporaciones solicitan el conocimiento y las habilidades de los expertos en seguridad para auditar los sistemas y ajustar soluciones que satisfagan los requerimientos operativos de la organización. Ya que la mayoría de las organizaciones son dinámicas por naturaleza, con empleados que acceden a los recursos informáticos de la organización tanto local como remotamente, la necesidad de ambientes computacionales seguros es cada vez más relevante.

Desafortunadamente, la mayoría de las organizaciones (así como los usuarios individuales) consideran la seguridad en un segundo plano, dándole mayor importancia al poder, productividad y preocupaciones presupuestarias. La implementación adecuada de la seguridad es a menudo realizada postmortem — después de que ocurre una intrusión no autorizada. Los expertos de seguridad consideran que el establecimiento de medidas adecuadas antes de conectar un sitio a una red insegura tal como la Internet, es una forma efectiva de frustrar la mayoría de los intentos de intrusión.

42.1. Evaluación de vulnerabilidad

Con el tiempo suficiente, los recursos y la motivación, un intruso puede violar casi cualquier sistema. Al final del día, todos los procedimientos de seguridad y la tecnología disponible actualmente no pueden garantizar que sus sistemas estén seguros de un ataque. Los enrutadores lo pueden ayudar a asegurar sus puertas de enlace (gateways) a la Internet. Los cortafuegos (firewalls) le permiten asegurar el borde de su red. Las redes privadas virtuales pueden pasar con seguridad sus datos en un flujo encriptado. Los sistemas de detección de intrusos pueden advertirlo de actividades maliciosas. Sin embargo, el éxito de cada una de estas tecnologías depende de un número de variables, incluyendo:

  • La experiencia del personal responsable de la configuración, supervisión y mantenimiento de las tecnologías.

  • La habilidad de remendar y actualizar servicios y kernels rápida y eficientemente.

  • La habilidad de aquellos responsables de mantener vigilancia constante sobre la red.

Dado el estado dinámico de los sistemas de datos y tecnologías, asegurar sus recursos corporativos puede ser bien complejo. Debido a esta complejidad, puede ser difícil encontrar recursos expertos para todos sus sistemas. Mientras que es posible tener personal con conocimientos en muchas áreas de seguridad de información a un nivel alto, es difícil mantener personal que sea experto en más de unas pocas áreas particulares. Esto se debe principalmente a que cada área en particular de seguridad de la información requiere constante atención y foco. La seguridad de información no se queda quieta.

42.1.1. Pensando como el enemigo

Imagine que usted administra una red corporativa. Tales redes usualmente estan formadas de sistemas operativos, aplicaciones, servidores, monitores de red, cortafuegos, sistemas de detección de intrusos y más. Ahora imagínese el tratar de mantenerse actualizado con cada uno de estos. Dada la complejidad de los ambientes de software y de redes de hoy, los ataques y los bugs son una posibilidad constante. El tratar de mantenerse actualizado con las mejoras y actualizaciones para la red completa puede ser una tarea abrumadora cuando se trata de una organización grande y con sistemas heterogéneos.

Combine los requerimientos de experiencia con la tarea de mantenerse actualizado y es inevitable que incidentes adversos ocurrirán, habrá sistemas violados, se perderán datos y se interrumpe el servicio.

Para incrementar su tecnología de seguridad y ayudar a proteger los sistemas, redes y datos, piense como un cyberpirata (cracker) y estime la seguridad de los sistemas revisando sus debilidades. Las evaluaciones de vulnerabilidad preventivas contra sus propios sistemas y recursos de red pueden revelar problemas potenciales que se pueden solucionar antes de que un cyberpirata los descubra.

Si usted tuviese que realizar una evaluación de la vulnerabilidad de su hogar, probablemente verificará cada puerta de su casa para ver si estas se encuentran cerradas y aseguradas. Quizás también verificará cada ventana, asegurándose de que estas se encuentren bien cerradas y con seguro. Este mismo concepto aplica a los sistemas, redes y datos electrónicos. Los usuarios maliciosos son los ladrones y vándalos de sus datos. Fíjese en sus herramientas, mentalidad y motivaciones y podrá responder rápidamente a sus acciones.

42.1.2. Definición de la evaluación y pruebas

Las evaluaciones de vulnerabilidad se pueden dividir en dos grandes categorias: Desde afuera viendo hacia adentro y Desde adentro viendo alrededor.

Cuando se lleva a cabo una evaluación de vulnerabilidad desde el exterior, usted está tratando de comprometer sus sistemas desde afuera. Al posicionarse desde afuera de la compañía puede ver las cosas desde el punto de vista del intruso. Usted ve lo que un intruso ve — direcciones IP públicas, sistemas en su DMZ, las interfaces externas de su cortafuegos y más. DMZ viene de "zona desmilitarizada" lo que corresponde a un computador o a una pequeña subred que se coloca entre la red confiable interna, tal como la LAN corporativa, y una red externa no confiable, tal como la Internet. Típicamente, la DMZ contiene dispositivos accesibles al tráfico de la Internet, tal como servidores Web (HTTP), FTP, SMTP (correo electrónico) y servidores DNS.

Cuando realiza una evaluación de vulnerabilidad desde adentro, de alguna forma usted tiene una ventaja puesto que ya está adentro y su estatus es elevado y de confianza. Este es el punto de vista suyo y de sus compañeros de trabajo una vez que se conectan a los sistemas. Puede ver los servidores de impresión, servidores de archivos, bases de datos y otros recursos.

Hay diferencias importantes entre estos dos tipos de evaluación de vulnerabilidad. Por el hecho de ser parte de la compañía, usted tiene mayores privilegios que cualquier persona del exterior. Hoy día, en la mayoría de las organizaciones, la seguridad es configurada para mantener a los intrusos afuera. Se hace muy poco para asegurar la parte interna de la organización (tales como cortafuegos departamentales, controles de acceso a nivel de usuario, procedimientos de autenticación para recursos internos y más). Típicamente, hay muchos más recursos cuando se mira desde adentro, ya que la mayoría de los recursos son internos a la compañía. Una vez que se encuentra fuera de la compañía, inmediatamente se le da la condición de no fiable. Los sistemas y recursos que tiene disponibles son generalmente mucho más limitados.

Considere la diferencia entre las evaluaciones de vulnerabilidad y las pruebas de penetración. Piense en una evaluación de vulnerabilidad como el primer paso de una prueba de penetración. La información reunida a partir de la evaluación será usada en las pruebas. Mientras que la evaluación de vulnerabilidad busca huecos y vulnerabilidades potenciales, las pruebas de penetración tratan de explotar los resultados.

El acceso a la infraestructura de red es un proceso dinámico. La seguridad, tanto de información como física, es dinámica. Al realizar una evaluación, se tiene una vista general, la cual puede arrojar falsos positivos y falsos negativos.

Los administradores de seguridad son buenos en la medida que también lo sean las herramientas que usen y el conocimiento que posean. Tome por ejemplo cualquier herramienta de evaluación disponible en el mercado y ejecútela en su sistema. Es casi que garantizado que encontrará al menos algunos falsos positivos. Bien sea por un error del programa o del usuario, el resultado es el mismo. La herramienta puede encontrar vulnerabilidades que en realidad no existen (falsos positivos), o peor aún, la herramienta puede que no encuentre vulnerabilidades que actualmente si existen (falsos negativos).

Ahora que ya estan definidas las diferencias entre evaluaciones de vulnerabilidad y pruebas de penetración, es una buena idea reunir las conclusiones de la evaluación y revisarlas cuidadosamente antes de llevar a cabo una prueba de penetración como parte de sus nuevos buenos hábitos.

Aviso

Intentar explotar las vulnerabilidades sobre recursos en producción puede tener resultados adversos a la productividad y eficiencia de sus sistemas y redes.

A continuación se presenta una lista con algunas ventajas de llevar a cabo evaluaciones de vulnerabilidad.

  • Crea un enfoque proactivo en la seguridad de la información

  • Se pueden encontrar los puntos de explotación potenciales antes de que un intruso los encuentre

  • Genera sistemas actualizados y con las últimas revisiones de software

  • Promociona el crecimiento y ayuda en el desarrollo de la experiencia del personal

  • Reduce las pérdidas financieras y la publicidad negativa

42.1.2.1. Establecimiento de una metodología

Para facilitar en la selección de herramientas para las evaluaciones de vulnerabilidad, es útil establecer una metodología de evaluación de vulnerabilidad. Desafortunadamente, no existe actualmente una metodología predefinida o aprobada por la industria; sin embargo, el sentido común y los buenos hábitos pueden actuar como una guía completa.

¿Cuál es el objetivo? Se trata de sólo un servidor, o de la red completa y todo lo que esta dentro de ella? Somos internos o externos a la compañía? Las respuestas a estas preguntas son importantes pues le ayudaran a determinar no solamente cuáles herramientas seleccionar sino también la forma en que serán usadas.

Para aprender un poco más sobre el establecimiento de metodologías, refiérase a los siguientes sitios web:

42.1.3. Evaluación de herramientas

Una evaluación típica puede comenzar usando alguna herramienta para reunir información. Cuando se esté evaluando la red completa, haga un dibujo de la red primero para identificar las máquinas que estan en ejecución. Una vez identificadas, examine cada máquina individualmente. Para enfocarse en esas máquinas se requiere de otro conjunto de herramientas. Conocer cuál herramienta utilizar puede ser el paso más importante al encontrar vulnerabilidades.

Así como en todos los aspectos de la vida, hay muchas herramientas diferentes que pueden hacer el mismo trabajo. Este concepto también aplica al realizar evaluaciones de vulnerabilidad. Hay herramientas específicas al sistema operativo, aplicaciones y hasta redes (basadas en los protocolos utilizados). Algunas herramientas son gratuitas, mientras que otras no. Algunas herramientas son intuitivas y fáciles de utilizar, mientras que otras son enigmáticas y muy mal documentadas pero tienen características que las otras no.

Encontrar la herramienta adecuada puede ser una tarea abrumadora. Al final, la experiencia cuenta. Si es posible, configure un laboratorio de pruebas y evalue tantas herramientas como pueda, anotando las fortalezas y debilidades de cada una. Revise el archivo README o la página man de la herramienta. Además revise la internet para más información, tales como artículos, guías paso a paso, o inclusive listas de correo específicas a la herramienta.

Las herramientas que se discuten a continuación son sólo una pequeña muestra de las herramientas disponibles.

42.1.3.1. Explorar hosts con Nmap

Nmap es una popular herramienta incluida en Red Hat Enterprise Linux que puede ser usada para determinar la distribución de la red. Nmap ha estado disponible por muchos años y es probablemente la herramienta más usada para obtener información. Se incluye una página man excelente con una descripción detallada de sus opciones y uso. Los administradores pueden usar Nmap en una red para encontrar sistemas host y puertos abiertos en esos sistemas.

Nmap es un buen primer paso para una evaluación de vulnerabilidad. Puede mapear todos los hosts dentro de la red y hasta puede pasar una opción que le permite tratar de identificar el sistema operativo que se está ejecutando en un host en particular. Nmap es un buen fundamento para establecer una política de uso de servicios seguros y detener servicios que no se esten usando.

42.1.3.1.1. Uso de Nmap

Nmap se puede ejecutar desde un intérprete de comandos ejecutando el comando nmap seguido del nombre o la dirección IP de la máquina que desea explorar.

nmap foo.example.com

Los resultados de la exploración (lo cual puede tomar varios minutos, dependiendo de la ubicación de la máquina) se deberían ver similar a lo siguiente:

Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

Nmap prueba los puertos de comunicación de red más comunes por servicios en espera o escuchando. Este conocimiento puede ser útil para un administrador que desea cerrar servicios que no sean necesarios o que no se estén utilizando.

Para más información sobre el uso de Nmap, refiérase a la página oficial en la siguiente URL:

http://www.insecure.org/

42.1.3.2. Nessus

Nessus es un explorador de seguridad de servicio completo. La arquitectura de extensiones de Nessus permite a los usuarios personalizarlo para sus sistemas y redes. Como cualquier otro explorador, Nessus es bueno sólo si la base de datos de firmas es buena. Afortunadamente, Nessus es actualizado con frecuencia. Esta caracterizado por tener facilidades completas de informes, exploración de hosts y búsquedas de vulnerabilidades en tiempo real. Recuerde que pueden existir falsos positivos y falsos negativos, aún en una herramienta tan poderosa y tan actualizada como Nessus.

Nota

Nessus no está incluido y no es soportado en Red Hat Enterprise Linux. Ha sido incluido en este documento como una referencia a los usuarios que estén interesados en usar esta aplicación.

Para más información sobre el uso de Nessus, refiérase a la página oficial en la siguiente URL:

http://www.nessus.org/

42.1.3.3. Nikto

Nikto es un escaneador de scripts CGI excelente. Nikto tiene la capacidad de no sólo probar vulnerabilidades de CGI sino también que lo hace de forma evasiva, evitando los sistemas de detección de intrusos. Viene con una documentación muy completa, la cual es recomendable revisar antes de ejecutar el programa. Si sus servidores web están sirviendo scripts CGI, Nikto puede ser un recurso excelente para chequear la seguridad de estos servidores.

Nota

Nikto no está incluido y no es soportado en Red Hat Enterprise Linux. Ha sido incluido en este documento como una referencia a los usuarios que estén interesados en usar esta aplicación.

Se puede encontrar más información sobre Nikto en el siguiente URL:

http://www.cirt.net/code/nikto.shtml

42.1.3.4. VLAD the Scanner

VLAD es un explorador desarrollado por el equipo RAZOR en Bindview, Inc. que puede ser utilizado para verificar vulnerabilidades. comunes de seguridad de la lista Top Ten de SANS (problemas de SNMP, problemas de compartición de archivos, etc.). Aún cuando no tiene tantas funcionalidades como Nessus, vale la pena investigar VLAD.

Nota

VLAD no está incluido y no es soportado en Red Hat Enterprise Linux. Ha sido incluido en este documento como una referencia a los usuarios que puedan estar interesados en utilizar esta aplicación.

Se puede encontrar más información sobre VLAD en el sitio web del equipo RAZOR en el siguiente URL:

http://www.bindview.com/Support/Razor/Utilities/

42.1.3.5. Anticipándose a sus futuras necesidades

Hay muchas herramientas disponibles, dependiendo de su objetivo y recursos. Existen herramientas para redes inalámbricas, redes Novell, sistemas Windows, sistemas Linux y más. Otra parte esencial al realizar evaluaciones de seguridad puede incluir revisar la seguridad física, selección de personal o evaluaciones de red de voz/PBX. Hay algunos nuevos conceptos tales como war walking — explorar el perímetro de la estructura física de su corporación por vulnerabilidades de red inalámbrica — que también puede investigar y, si lo requiere, incorporar en sus evaluaciones. La imaginación y exposición son los únicos límites al planear y conducir una evaluación de vulnerabilidades.

42.2. Ataques y vulnerabilidades

Para poder planear e implementar una buena estrategia de seguridad, primero debe tener en cuenta algunos de los problemas que un atacante motivado y determinado explota para comprometer sus sistemas. Pero antes de detallar estos problemas, debemos definir la terminología usada para identificar un atacante.

42.2.1. Una breve historia sobre los hackers

El significado moderno del término hacker tiene sus origenes en los años 60 y en el Club de Modelaje de Trenes del Instituto de Tecnología de Massachusetts (MIT), el cual diseñaba conjuntos de trenes de gran escala y detalle. Hacker fue el nombre usado para nombrar aquellos miembros del club que descubrían un truco brillante o que resolvían un problema muy complicado.

Desde ese momento el término hacker se ha utilizado para describir desde un aficionado a las computadoras hasta un programador virtuoso. Un rasgo característico de un hacker es su disposición de explorar en detalle cómo funcionan los sistemas de computación con poca o ninguna motivación externa. Los desarrolladores de software de la comunidad de Código Abierto (Open Source), a menudo se consideran a si mismos y a sus colegas como hackers, como una forma de respeto.

Generalmente, los hackers siguen una forma de ética de hackers. Ésta declara que la búsqueda de información y experiencia es esencial y que compartir ese conocimiento es el compromiso de todo hacker con la comunidad. Durante esa búsqueda de conocimiento, algunos hackers disfrutan los retos académicos de burlar los controles de seguridad en sistemas de computación. Por esta razón, la prensa usualmente utiliza este término para describir aquellos que acceden ilegalmente a sistemas y redes con intenciones maliciosas o criminales. El término más adecuado para este tipo de hacker de computadoras es cracker o maleante informático (también se les conoce como pirata informático, ciberpirata, etc.) — un término creado por los hackers en la mitad de los 80 para diferenciar a las dos comunidades.

42.2.1.1. Escalas de grises

Hay varios grupos distinto dentro de la comunidad de individuos que intentan encontrar y explotar las vulnerabilidades en sistemas y redes. Estos grupos se describen por el color del sombrero que ellos "usan" cuando realizan sus investigaciones de seguridad. El color es un indicativo de su intención.

Un hacker de sombrero blanco es aquel que prueba sistemas y redes para examinar su rendimiento y determinar que tan vulnerables son éstos ante un intruso. Usualmente, los hackers de sombrero blanco tratan de violar sus propios sistemas o los sistemas de un cliente que los ha empleado para propósitos de auditoría de seguridad. Los investigadores de seguridad y los consultores de seguridad profesional son dos ejemplos de hackers de sombrero blanco.

Un hacker de sombrero negro es sinónimo de un cracker. Generalmente, los crackers están menos enfocados a la programación y al lado de académico de violar un sistema. Con frecuencia los crackers utilizan programas especializados para violar vulnerabilidades conocidas en los sistemas para así descubrir información confidencial para beneficio personal o para producir daños a un sistema o a una red.

Por otro lado, un hacker de sombrero gris, tiene las habilidades e intenciones de un hacker de sombrero blanco pero en la mayoría de las situaciones utiliza ese conocimiento para propósitos menos nobles. Un hacker de sombrero gris se puede ver como un hacker de sombrero blanco que usa un sombrero negro para ejecutar su propia agenda.

Los hackers de sombrero gris usualmente se suscriben a otra forma de código ético que señala que es aceptable entrar en un sistema siempre y cuando el hacker no cometa robo o viole la confidencialidad. Sin embargo, otros argumentan que el sólo hecho de violar un sistema es por sí mismo anti-ético.

No importa cual sea la intención, es importante conocer las debilidades que un pirata intentará explotar. El resto del capítulo se basará en estos problemas.

42.2.2. Amenazas a la Seguridad de la red

Los malos hábitos cuando se configuran los siguientes aspectos de una red pueden incrementar los riesgos de ataques.

42.2.2.1. Arquitecturas inseguras

Una red mal configurada es un punto de entrada para usuarios no autorizados. Al dejar una red local abierta, confiable, vulnerable a la inseguridad de la Internet, es como dejar una puerta abierta en un vecindario con alta criminalidad — puede que no ocurra nada durante un cierto tiempo, pero eventualmente alguien intentará aprovecharse de la oportunidad.

42.2.2.1.1. Redes de difusión

Los administradores de sistemas a menudo fallan al darse cuenta de la importancia del hardware de la red en sus esquemas de seguridad. El hardware simple, como concentradores y enrutadores, a menudo se basa en broadcast (difusión) o en el principio de sin-interruptores; esto es, cada vez que un nodo transmite datos a través de la red a un nodo recipiente, el concentrador o enrutador hace una difusión de los paquetes de datos hasta que el nodo recipiente recibe y procesa los datos. Este método es el más vulnerable para hacer engaños de direcciones (spoofing) al protocolo de resolución de direcciones (arp) o control de acceso a la media (MAC) tanto por intrusos externos como por usuarios no autorizados.

42.2.2.1.2. Servidores centralizados

Otra falla potencial de redes es el uso de computación centralizada. Una forma común de reducir costos para muchos negocios, es el de consolidar todos los servicios a una sola máquina poderosa. Esto puede ser conveniente porque es fácil de manejar y cuesta considerablemente menos que una configuración de múltiples servidores. Sin embargo, un servidor centralizado introduce un punto único de falla en la red. Si el servidor central está comprometido, puede dejar la red totalmente inútil o peor aún, sensible a la manipulación o robo de datos. En estas situaciones un servidor central se convierte en una puerta abierta, permitiendo el acceso a la red completa.

42.2.3. Amenazas a la seguridad de servidores

La seguridad de servidores es tan importante como la seguridad de la red debido a que los servidores usualmente contienen una gran cantidad de información vital de la organización. Si un servidor está comprometido, todos sus contenidos pueden estar disponibles para que un pirata los manipule o robe a su gusto. Las siguientes secciones detallan algunos de los problemas más importantes.

42.2.3.1. Servicios inutilizados y puertos abiertos

Una instalación completa de Red Hat Enterprise Linux contiene más de 1000 paquetes de aplicaciones y bibliotecas. Sin embargo, la mayoría de los administradores de servidores optan por no instalar todos los paquetes de la distribución, prefiriendo una instalación de paquetes base que incluye varias aplicaciones para servidores.

42.2.3.2. Servicios sin sus parches

La mayoría de las aplicaciones de servidores incluidas en la instalación por defecto, son piezas de software robustas y sólidas que ya han sido probadas. Estas han sido usadas en ambientes de producción por varios años y su código ha sido refinado en detalle y muchos de los errores han sido encontrados y reparados.

Sin embargo, no hay tal cosa como un software sin errores y siempre hay espacio para mejorar o refinarlo. Más aún, el nuevo software usualmente no es probado tan rigurosamente como uno se esperaría, debido a su reciente llegada al ambiente de producción o porque quizás no es tan popular como otras aplicaciones de servidores.

Los desarrolladores y administradores de sistemas a menudo encuentran fallas (bugs) en las aplicaciones de servidores y publican la información de la falla en sitios webs de seguimiento de errores y seguridad, tales como la lista de correo Bugtraq (http://www.securityfocus.com) o al sitio web del Equipo de Respuestas a Emergencias de Computación (Computer Emergency Response Team, CERT) (http://www.cert.org). Aún cuando estos mecanismos constituyen una forma efectiva de alertar a la comunidad sobre vulnerabilidades de seguridad, depende de los administradores de sistemas el aplicar los parches de sistemas a tiempo. Esto es particularmente cierto puesto que los crackers tienen acceso a las mismas fuentes e intentarán utilizar esta información para violar sistemas que no hayan sido emparchados. Una buena administración de sistemas requiere vigilancia, seguimiento constante de errores y un mantenimiento de sistemas apropiado para asegurar un ambiente computacional seguro.

Consulte el Sección 42.4, “Actualizaciones de seguridad” para obtener mayor información sobre cómo mantener el sistema actualizado.

42.2.3.3. Administración desatendida

Una de las amenazas más grandes a la seguridad de los servidores son los administradores distraídos que olvidan remendar sus sistemas. De acuerdo al Instituto de Seguridad y Administración de Sistemas de Redes (System Administration Network and Security Institute, SANS), la causa primaria de la vulnerabilidad de seguridad de los sistemas es «asignar personal poco entrenado para mantener la seguridad y no proporcionar ni el entrenamiento ni el tiempo para permitir que ejecuten su trabajo»[10] Esto aplica tanto a los administradores nuevos como a aquellos demasiado confiados o poco motivados.

Algunos administradores fallan en emparchar sus servidores y estaciones de trabajo, mientras que otros fallan en leer los mensajes del registro de eventos del kernel del sistema o tráfico de la red. Otro error común es dejar las contraseñas o llaves a servicios sin modificar. Por ejemplo, algunas bases de datos tienen contraseñas administrativas por defecto porque sus desarrolladores asumen que el administrador de sistemas cambiará estas contraseñas inmediátamente luego de la instalación. Si un administrador de bases de datos no cambia las contraseñas, hasta un cracker sin mucha experiencia puede utilizar una contraseña conocida por todo el mundo para ganar acceso con privilegios administrativos a la bases de datos. Estos son sólo unos ejemplos de como una administración descuidada puede llevar a servidores comprometidos.

42.2.3.4. Servicios intrínsecamente inseguros

Aún hasta la organización más atenta y vigilante puede ser victima de vulnerabilidades si los servicios de red que seleccionen son intrínsecamente inseguros. Por ejemplo, hay muchos servicios desarrollados bajo la suposición de que serían usados en una red confiable; sin embargo, esta supuesto falla tan pronto como el servicio se vuelve disponible sobre la Internet — la cual es por sí misma insegura.

Una categoría de servicios de red inseguros son aquellos que requieren nombres y contraseñas de usuario sin encriptar para la autenticación.Telnet y FTP son dos de estos servicios. Un software de huzmeo de paquetes que esté monitoreando el tráfico entre un usuario remoto y tal servicio, puede fácilmente robarse los nombres de usuario y contraseña.

Tales servicios pueden también ser presa fácil de lo que en términos de seguridad se conoce como un ataque de hombre en el medio. En este tipo de ataque, un pirata redirige el tráfico de la red a que apunte a su máquina en vez del servidor destino. Una vez que alguien abre una sesión remota con el servidor, la máquina del atacante actua como un conductor invisible, quedándose tranquilamente capturando la información entre el servicio remoto y el usuario inocente. De esta forma un pirata puede reunir contraseñas administrativas y datos sin que el servidor o el usuario se den cuenta.

En otro categoría de servicios inseguros se incluyen los sistemas de archivos de red y servicios de información tales como NFS o NIS, los cuales son desarrollados específicamente para ser usados en una LAN pero que son, desafortunadamente, extendidos para incluir WANs (para los usuarios remotos). NFS, por defecto, no tiene ningún tipo de autenticación o mecanismos de seguridad configurado para prevenir que un pirata monte un directorio compartido NFS y a partir de allí acceder a cualquier cosa dentro de él. NIS también tiene información vital que debe ser conocida por cada computador de la red, incluyendo contraseñas y permisos de archivos, dentro de una base de datos de texto plano ACSII o DBM (derivado de ASCII). Un cracker que gana acceso a esta base de datos puede tener acceso a todas las cuentas de usuarios en la red, incluyendo la cuenta del administrador.

42.2.4. Amenazas a la seguridad de estaciones de trabajo y PCs del hogar

Las estaciones de trabajo y PCs del hogar a menudo no son tan susceptibles a ataques como las redes o servidores, pero puesto que a menudo estas contienen información confidencial, tales como información de tarjetas de credito, pueden ser blancos para los crackers de sistemas. Las estaciones de trabajo también pueden ser manipuladas sin que el usuario se de cuenta por un atacante y ser utilizadas como máquinas «esclavas» en ataques coordinados. Por estas razones, conociendo las vulnerabilidades de una estación de trabajo puede ahorrar a los usuarios el dolor de cabeza de reinstalar el sistema operativo o peor aún, recuperarse del robo de datos.

42.2.4.1. Malas contraseñas

42.2.4.2. Aplicaciones cliente vulnerables

A pesar de que un administrador puede tener un servidor completamente actualizado y seguro, eso no significa que un usuario remoto esté seguro cuando accese al mismo. Por ejemplo, si el servidor ofrece servicios Telnet o FTP sobre una red pública, un atacante puede capturar el texto plano de los nombres de usuarios y contraseñas cuando estos son transmitidos a través de la red y luego usar la información de la cuenta para acceder a la estación de trabajo remota del usuario.

Aún cuando se utilicen protocolos seguros, tales como SSH, un usuario remoto puede ser vulnerable a ciertos ataques si no mantienen sus aplicaciones cliente actualizadas. Por ejemplo, clientes v.1 SSH son vulnerables a un ataque de redireccionamiento de X desde un servidor SSH malicioso. Una vez conectado al servidor, el atacante puede de manera cuidadosa capturar los golpes de teclas y los clics del ratón hechos por el cliente sobre la red. Este problema se reparó con el protocolo v.2 SSH, pero depende del usuario hacer un seguimiento de qué aplicaciones tienen tales vulnerabilidades y actualizarlas si es necesario.

42.3. Ataques y agresiones comunes

Tabla 42.1, “Agresiones comunes” detalla algunas de las agresiones y puntos de entrada más comunes que los intrusos utilizan para acceder a los recursos de red de la organización. La clave para prevenir estas agresiones es entender cómo se realizan y cómo los administradores puedes proteger sus redes en contra de estos ataques.

Agresiones Descripción Notas
Contraseñas nulas o por defecto Dejar las contraseñas administrativas en blanco o usar la contraseña predeterminada proporcionada por el fabricante. Esto sucede frecuentemente en hardware como enrutadores y cortafuegos, aunque algunos servicios que corren en Linux pueden contener contraseñas administrativas predeterminadas (Red Hat Enterprise Linux 5 no se entrega con ellas).
Asociado generalmente con hardware de red como enrutadores, cortafuegos, VPNs y redes de almacenamiento adjunto (NAS).
Frecuente en sistemas operativos de legado, especialmente aquellos que contienen servicios (tales como UNIX y Windows).
Algunas veces los administradores crean de prisa cuentas de usuarios privilegiados y dejan la contraseña vacía, un punto de entrada perfecto para usuarios malignos que descubren la cuenta.
Contraseñas compartidas por defecto Hay servicios seguros que a veces incluyen llaves de seguridad por defecto para propósitos de desarrollo o de prueba. Si estas llaves se dejan sin modificar y se colocan en un ambiente de producción en la Internet, todos los usuarios con la misma llave por defecto tienen acceso a ese recurso y a toda la información confidencial que pueda contener.
Comunes en puntos de acceso inalámbrico y productos para servidores de seguridad preconfigurados.
IP Spoofing (Engaño de IPs) Una máquina remota actúa como un nodo en su red local, encuentra vulnerabilidades con sus servidores e instala un programa en el fondo o un caballo de troya para ganar control sobre los recursos de su red.
Un "Spoofing" es bastante difícil de ejecutar, ya que envuelve la predicción del número TCP/IP SYN-ACK por parte del atacante para coordinar una conexión al sistema objetivo. Sin embargo, hay varias herramientas disponibles que ayudan a los crackers en la ejecución de este ataque.
Depende de los servicios ejecutándose en el sistema objetivo (tales como rsh, telnet, FTP y otros) que usan técnicas de autenticación basadas en fuente, las cuales no son recomendables si se les compara con PKI u otras formas de autenticación encriptada como las utilizadas por ssh o SSL/TLS.
Intercepción pasiva Reunir datos que pasan entre dos nodos activos en una red mediante el rastreo de la conexión entre los dos nodos.
Este tipo de ataque funciona con protocolos de transmisión de texto llano tales como Telnet, FTP, y transferencias HTTP.
Los atacantes remotos deben tener acceso a un sistema comprometido en un LAN para poder ejecutar dicho ataque; generalmente el cracker ha utilizado un ataque activo (tal como IP spoofing o man-in-the-middle) para comprometer un sistema en un LAN.
Entre las medidas preventivas se incluyen los servicios con cambios de llaves encriptadas, contraseñas de un solo uso o autenticación encriptada para prevenir la captura de contraseñas (snooping). Es asimismo recomendable la encriptación severa durante la transmisión.
Vulnerabilidades de servicios Un atacante encuentra una falla o un hueco en un servicio que se ejecuta en la Internet; a través de esa vulnerabilidad, el atacante puede comprometer el sistema completo y cualquier dato que contenga. También podría comprometer otros sistemas en la red.
Los servicios basados en HTTP, como por ejemplo CGIs, son vulnerables a la ejecución de comandos remotos e incluso al acceso interactivo a la shell. Incluso cuando el servicio HTTP es ejecutado por un usuario sin privilegios, como "nobody", es posible leer información incluida en archivos de configuración y mapas de red. El atacante puede también iniciar un ataque de negación de servicio que consume los recursos del sistema o convierte estos recursos como inalcanzables para otros usuarios.
En algunas ocasiones, los servicios pueden presentar vulnerabilidades que pasan inadvertidas durante los periodos de desarrollo y prueba; estas vulnerabilidades (como el buffer overflows, en donde los atacantes congelan el servicio utilizando valores arbitrarios que llenan el buffer de memoria de una aplicación, dando al atacante un entrada de comandos interactiva desde la cual pueden ejecutar comandos arbitrarios) pueden dar control administrativo completo a un atacante.
Los administradores deben asegurarse de no ejecutar los servicios como usuarios root. Asimismo, los administradores deben permanecer pendientes de los parches y actualizaciones de erratas de aplicaciones que son expedidos por distribuidores u organizaciones de seguridad como CERT y CVE.
Vulnerabilidades de las aplicaciones Los atacantes encuentran fallas en aplicaciones de escritorio y de estaciones de trabajo (tales como clientes de correo electrónico) y ejecutan código arbitrario, implantan caballos de troya para comprometer los sistemas en un futuro o dañan los sistemas. Pueden ocurrir otras agresiones si la estación de trabajo tiene privilegios administrativos sobre el resto de la red.
Las estaciones de trabajo y los escritorios son más susceptibles de ataques porque los empleados no tienen la suficiente experiencia para prevenir o detectar una máquina comprometida. Es importante informar a las personas sobre los riesgos de instalar software no autorizado o de abrir correo no solicitado.
Se pueden implementar medidas de seguridad, evitar, por ejemplo, que el cliente de correo abra automáticamente o ejecute los anexos. Adicionalmente, las actualizaciones automáticas de software de las estaciones de trabajo a través de Red Hat Network u otros servicios de administración de sistemas pueden aliviar la carga de las distribuciones de seguridad en múltiples puestos.
Ataques de rechazo de servicio (DoS, Denial of Service) Un atacante o grupo de atacantes pueden coordinar un ataque a la red o a los recursos de un servidor de una organización, mediante el envío de paquetes a la máquina objetivo (bien sea un servidor, enrutador o estación de trabajo). El recurso queda así deshabilitado para validar usuarios.
El caso más conocido y reportado de un ataque DoS ocurrió en los Estados Unidos en 2000. Varios sitios comerciales y gubernamentales permanecieron no disponibles debido a un ataque coordinado que utilizó varios sistemas comprometidos con conexiones de ancho de banda amplia que actuaron como zombies, o nodos de redirección de emisión.
Los paquetes fuentes son frecuentemente bifurcados (o redirigidos) para dificultar la investigación de la verdadera fuente del ataque.
Avances en filtrados de entradas (IETF rfc2267) utilizando iptables y Network IDSes tales como snort asisten a los administradores con el seguimiento y prevención de ataques DoS.
Tabla 42.1. Agresiones comunes

42.4. Actualizaciones de seguridad

A medida que se descubren fallas de seguridad en el software, éste debe ser actualizado para sellar cualquier posible riesgo de seguridad. Si el paquete es parte de una distribución de Red Hat Enterprise Linux actualmente soportada, Red Hat, Inc. está en la obligación de producir los paquetes de actualización que reparen las vulnerabilidades tan pronto como sea posible. A menudo, el anuncio de una falla de seguridad viene acompañado de un parche (o el código fuente que repara el problema). Este parche es aplicado al paquete de Red Hat Enterprise Linux, probado por el equipo de control de calidad de Red Hat y luego distribuido como una actualización de erratas. Sin embargo, si el anuncio no incluye un parche, un desarrollador de Red Hat trabajará con la persona encargada de mantener el software con el fin de reparar el problema. Después de la reparación del problema, el paquete es probado y distribuido como una actualización de errata.

Si se ha distribuido una actualización de errata para algún software usado en su sistema, se le recomienda que actualice los paquetes afectados tan pronto como estos sean publicados para minimizar el tiempo en que su sistema está potencialmente vulnerable.

42.4.1. Actualización de paquetes

Cuando actualice software en un sistema, es importante descargar la actualización desde una fuente confiable. Un intruso puede fácilmente reconstruir una versión de un paquete con el mismo número de versión como el que se supone va a reparar el problema, pero con una agresión de seguridad diferente en el paquete y distribuirlo en Internet. Si ésto ocurre, no se detectará la agresión cuando se utilicen medidas de seguridad tales como la verificación de archivos contra el RPM original. Por esta razón, es muy importante que solamente descargue RPMs desde fuentes confiables, tales como Red Hat, Inc. y verifique la firma del paquete para asegurarse de su integridad.

Red Hat proporciona dos maneras de encontrar información sobre las actualizaciones de erratas:

  1. Listadas y disponibles para su descarga desde Red Hat Network

  2. Listadas y desvinculadas del sitio web de Erratas de Red Hat

Nota

A partir de la línea de productos Red Hat Enterprise Linux, solamente se pueden descargar los paquetes de actualizaciones desde Red Hat Network. Aunque el sitio web de erratas de Red Hat contiene información sobre las actualizaciones, no contiene los paquetes para ser descargados.

42.4.1.1. Utilizando Red Hat Network

Red Hat Network le permite automatizar la mayoría de los procesos de actualización. Determina cuáles paquetes RPM son necesarios para el sistema, los descarga desde repositorios seguros, verifica la firma del RPM para asegurarse de que no han sido dañados y los actualiza. La instalación del paquete puede ocurrir de inmediato o puede ser planificada durante un cierto período de tiempo.

Red Hat Network requiere un Perfil del sistema para cada máquina que desea actualizar. El Perfil del Sistema contiene la información del hardware y software del sistema. Esta información se mantiene como confidencial y no se entrega a nadie más. Sólo se utiliza para determinar cuales actualizaciones de errata son aplicables a cada sistema. Sin esta información, Red Hat Network no puede determinar si su sistema necesita actualizaciones. Cuando una errata de seguridad (o cualquier tipo de errata) es publicada, Red Hat Network le enviará un correo electrónico con una descripción de la errata así como también cuáles de sus sistemas son afectados. Para aplicar la actualización, puede utilizar el Red Hat Update Agent o planificar para que el paquete sea actualizado a través del sitio web http://rhn.redhat.com.

Sugerencia

Red Hat Enterprise Linux incluye la Herramienta de notificación de alerta de Red Hat Network. Esta conveniente aplicación muestra un icono en panel que visualiza las alertas cuando hay una actualización para los sistemas Red Hat Enterprise Linux. Consulte el siguiente URL para más información sobre el aplique: https://rhn.redhat.com/rhn/help/quickstart.jsp

Importante

Antes de instalar cualquier errata de seguridad, asegúrese de leer cualquier instrucción especial contenida en el informe de errores y ejecútelas de la forma adecuada. Consulte la Sección 42.4.1.5, “Aplicar los cambios” para ver instrucciones generales sobre cómo aplicar los cambios de una actualización de errores.

42.4.1.2. Utilizando el sitio web de Erratas de Red Hat

Cuando se lanzan los informes de errata, estos son publicados en el sitio web de Erratas de Red Hat en http://www.redhat.com/security/. Desde esta página, seleccione el producto y la versión de su sistema y luego seleccione seguridad en la parte superior de la página para sólo desplegar los Advertencia de seguridad de Red Hat Enterprise Linux. Si la sinopsis de alguna de las recomendaciones describe un paquete usado en su sistema, pulse en la sinopsis para ver más detalles.

La página de detalles describe las violaciones de seguridad y cualquier instrucción especial que se deba llevar a cabo adicionalmente para actualizar el paquete y reparar el hueco de seguridad.

Para descargar el paquete actualizado, pulse en el enlace para iniciar una sesión en Red Hat Network, luego pulse el nombre del paquete y guárdelo al disco duro. Se recomienda que cree un nuevo directorio tal como /tmp/updates y guarde todos los paquetes descargados en él.

42.4.1.3. Verificar paquetes firmados

Todos los paquetes de Red Hat Enterprise Linux están firmados con la llave GPG de Red Hat, Inc. GPG viene de GNU Privacy Guard, o GnuPG, un paquete de software libre utilizado para asegurarse de la autenticidad de los paquetes distribuidos. Por ejemplo, una llave privada (llave secreta) de Red Hat bloquea el paquete mientras que la llave pública desbloquea y verifica el paquete. Si la llave pública distribuida por Red Hat no coincide con la llave privada durante la verificación de RPM, puede que el paquete haya sido alterado y por lo tanto no se puede confiar en el.

La utilidad de RPM dentro de Red Hat Enterprise Linux trata automáticamente de verificar la firma GPG de un paquete RPM antes de instalarlo. Si no tiene la llave GPG de Red Hat instalada, instálela desde una ubicación segura y estática tal como un CD-ROM de instalación de Red Hat Enterprise Linux.

Asumiendo que el CD-ROM se encuentra montado en /mnt/cdrom, utilice el siguiente comando para importarla a su llavero (una base de datos de llaves confiables en el sistema):

rpm --import /mnt/cdrom/RPM-GPG-KEY

Para desplegar una lista de todas las llaves instaladas para ser verificadas por RPM, ejecute el comando:

rpm -qa gpg-pubkey*

Para la llave de Red Hat, la salida incluirá lo siguiente:

gpg-pubkey-db42a60e-37ea5438

Para desplegar detalles sobre una llave específica, utilice el comando rpm -qi seguido de la salida del comando anterior, como se muestra en este ejemplo:

rpm -qi gpg-pubkey-db42a60e-37ea5438

Es extremadamente importante que verifique la firma de sus archivos RPM antes de instalarlos para asegurarse de que la llave no ha sido alterada desde la publicación de los paquetes por Red Hat. Para verificar todos los paquetes descargados de una vez, escriba el comando siguiente:

rpm -K /tmp/updates/*.rpm

Para cada paquete, si se verifica exitósamente la llave GPG, el comando devuelve gpg OK. Si no es así, asegúrese de estar utilizando la llave pública correcta de Red Hat, así como también verificar la fuente del contenido. No se deberían instalar paquetes que no pasan las verificaciones de GPG pues pueden haber sido alterados por terceros.

Después de verificar la llave GPG y descargar todos los paquetes asociados con el informe de errores, instálelos como usuario root desde un shell.

42.4.1.4. Instalación de paquetes firmados

La instalación para la mayoría de los paquetes se puede hacer sin percances (excepto para los paquetes kernel), con el comando siguiente:

rpm -Uvh /tmp/updates/*.rpm

Para los paquetes del kernel utilice el comando que sigue:

rpm -ivh /tmp/updates/<kernel-package>

Reemplace <kernel-package> en el ejemplo anterior con el nombre del RPM del kernel.

Una vez que la máquina ha sido reiniciada sin problemas usando el nuevo kernel, se puede eliminar el viejo kernel utilizando el comando siguiente:

rpm -e <old-kernel-package>

Reemplace <old-kernel-package> en el ejemplo anterior con el nombre del RPM del kernel viejo.

Nota

No se requiere que elimine el viejo kernel. El gestor de arranque por defecto, GRUB, permite tener instalados múltiples kernels y seleccionarlos desde el menú durante el arranque.

Importante

Antes de instalar cualquier errata de seguridad, asegúrese de leer cualquier instrucción especial contenida en el informe de errores y ejecútelas de la forma adecuada. Consulte la Sección 42.4.1.5, “Aplicar los cambios” para ver instrucciones generales sobre cómo aplicar los cambios de una actualización de errores.

42.4.1.5. Aplicar los cambios

Después de descargar e instalar las erratas de seguridad a través de Red Hat Network o del sitio web de Erratas de Red Hat, es importante que detenga el uso del software viejo y comience a utilizar el nuevo software. Como se lleve esto a cabo va a depender del tipo de software que se haya actualizado. La lista siguiente muestra las diferentes categorías generales de software y proporciona instrucciones para utilizar las versiones actualizadas luego de una actualización de paquetes.

Nota

En general, la forma más segura de asegurarse que se está utilizando la versión más reciente de un paquete de software es reiniciando el sistema; sin embargo, esta opción no siempre está disponible para el administrador del sistema.

Aplicaciones

Las aplicaciones del espacio de usuario son cualquier programa que puede ser iniciado por un usuario del sistema. Generalmente, tales aplicaciones son solamente utilizadas cuando un usuario, script o tarea automática las lanza y no persisten por largos períodos de tiempo.

Una vez que tal aplicación del espacio de usuario es actualizada, detenga cualquier instancia de la aplicación en el sistema y lance el programa nuevamente para así utilizar la versión actualizada.

Kernel

El kernel es el componente de software central para el sistema operativo de Red Hat Enterprise Linux. Éste se encarga de manejar el acceso a la memoria, el procesador y los periféricos así como también, planifica todas las tareas.

Debido a su rol central, el kernel no puede reiniciarse sin detener el computador. Por lo tanto, una versión actualizada del kernel no puede ser usada hasta que el sistema no se reinicie.

Bibliotecas compartidas

Las bibliotecas compartidas son unidades de código, tales como glibc, que son usadas por un número de aplicaciones y servicios. Las aplicaciones que utilizan una biblioteca compartida típicamente cargan el código compartido cuando la aplicación es inicializada, así cualquier aplicación que esté utilizando la biblioteca debe ser detenida y relanzada.

Para determinar cuáles aplicaciones en ejecución estan enlazadas a una biblioteca en particular, utilice el comando lsof, como se muestra en el ejemplo:

lsof /usr/lib/libwrap.so*

Este comando devuelve una lista de todos los programas en ejecución que están usando TCP wrappers para el control de acceso a máquinas. Por lo tanto, cualquier programa listado debe ser detenido y relanzado si el paquete tcp_wrappers es actualizado.

Servicios SysV

Los servicios SysV son programas del servidor persistentes, que son lanzados durante el proceso de arranque. Ejemplos de servicios SysV incluyen sshd, vsftpd y xinetd.

Debido a que estos programas usualmente persisten en memoria, siempre y cuando la máquina esté encendida, cada servicio SysV actualizado, debe ser detenido y relanzado después de una actualización de paquetes. Esto se puede hacer usando la Herramienta de configuración de servicios o conectándose como root en un indicador de comandos shell y ejecutando el comando /sbin/service como se muestra en el ejemplo siguiente:

/sbin/service <service-name> restart

En el ejemplo anterior, reemplace <service-name> con el nombre del servicio, tal como sshd.

Servicios xinetd

Los servicios controlados por el super servicio xinetd sólo funcionan cuando hay una conexión activa. Ejemplos de servicios controlados por xinetd incluyen Telnet, IMAP, y POP3.

Puesto que xinetd lanza nuevas instancias de estos servicios cada vez que se recibe una nueva petición, las conexiones que ocurren después de una actualización son manejadas por el software actualizado. Sin embargo, si hay conexiones activas en el momento en que el servicio controlado por xinetd es actualizado, estas son servidas por la versión vieja del software.

Para matar todas las instancias viejas de un servicio controlado por xinetd, actualice el paquete para el servicio y luego detenga todos los procesos que se esten ejecutando en ese momento. Para determinar si el proceso está en ejecución, utilice el comando ps y luego use kill o killall para detener todas las instancias actuales del servicio.

Por ejemplo, si hay erratas de seguridad para paquetes imap, actualice los paquetes, luego escriba el comando siguiente como root en un indicador de comandos:

ps -aux | grep imap

Este comando devuelve todas las sesiones activas de IMAP. Las sesiones individuales pueden ser terminadas luego usando el comando que sigue:

kill <PID>

Si la sesión no es finalizada después de ejecutar este comando, utilice el comando siguiente:

kill -9 <PID>

En el ejemplo anterior, reemplace <PID> con el número de identificación del proceso (encontrado en la segunda columna del comando ps) para una sesión IMAP.

Para matar todas las sesiones IMAP activas, utilice el comando que sigue:

killall imapd

Capítulo 43. Aseguramiento de su Red

43.1. Seguridad en las estaciones de trabajo
43.1.1. Evaluando la seguridad en la estación de trabajo
43.1.2. Seguridad del BIOS y del gestor de arranque
43.1.3. Seguridad de contraseñas
43.1.4. Controles administrativos
43.1.5. Servicios de red disponibles
43.1.6. Cortafuegos personales
43.1.7. Herramientas de mejoramiento de la seguridad
43.2. Seguridad de servidores
43.2.1. Asegurando los servicios con TCP Wrappers y xinetd
43.2.2. Protección de Portmap
43.2.3. Protección de NIS
43.2.4. Protección de NFS
43.2.5. Protegiendo el servidor Apache HTTP
43.2.6. Protección de FTP
43.2.7. Asegurando Sendmail
43.2.8. Verificar cuáles puertos están escuchando
43.3. Single Sign-on (SSO)
43.3.1. Introducción
43.3.2. Iniciando con su nueva tarjeta inteligente
43.3.3. Cómo funciona la inscripción de las tarjetas inteligentes
43.3.4. Cómo funciona el registro de las tarjetas inteligentes
43.3.5. Configuración de Firefox para utilizar Kerberos con SSO
43.4. Pluggable Authentication Modules (PAM)
43.4.1. Las ventajas de PAM
43.4.2. archivos de configuración PAM
43.4.3. Formato del archivo de configuración PAM
43.4.4. Muestras de archivos de configuración PAM
43.4.5. Creación de módulos PAM
43.4.6. PAM y el caché de credenciales administrativas
43.4.7. PAM y propiedad del dispositivo
43.4.8. Recursos adicionales
43.5. TCP Wrappers y xinetd
43.5.1. Wrappers TCP
43.5.2. Archivos de configuración de Wrappers TCP
43.5.3. xinetd
43.5.4. Archivos de configuración de xinetd
43.5.5. Recursos adicionales
43.6. Redes privadas virtuales (VPNs)
43.6.1. ¿Cómo funciona un VPN?
43.6.2. VPNs y Red Hat Enterprise Linux
43.6.3. IPsec
43.6.4. Creando una conexión IPsec
43.6.5. Instalación de IPsec
43.6.6. Configuración IPsec de host-a-host
43.6.7. Configuración de IPsec de red-a-red
43.6.8. Iniciando y deteniendo conexiones IPsec
43.7. IPTables
43.7.1. Filtrado de paquetes
43.7.2. Diferencias entre IPTables y IPChains
43.7.3. Opciones de comandos para IPTables
43.7.4. Guardando reglas IPTables
43.7.5. Scripts de control de IPTables
43.7.6. IPTables y IPv6
43.7.7. Recursos adicionales

43.1. Seguridad en las estaciones de trabajo

La seguridad del ambiente Linux comienza en la estación de trabajo. Bien sea que esté bloqueando su propia máquina personal o asegurando un sistema corporativo, una buena política de seguridad comienza con el computador personal. Después de todo, una red es tan segura como su nodo más débil.

43.1.1. Evaluando la seguridad en la estación de trabajo

Cuando evalúe la seguridad de una estación de trabajo Red Hat Enterprise Linux, considere lo siguiente:

  • Seguridad del BIOS y del gestor de arranque — ¿Puede un usuario no autorizado acceder físicamente a la máquina e iniciar una sesión como usuario único o en modo de rescate sin una contraseña?

  • Seguridad de la contraseña — ¿Qué tan seguras son las cuentas de usuarios en la máquina?

  • Controles administrativos — ¿Quién tiene una cuenta en el sistema y cuánto control administrativo tienen?

  • Servicios de red disponibles — ¿Qué servicios están escuchando peticiones desde la red que realmente deberían estar en ejecución?

  • Cortafuegos personales — ¿Qué tipo de cortafuego o firewall, si existe, es necesario?

  • Herramientas de comunicación para mejor seguridad — ¿Qué herramientas debería utilizar para comunicarse entre estaciones de trabajo y cuáles se deberían evitar?

43.1.2. Seguridad del BIOS y del gestor de arranque

La protección con contraseñas para el BIOS (o equivalentes al BIOS) y para el gestor de arranque pueden ayudar a prevenir el acceso físico a sus sistemas por parte de usuarios no autorizados. Asimismo evita que los sistemas sean iniciados desde medios removibles o que se obtenga acceso como root a través del modo monousuario. Sin embargo, las medidas de seguridad que uno debería tomar para protegerse contra tales ataques dependen tanto de la confidencialidad de la información que las estaciones tengan como de la ubicación de la máquina.

Por ejemplo, si se utiliza una máquina en una exhibición y ésta no contiene datos confidenciales, entonces puede que no sea crítico prevenir tales ataques. Sin embargo, si en la misma exhibición se deja sin cuidado el portátil de uno de los empleados que contiene llaves privadas SSH sin encriptar pertenecientes a la red corporativa, se puede conducir a una violación de seguridad importante para toda la compañía.

Por otro lado, si la estación de trabajo está localizada en un lugar donde sólo los usuarios autorizados o de confianza tienen acceso, entonces la seguridad del BIOS o del gestor de arranque puede no ser necesaria.

43.1.2.1. Contraseñas del BIOS

Las dos razones básicas por las cuales se debe proteger la BIOS de una computadora con una contraseña son[11]:

  1. Prevenir cambios a las configuraciones del BIOS — Si un intruso tiene acceso a la BIOS, puede configurarlo para que arranque desde un diskette o CD-ROM. Esto permite entrar en modo de rescate o monousuario, lo que a su vez les permite plantar programas dañinos en el sistema o copiar datos confidenciales.

  2. Prevenir el arranque del sistema — Algunas BIOSes le permiten proteger el proceso de arranque con una contraseña. Cuando está funcionalidad está activada, un atacante esta forzado a introducir una contraseña antes de que el BIOS lanze el gestor de arranque.

Debido a que los métodos para colocar contraseñas del BIOS varían entre fabricantes de equipos, consulte el manual de su computador para ver las instrucciones específicas.

Si olvida su contraseña del BIOS, usualmente esta se puede reconfigurar bien sea a través de los jumpers en la tarjeta madre o desconectando la batería CMOS. Por esta razón, es una buena idea bloquear el chasis del computador si es posible. Sin embargo, consulte el manual del computador o tarjeta madre antes de proceder a desconectar la batería CMOS.

43.1.2.1.1. Aseguramiento de plataformas diferentes a x86

Otras arquitectura utilizan programas diferentes para llevar a cabo tareas de bajo nivel similares a las del BIOS en sistemas x86. Por ejemplo, las computadoras basadas en Intel®Itanium™ utilizan la shell Extensible Firmware Interface (EFI).

Para ver las instrucciones sobre cómo proteger con contraseñas estos programas, consulte las instrucciones del fabricante.

43.1.2.2. Contraseñas del gestor de arranque

A continuación se muestran las razones principales por las cuales se debe proteger el gestor de arranque de Linux:

  1. Previene el acceso en modo monousuario — Si un atacante puede arrancar en modo monousuario, se convierte en el superusuario de forma automática sin que se le solicite la contraseña de acceso.

  2. Previene el acceso a la consola de GRUB — Si la máquina utiliza GRUB como el gestor de arranque, un atacante puede usar la interfaz del editor para cambiar su configuración o para reunir información usando el comando cat.

  3. Previene el acceso a sistemas operativos inseguros — Si es un sistema de arranque dual, un atacante puede seleccionar un sistema operativo en el momento de arranque, tal como DOS, el cual ignora los controles de acceso y los permisos de archivos.

Red Hat Enterprise Linux para la plataforma x86 se entrega con el gestor de arranque GRUB. Consulte el Manual de Instalación de Red Hat si desea una visión más profunda de GRUB.

43.1.2.2.1. Protegiendo GRUB con contraseñas

Puede configurar GRUB para solucionar los primeros dos problemas listados en la Sección 43.1.2.2, “Contraseñas del gestor de arranque” añadiendo una directriz de contraseña a su archivo de configuración. Para hacer esto, primero seleccione una contraseña, luego abra un intérprete de comandos, conéctese como root y escriba:

/sbin/grub-md5-crypt

Cuando se le pida, escriba la contraseña GRUB y presione Intro. Esto retornará un hash MD5 para la contraseña.

Luego, modifique el archivo de configuración GRUB /boot/grub/grub.conf. Abra el archivo y debajo de la línea timeout en la sección principal del documento, añada la siguiente línea:

password --md5 <contraseña-hash>

Reemplace <contraseña-hash> con el valor que /sbin/grub-md5-crypt retornó[12].

La próxima vez que el sistema arranque, el menú de GRUB no le permitirá acceder al editor o a la interfaz de comandos si no presiona primero p seguido por la contraseña de GRUB.

Lamentablemente, esta solución no previene a un atacante arrancar en un sistema operativo inseguro si se está en un ambiente de arranque dual. Para esto, necesita editar una parte diferente del archivo /boot/grub/grub.conf.

Busque la línea title del sistema operativo inseguro y añada una línea que diga lock directamente debajo de ella.

Para un sistema DOS, debería comenzar con algo similar a:

title DOS lock

Advertencia

Debe tener una línea password en la sección principal del archivo /boot/grub/grub.conf para que este mecanismo funcione adecuadamente. De lo contrario, un atacante podrá acceder a la interfaz del editor de GRUB y eliminar la línea de bloqueo.

Para crear una contraseña diferente para un kernel o sistema operativo particular, añada una línea lock, seguida por una línea de contraseña.

Cada entrada que proteja con una contraseña única debería comenzar con líneas similares a las del ejemplo siguiente:

title DOS lock password --md5 <contraseña-hash>

43.1.3. Seguridad de contraseñas

Las contraseñas son el método principal que Red Hat Enterprise Linux utiliza para verificar la identidad de los usuarios. Por esta razón la seguridad de las contraseñas es de suma importancia para la protección del usuario, la estación de trabajo y la red.

Por razones de seguridad, el programa de instalación configura el sistema para usar el Message-Digest Algorithm (MD5) y contraseñas shadow. Se recomienda que no cambie esta configuración.

Si quita la selección de MD5 durante la instalación, se utilizará el formato Data Encryption Standard (DES). Este formato limita las contraseñas a ocho caracteres alfanuméricos (no permite caracteres de puntuación o especiales) y proporciona un modesto nivel de encriptación de 56-bits.

Si usted deselecciona las contraseñas shadow durante la instalación, todas las contraseñas son almacenadas como hash de una sola vía en el archivo /etc/passwd, lo que hace al sistema vulnerable a ataques de piratas fuera de línea. Si un intruso obtiene acceso a la máquina como un usuario regular, puede también copiar el archivo /etc/passwd a su propia máquina y ejecutar cualquier cantidad de programas de descifrado de contraseñas contra él. Si hay una contraseña insegura en el archivo, es cuestión de tiempo antes de que el maleante informático la descubra.

Las contraseñas shadow eliminan este tipo de ataques, almacenando los hash de las contraseñas en el archivo /etc/shadow, el cual sólo es leído por el usuario root.

Esto obliga al atacante potencial a intentar descubrir la contraseña remotamente mediante la conexión a un servicio de la red en la máquina, tal como SSH o FTP. Este tipo de ataques de fuerza bruta son mucho más lentos y dejan rastros obvios, pues los intentos fallidos de conexión son registrados a los archivos del sistema. Por supuesto, si el maleante o cracker comienza un ataque durante la noche y usted tiene contraseñas débiles, éste podría obtener acceso antes del amanecer y editar el archivo de registro para borrar sus rastros.

Además del formato y el almacenamiento, está el problema del contenido. Lo más importante que un usuario puede hacer para proteger su cuenta contra un ataque de piratas, es crear una contraseña robusta.

43.1.3.1. Creación de contraseñas robustas

Cuando se cree una contraseña segura, es una buena idea seguir las siguientes pautas:

  • No utilice solamente palabras o números — Nunca debería utilizar únicamente letras o sólo números en una contraseña.

    Algunos ejemplos inseguros incluyen:

    • 8675309

    • juan

    • atrapame

  • No utilice palabras reconocibles — Palabras tales como nombres propios, palabras del diccionario o hasta términos de shows de televisión o novelas deberían ser evitados, incluso si utiliza números al final de éstos.

    Algunos ejemplos inseguros incluyen:

    • john1

    • DS-9

    • mentat123

  • No utilice palabras en idiomas extranjeros — Los programas de descifrado de contraseñas a menudo verifican listas de palabras que abarcan diccionarios de muchos idiomas. No es seguro confiarse en un idioma extranjero para asegurar una contraseña.

    Algunos ejemplos inseguros incluyen:

    • cheguevara

    • bienvenue1

    • 1dumbKopf

  • No utilice terminología de hackers — Si piensa que usted pertenece a una élite porque utiliza terminología hacker — también llamado hablar l337 (LEET) — en su contraseña, piense otra vez. Muchas listas de palabras incluyen lenguaje LEET.

    Algunos ejemplos inseguros incluyen:

    • H4X0R

    • 1337

  • No utilice información personal — Mantengase alejado de la información personal. Si un atacante conoce quién es usted, la tarea de deducir su contraseña será aún más fácil. La lista siguiente muestra los tipos de información que debería evitar cuando esté creando una contraseña:

    Algunos ejemplos inseguros incluyen:

    • Su nombre

    • El nombre de sus mascotas

    • El nombre de los miembros de su familia

    • Fechas de cumpleaños

    • Su número telefónico o código postal

  • No invierta palabras reconocibles — Los buenos verificadores de contraseñas siempre invierten las palabras comunes; por tanto, invertir una mala contraseña no la hace para nada más segura.

    Algunos ejemplos inseguros incluyen:

    • R0X4H

    • nauj

    • 9-DS

  • No escriba su contraseña — Nunca guarde su contraseña en un papel. Es mucho más seguro memorizarla.

  • No utilice la misma contraseña para todas las máquinas — Es importante que cada máquina tenga una contraseña diferente. De esta forma, si un sistema es comprometido, no todas sus máquinas estarán en peligro inmediato.

Las siguientes pautas lo ayudarán a crear una contraseña robusta:

  • Cree contraseñas de al menos ocho caracteres — Mientras más larga sea la contraseña, mejor. Si está usando contraseñas MD5, debería ser de 15 caracteres de largo o más. Con las contraseñas DES, use el largo máximo (ocho caracteres).

  • Mezcle letras mayúsculas y minúsculas — Red Hat Enterprise Linux distingue entre mayúsculas y minúsculas, por la tanto mezcle las letras para reforzar su contraseña.

  • Mezcle letras y números — Agregando números a las contraseñas, especialmente cuando se añaden en el medio (no solamente al comienzo o al final), puede mejorar la fortaleza de su contraseña.

  • Incluya caracteres no alfanuméricos — Los caracteres especiales tales como &, $, y > pueden mejorar considerablemente su contraseña (esto no es posible si esta usando contraseñas DES).

  • Seleccione una contraseña que pueda recordar — La mejor contraseña en el mundo será de poca utilidad si usted no puede recordarla. Por lo tanto utilice acrónimos u otros dispositivos nemónicos que lo ayuden a memorizar las contraseñas.

Con todas estas reglas, puede parecer difícil crear una contraseña que reuna todos estos requisitos y evite, a la vez, los rasgos de las malas contraseñas. Afortunadamente, hay algunos pasos que uno puede tomar para generar una contraseña segura y fácil de recordar.

43.1.3.1.1. Metodología para la creación de contraseñas seguras

Hay muchos métodos que la gente utiliza para crear contraseñas seguras. Uno de los métodos más populares incluyen acrónimos. Por ejemplo:

  • Piense en una frase memorable, tal como:

    "Es más fácil creer que pensar con espíritu crítico."

  • Luego, cámbielo a un acrónimo (incluyendo la puntuación).

    emfcqpcec.

  • Añada un poco de complejidad sustituyendo números y símbolos por letras en el acrónimo. Por ejemplo, sustituya7 por e y el símbolo arroba (@) por c:

    7mf@qp@7@.

  • Añada un poco más de complejidad colocando mayúscula al menos a una letra, tal como M.

    7Mf@qp@7@.

  • Por último, no utilice esta contraseña de ejemplo en ninguno de sus sistemas.

Mientras que la creación de contraseñas seguras es imperativo, manejarlas adecuadamente es también importante, especialmente para los administradores de sistemas dentro de grandes organizaciones. La próxima sección detalla buenos hábitos en la creación y manejo de contraseñas de usuarios dentro de una organización.

43.1.3.2. Creación de cuentas de usuario dentro de la organización

Si hay un número significativo de usuarios dentro de una organización, los administradores de sistemas tienen dos opciones básicas disponibles para forzar el uso de buenas contraseñas. Ellos pueden crear contraseñas para el usuario o dejar que los usuarios crean sus propias contraseñas, a la vez que verifican que las contraseñas sean de calidad aceptable.

Al crear las contraseñas para los usuarios se asegura de que las contraseñas sean buenas, pero se vuelve una tarea agotadora a medida que la organización crece. También incrementa el riesgo de que los usuarios escriban sus contraseñas en papel.

Por estas razones, la mayoría de los administradores de sistemas prefieren dejar que los usuarios creen sus propias contraseñas, pero verifican de una forma activa que las contraseñas sean buenas y, en algunos casos, obligan a los usuarios a cambiarlas periódicamente haciéndolas caducar.

43.1.3.2.1. Forzar la creación de contraseñas robustas

Para proteger la red contra intrusos, es aconsejable que los administradores de sistemas verifiquen que las contraseñas usadas dentro de la organización sean robustas. Cuando se les pide a los usuarios crear o modificar sus contraseñas, ellos pueden utilizar la aplicación de la línea de comandos passwd, la cual reconoce PAM (Pluggable Authentication Manager) y por lo tanto verificará si la contraseña es fácil de descifrar o si es demasiado corta, a través del módulo PAM pam_cracklib.so. Puesto que PAM es personalizable, es posible añadir más verificaciones para la integridad de la contraseña, tales como pam_passwdqc (disponible en http://www.openwall.com/passwdqc/) o escribir un nuevo módulo. Para una lista de los módulos PAM disponibles, consulte http://www.kernel.org/pub/linux/libs/pam/modules.html. Para obtener mayor información sobre PAM, consulte el Sección 43.4, “Pluggable Authentication Modules (PAM)”.

Sin embargo, es importante resaltar que la verificación realizada en las contraseñas al momento de su creación, no descubren las malas contraseñas de forma tan efectiva como lo haría un programa específico para descifrado ejecutado sobre las contraseñas dentro de la organización.

Hay muchos programas de descifrado de contraseñas que corren bajo Red Hat Enterprise Linux, aunque ninguno es suministrado con el sistema operativo. Abajo se muestra una breve lista de algunos de los programas de descifrado de contraseñas más populares:

Nota

Ninguna de estas herramientas son suministradas con Red Hat Enterprise Linux y, por lo tanto, no son soportadas por Red Hat, Inc. de ninguna manera.

  • John The Ripper — Un programa rápido y flexible de descifrado de contraseñas. Permite el uso de múltiples listas de palabras y es capaz de usar descifrado de contraseñas con fuerza bruta. Está disponible en http://www.openwall.com/john/.

  • Crack — Quizás el software más conocido sobre descifrado de contraseñas; muy rápido, pero no tan fácil de usar como John The Ripper. Se puede encontrar en línea desde http://www.crypticide.com/users/alecm/.

  • SlurpieSlurpie es similar a John The Ripper y a Crack excepto que está diseñado para ejecutarse en varias máquina simultáneamente, creando un ataque de contraseñas distribuido. Se puede encontrar junto a otros grupos de herramientas de evaluación de ataques distribuidos a la seguridad en http://www.ussrback.com/distributed.htm.

Advertencia

Siempre obtenga autorización por escrito antes de intentar descifrar las contraseñas dentro de la organización.

43.1.3.2.2. Envejecimiento de las contraseñas

El envejecimiento de contraseñas es una técnica utilizada por los administradores de sistemas para defenderse de las malas contraseñas dentro de la organización. El envejecimiento de contraseñas significa que luego de un tiempo determinado (usualmente 90 días) se le pide al usuario que creee una nueva contraseña. La teoría detrás de esto es que si un usuario es forzado a cambiar su contraseña periódicamente, una contraseña que ha sido descifrada por un cracker sólo le es útil por un tiempo determinado. La desventaja del envejecimiento de contraseñas, es que los usuarios tienden a escribir sus contraseñas.

Existen dos programas principales usados para especificar la caducidad de contraseñas bajo Red Hat Enterprise Linux, el comando chage o la aplicación gráfica Gestor de usuarios (system-config-users).

La opción -M del comando chage especifica el número de días máximo en que la contraseña será válida. Por lo tanto, si desea que la contraseña de un usuario expire en 90 días, escriba el comando siguiente:

chage -M 90 <usuario>

En el comando anterior, reemplace <usuario> con el nombre del usuario. Para desactivar la expiración de contraseñas, es común utilizar un valor de 99999 después de la opción -M (esto equivale a un poco más de 273 años).

También puede utilizar el comando chage en modo interactivo para modificar múltiples envejecimientos de contraseñas y otros detalles de la cuenta. Utilice el siguiente comando para entrar en modo interactivo:

chage <usuario>

El siguiente es un ejemplo de una sesión interactiva utilizando este comando:

 [root@interch-dev1 ~]# chage davido Changing the aging information for davido Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: [root@interch-dev1 ~]# 

Consulte las páginas man de chage para obtener información sobre las opciones disponibles.

También puede utilizar la aplicación gráfica Gestor de usuarios para crear políticas de envejecimiento de contraseñas. Tenga en cuenta que usted necesitará privilegios administrativos para utilizar este procedimiento.

  1. En el panel, haga clic en Sistema, vaya a Administración y haga clic en Usuarios y grupos para iniciar el Gestor de usuarios. También puede escribir el comando system-config-users en el intérprete de comandos.

  2. Haga clic en la pestaña Usuarios y seleccione el usuario requerido en la liste de usuarios.

  3. Haga clic en Propiedades en la barra de herramientas para ver las propiedades de usuario (o escoja Propiedades en el menú Archivo).

  4. Luego haga clic en la pestaña Información de la contraseña y seleccione la casilla para Activar expiración de contraseña.

  5. Introduzca el valor requerido en el campo Días requeridos antes de cambiar y haga clic en OK.

Especificando las opciones de envejecimiento de contraseñas

Panel de ilustración de Información de la contraseña.

Figura 43.1. Especificando las opciones de envejecimiento de contraseñas

43.1.4. Controles administrativos

Cuando se está administrando una máquina casera, el usuario tiene que llevar a cabo algunas tareas como usuario root o adquiriendo privilegios de root a través de programas setuid como sudo o su. Un programa setuid es aquel que opera con el ID (UID) del usuario del dueño del programa en vez del usuario que esté operando el programa. Tales programas son denotados con una s en minúscula en la sección del dueño de un listado de formato largo:

-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

Nota

La s puede estar en mayúsculas o minúsculas. Si aparece en mayúsculas significa que el bit de permisos no ha sido establecido.

Sin embargo, los administradores de sistemas de una organización deben decidir cuánto acceso administrativo se le otorga a los usuarios dentro de la organización a sus máquinas. A través de un módulo PAM llamado pam_console.so, se le permite al primer usuario que se conecte en la consola física realizar algunas actividades normalmente reservadas para el superusuario, tales como el reinicio o el montaje de media removible (consulte el Sección 43.4, “Pluggable Authentication Modules (PAM)” para obtener mayores detalles sobre el módulo pam_console.so). Sin embargo, otras tareas importantes de administración de sistemas, tales como la modificación de las configuraciones de la red, configurar un nuevo ratón o montar dispositivos de red, son imposibles sin privilegios administrativo. En consecuencia, los administradores deben decidir cuanto acceso administrativo deberían recibir los usuarios en su red.

43.1.4.1. Permitir el acceso como root

Si los usuarios dentro de la organización son de confianza y saben de computación, entonces darles acceso root quizás no sea una mala idea. Permitir el acceso root a los usuarios significa que los pequeños problemas, tales como añadir dispositivos o configurar interfaces de red, pueden ser manejados por los usuarios individuales, dejando a los administradores de sistemas libres para manejar la seguridad de la red y otras cosas de mayor importancia.

Por otro lado, dar acceso de superusuario a usuarios individuales puede conllevar a los siguientes problemas:

  • Configuración errónea de las máquinas — Los usuarios con acceso root pueden configurar las máquinas de forma errónea y luego necesitar asistencia o peor aún, abrir huecos de seguridad sin saberlo.

  • Ejecutar servicios inseguros — Los usuarios con acceso root pueden correr servicios inseguros en sus máquinas, tales como FTP o Telnet, colocando potencialmente los nombres de usuarios y sus contraseñas en riesgo. estos servicios transmiten la información a través de la red en texto llano.

  • Ejecutar anexos de correo electrónico como root — Aún cuando es muy raro, si existen viruses que afectan Linux. La única vez en que se convierten en una amenaza, es cuando son ejecutados por el usuario root.

43.1.4.2. Desactivación del acceso root

Si un administrador no está cómodo con permitir a los usuarios tener acceso como root por estas u otras razones, entonces la contraseña de root debería mantenerse en secreto y deshabilitar el acceso a nivel uno o en modo monousuario a través de la protección con contraseñas del gestor de arranque (consulte la Sección 43.1.2.2, “Contraseñas del gestor de arranque” para más detalles sobre este tema).

Tabla 43.1, “Métodos para deshabilitar la cuenta root” muestra las formas en que un administrador puede asegurar aún más que las conexiones como root estén prohibidas.

Método Descripción Efectos No afecta
Cambiar el shell de root. Modifique el archivo /etc/passwd y cambie el shell de /bin/bash a /sbin/nologin.
Previene el acceso a la shell de root y registrar cualquier intento de hacerlo.
Se previene el acceso a la cuenta root a los siguientes programas:
· login
· gdm
· kdm
· xdm
· su
· ssh
· scp
· sftp
Programas que no requieren una shell, como clientes FTP, clientes de correo y varios programas setuid.
A los siguientes programas no se les previene el acceso a la cuenta root:
· sudo
· clientes FTP
· Clientes de correo-e
Deshabilitar el acceso root a través de cualquier dispositivo de consola (tty). Un archivo /etc/securetty vacío previene la conexión como root en cualquier dispositivo conectado a la computadora.
Prevenir el acceso a la cuenta root a través de la consola o la red. A los siguientes programas se les previene el acceso a la cuenta root:
· login
· gdm
· kdm
· xdm
· Otros servicios de red que abren una tty
Los programas que no inician una sesión como root pero que ejecutan tareas de administración a través de setuid u otros mecanismos.
A los siguientes programas no se les previene el acceso a la cuenta root:
· su
· sudo
· ssh
· scp
· sftp
Deshabilitar conexiones root SSH. Modifique el archivo /etc/ssh/sshd_config y configure el parámetro PermitRootLogin a no.
Previene el acceso a root a través del conjunto de herramientas OpenSSH. A los siguientes programas se les previene el acceso a la cuenta de root:
· ssh
· scp
· sftp
Esto sólo previene el acceso root al conjunto de herramientas OpenSSH.
Utilizar PAM para limitar el acceso a servicios desde root. Modifique el archivo para el servicio objetivo en el directorio /etc/pam.d/. Asegúrese que pam_listfile.so sea requerido para la autenticación.[a]
Prevenir el acceso a root a los servicios de red que reconocen PAM.
A los siguientes servicios se les previene el acceso a la cuenta root:
· clientes FTP
· Clientes de correo-e
· login
· gdm
· kdm
· xdm
· ssh
· scp
· sftp
· Cualquier servicio que reconozca PAM
Programas y servicios que no reconozcan PAM.

[a] Consulte la Sección 43.1.4.2.4, “Deshabilitar root utilizando PAM” para obtener mayores detalles.

Tabla 43.1. Métodos para deshabilitar la cuenta root

43.1.4.2.1. Deshabilitar el shell de root

Para prevenir que los usuarios se conecten directamente como root, el administrador del sistema puede configurar el shell de la cuenta root a /sbin/nologin en el archivo /etc/passwd. Esto impedirá el acceso a la cuenta root a través de comandos que requieren un shell, tal como los comandos su y ssh.

Importante

Los programas que no requieren acceso al shell, tales como los clientes de correo electrónico o el comando sudo, aún pueden tener acceso a la cuenta root.

43.1.4.2.2. Deshabilitar las sesiones root

Para limitar aún más el acceso a la cuenta root, los administradores pueden desactivar las conexiones root en la consola, editando el archivo /etc/securetty. Este archivo lista todos los dispositivos a los cuales el usuario root puede conectarse. Si el archivo no existe, el usuario puede conectarse a través de cualquier dispositivo de comunicación en el sistema, bien sea a través de la consola o una interfaz de red sin configurar. Esto es peligroso porque un usuario puede hacer Telnet en su máquina como root, enviando su contraseña sobre la red en texto plano. Por defecto, el archivo /etc/securetty de Red Hat Enterprise Linux,, sólo permite que el usuario root se conecte en la consola conectada físicamente a la máquina. Para prevenir que el usuario root se conecte, elimine los contenidos de este archivo escribiendo el comando siguiente:

echo > /etc/securetty

Advertencia

Un archivo /etc/securetty en blanco no previene al usuario root conectarse remotamente usando el conjunto de herramientas OpenSSH, ya que la consola no se abre sino hasta después de que se obtenga la autenticación.

43.1.4.2.3. Deshabilitar conexiones root SSH

Para prevenir las conexiones de root a través del protocolo SSH, modifique el archivo de configuración del demonio SSH (/etc/ssh/sshd_config). Cambie la línea que dice:

# PermitRootLogin yes

para que diga lo siguiente:

 PermitRootLogin no
43.1.4.2.4. Deshabilitar root utilizando PAM

PAM, a través del módulo /lib/security/pam_listfile.so, otorga gran flexibilidad en negar cuentas específicas. Esto permite al administrador apuntar el módulo a una lista de usuarios que no tienen derecho a conectarse. Abajo se muestra un ejemplo de cómo el módulo es usado por el servidor FTP vsftpd en el archivo de configuración PAM /etc/pam.d/vsftpd (el caracter \ al final de la primera línea en el ejemplo siguiente no es necesario si la directiva esta en una sola línea):

auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Esto le dice a PAM que consulte el archivo /etc/vsftpd.ftpusers y que niegue el acceso al servicio a cualquier usuario que esté listado allí. El administrador tiene la libertad de cambiar el nombre de este archivo y de mantener una lista separada para cada servicio o de usar una lista central para negar el acceso a múltiples servicios.

Si el administrador desea negar el acceso a múltiples servicios, se puede añadir una línea similar a los servicios de configuración PAM, tales como /etc/pam.d/pop y /etc/pam.d/imap para los clientes de correo o /etc/pam.d/ssh para los clientes SSH.

Para obtener mayor información sobre PAM, consulte Sección 43.4, “Pluggable Authentication Modules (PAM)”.

43.1.4.3. Limitar el acceso root

En vez de negar completamente el acceso al superusuario, el administrador puede permitir el acceso solamente a través de programas setuid, tales como su o sudo.

43.1.4.3.1. El comando su

Después de ejecutar el comando su, se le solicita al usuario la contraseña de root y, luego de la autenticación, se le presenta un intérprete de comandos de shell.

Una vez conectado a través de su, el usuario se convierte en el superusuario y tiene acceso administrativo absoluto al sistema[13]. Además, una vez que el usuario obtiene acceso root es posible, en algunos casos, usar el comando su para cambiarse a cualquier otro usuario en el sistema sin que se le solicite una contraseña.

Debido a que este programa es tan poderoso, los administradores dentro de la organización pueden desear limitar el acceso a este comando.

Una de las formas más fáciles de hacer esto es añadir usuarios al grupo administrativo especial llamado wheel. Para añadirlos, escriba el siguiente comando como root:

usermod -G wheel <usuario>

En el comando anterior, cambie <usuario> con el nombre del usuario que desea añadir al grupo wheel.

También puede utilizar el Gestor de usuarios para modificar las membresías a grupos. Tenga en cuenta que necesitará privilegios administrativos para ejecutar este procedimiento.

  1. En el panel, haga clic en Sistema, vaya a Administración y haga clic en Usuarios y grupos para iniciar el Gestor de usuarios. También puede escribir el comando system-config-users en el intérprete de comandos.

  2. Haga clic en la pestaña Usuarios y seleccione el usuario requerido en la liste de usuarios.

  3. Haga clic en Propiedades en la barra de herramientas para ver las propiedades de usuario (o escoja Propiedades en el menú Archivo).

  4. Luego seleccione la pestaña Grupos y seleccione la casilla de verificación para el grupo wheel. Haga clic en OK para finalizar. Observe la Figura 43.2, “Añadiendo usuarios al grupo "wheel".”.

  5. Luego, abra el archivo de configuración PAM para su (/etc/pam.d/su) en un editor de texto y elimine el caracter de comentario # desde la línea siguiente:

    auth  required /lib/security/$ISA/pam_wheel.so use_uid
    

    Este cambio significa que sólo los miembros del grupo administrativo wheel pueden utilizar el programa.

Añadiendo usuarios al grupo "wheel".

Panel de ilustración Grupos

Figura 43.2. Añadiendo usuarios al grupo "wheel".

Nota

El usuario root es parte del grupo wheel por defecto.

43.1.4.3.2. El comando sudo

El comando sudo ofrece otra solución para otorgar acceso administrativo a los usuarios. Cuando un usuario de confianza antecede un comando administrativo con sudo, se le pide su propia contraseña. Luego, una vez autenticado y asumiendo que el comando es permitido, el comando administrativo es ejecutado como que si se tratase del usuario root.

El formato básico del comando sudo es el siguiente:

sudo <comando>

En el ejemplo anterior, <comando> sería reemplazado por un comando normalmente reservado para el usuario root, tal como mount.

Importante

Los usuarios del comando sudo deberían tener cuidado adicional al desconectarse antes de abandonar sus máquinas puesto que otros pueden utilizar el comando nuevamente sin que se les solicite contraseña alguna por un período de hasta cinco minutos. Esta configuración se puede alterar a través del archivo de configuración, /etc/sudoers.

El comando sudo permite un gran nivel de flexibilidad. Por ejemplo, solo los usuarios listados en el archivo de configuración /etc/sudoers tienen permitido utilizar el comando sudo y el comando es ejecutado en el shell del usuario, no en el shell de root. Esto significa que el shell de root podría ser desactivado completamente, como se muestra en la Sección 43.1.4.2.1, “Deshabilitar el shell de root”.

El comando sudo también proporciona un rastro completo para auditoría. Cada autenticación exitosa es registrada al archivo /var/log/messages y el comando emitido junto con el nombre del usuario se registran en el archivo /var/log/secure.

Otra ventaja del comando sudo es que un administrador puede permitir a usuarios diferentes acceso a comandos específicos basado en sus necesidades.

Los administradores que deseen modificar el archivo de configuración de sudo, /etc/sudoers, deberían usar el comando visudo.

Para otorgarle a un usuario privilegios administrativos completos, escriba visudo y añada una línea similar a la siguiente en la sección de especificación de privilegios del usuario:

juan ALL=(ALL) ALL

Este ejemplo establece que el usuario, juan, puede utilizar sudo desde cualquier máquina y ejecutar cualquier comando.

El ejemplo dado a continuación muestra qué tan detallado puede llegar a ser la configuración de sudo:

%users localhost=/sbin/shutdown -h now

Este ejemplo establece que cualquier usuario puede emitir el comando /sbin/shutdown -h now siempre y cuando sea emitido desde la consola.

La página de manual para sudoers tiene un listado detallado de las opciones para este archivo.

43.1.5. Servicios de red disponibles

Mientras que el acceso de usuarios a los controles administrativos es un aspecto importante para los administradores de sistemas dentro de una organización, también es de suma importancia para el que instala o maneja un sistema Linux mantener un registro sobre cuáles servicios de red están activos.

Muchos servicios bajo Red Hat Enterprise Linux se comportan como servidores de red. Si un servicio de red está ejecutándose en una máquina, entonces hay una aplicación de servidor (llamada demonio) escuchando por conexiones en uno o más puertos de red. Cada uno de estos servidores debería ser tratado como una avenida potencial de ataque.

43.1.5.1. Riesgos a los servicios

Los servicios de red pueden implicar muchos riesgos para los sistemas Linux. Abajo se muestra una lista de algunos de los principales problemas:

  • Ataques de rechazo de servicio (Denial of Service, DoS) — Inundando un servicio con peticiones se puede producir un ataque de rechazo de servicio que llevaría al sistema a un estado suspendido, mientras éste intenta responder a cada petición.

  • Ataques de vulnerabilidad de scripts — Si un servidor esta usando scripts para ejecutar acciones del lado del servidor, como usualmente hacen los servidores Web, un pirata puede montar un ataque a los scripts que no hayan sido escritos de forma apropiada. Estos ataques de vulnerabilidad de scripts podrían llevar a una condición de desbordamiento del buffer o permitir al atacante alterar archivos en el sistema.

  • Ataques de desbordamiento del buffer — Los servicios que se conectan a puertos del 0 al 1023 deben ser ejecutados como un usuario administrativo. Si la aplicación tiene un posible desbordamiento del buffer, un atacante podría ganar acceso al sistema como el usuario ejecutando el demonio. Debido a que los desbordamientos del buffer existen, los maleantes informáticos usan herramientas automatizadas para identificar vulnerabilidades en los sistemas y una vez que han obtenido acceso, utilizan kits automatizados para mantener su acceso al sistema.

Nota

ExecShield puede mitigar las amenazas de un desbordamiento de la memoria intermedia en Red Hat Enterprise Linux. ExecShield es un ejecutable de segmentación de memoria y una tecnología de protección soportado por los kernels en uni o multi-procesadores x86. ExecShield reduce el riesgo del desbordamiento de memoria intermedia al separar la memoria virtual en segmentos ejecutables y no ejecutables. Cualquier código de programa que trate de ejecutarse en el segmento ejecutable (como por ejemplo, código malicioso inyectado desde un ataque de memoria intermedia) disparará una falla de segmentación y se cerrará.

ExecShield también incluye el soporte para la tecnología No eXecute (NX) en las plataformas AMD64 y la tecnología eXecute Disable (XD), en los sistemas Itanium y sistemas de 64 bits de Intel®. Estas tecnologías funcionan en conjunto con ExecShield para prevenir que el código malicioso se ejecute en la porción ejecutable de la memoria virtual con una granularidad de 4KB de código ejecutable, reduciendo el riesgo de un ataque desde un desbordamiento de búfer.

Concejo

Para limitar la exposición de ataques sobre la red, se deberían apagar todos los servicios que no se estén usando.

43.1.5.2. Identificación y configuración de servicios

Para mejorar la seguridad, la mayoría de los servicios de red instalados con Red Hat Enterprise Linux están desactivados por defecto. Sin embargo, hay algunas excepciones importantes:

  • cupsd — El servidor de impresión por defecto para Red Hat Enterprise Linux.

  • lpd — Un servidor de impresión alternativo.

  • xinetd — Un super servidor que controla las conexiones a una serie de servidores subordinados, tal como gssftp y telnet.

  • sendmail — El agente de transporte de correos Sendmail (MTA por sus siglas en inglés,Mail Transport Agent) está activado por defecto, pero sólo escucha conexiones desde localhost.

  • sshd — El servidor OpenSSH, el cual es un reemplazo seguro para Telnet.

Cuando se está determinando si se deben dejar estos servicios en ejecución, es mejor usar el sentido común y pecar por el lado de la cautela. Por ejemplo, si usted no tiene impresora, no deje cupsd ejecutándose. Lo mismo para portmap. Si no tiene volúmenes NFSv3 o utiliza NIS (el servicio ypbind), entonces portmap también debería esta desactivado.

Herramienta de configuración de servicios

Ilustración de la Herramienta de configuración de servicios

Figura 43.3. Herramienta de configuración de servicios

Si no está seguro del propósito de un servicio particular, la Herramienta de configuración de servicios, tiene un campo de descripción, mostrado en la Figura 43.3, “Herramienta de configuración de servicios, que puede ser de ayuda.

Pero el verificar cuáles servicios están disponibles al momento del arranque no es suficiente. Los buenos administradores de sistemas deberían verificar cuáles puertos están abiertos y escuchando. Consulte la Sección 43.2.8, “Verificar cuáles puertos están escuchando” para obtener mayor información.

43.1.5.3. Servicios inseguros

Algunos protocolos de red son inherentemente más inseguros que otros. Esto incluye cualquier servicio que:

  • Pase los nombres de usuarios y contraseñas sobre la red sin encriptar — Mucho protocolos viejos, tales como Telnet y FTP, no encriptan la sesión de autenticación y deberían ser evitados siempre que sea posible.

  • Pase datos confidenciales sobre la red sin encriptar — Muchos protocolos pasan información sobre la red sin encriptar. Estos protocolos incluyen Telnet, FTP, HTTP y SMTP. Muchos sistemas de archivos de red, tales como NFS y SMB también pasan la información sobre la red sin encriptar. Cuando se estén usando estos protocolos es responsabilidad del usuario limitar el tipo de datos que se transmite.

    Los servicios de volcado de memoria remota, como netdump, pasan los contenidos de la memoria sobre la red sin encriptar. Los volcados de memoria pueden contener contraseñas o, peor aún, entradas de la base de datos u otra información confidencial.

    Otros servicios como finger y rwhod revelan información sobre los usuarios del sistema.

Algunos ejemplos de servicios inseguros que han sido heredados son: rlogin, rsh, telnet y vsftpd.

Todos los programas de conexión y de shell remotos (rlogin, rsh y telnet), deberían ser evitados en favor de SSH. (consulte la Sección 43.1.7, “Herramientas de mejoramiento de la seguridad” para más información sobre sshd).

FTP no es tan inherentemente peligroso para la seguridad de los sistemas como lo son los shells remotos, pero los servidores FTP deben ser configurados y monitoreados cuidadosamente para evitar problemas. Consulte la Sección 43.2.6, “Protección de FTP” para obtener mayor información sobre cómo asegurar los servidores FTP.

Los servicios que deberían ser implementados con sumo cuidado y colocados detrás de un cortafuegos incluyen:

  • finger

  • authd (era llamado identd en versiones anteriores de Red Hat Enterprise Linux).

  • netdump

  • netdump-server

  • nfs

  • rwhod

  • sendmail

  • smb (Samba)

  • yppasswdd

  • ypserv

  • ypxfrd

En el Sección 43.2, “Seguridad de servidores” puede encontrar más información sobre el aseguramiento de los servicios de red.

La próxima sección discute las herramientas disponibles para configurar un cortafuegos sencillo.

43.1.6. Cortafuegos personales

Una vez configurados los servicios de red necesarios, es importante implementar un cortafuegos.

Importante

Se debe configurar los servicios necesarios e implementar un cortafuegos antes de conectar el sistema a Internet o a otra red no confiable.

Los cortafuegos previenen que los paquetes de red accedan a la interfaz de la red del sistema. Si se hace una petición a un puerto que está bloqueado por un cortafuegos, se ignorará la petición. Si un servicio está escuchando en uno de estos puertos bloqueados, no recibirá paquetes y estará efectivamente inhabilitado. Por esta razón, se debe tener cuidado cuando se configure un cortafuegos para bloquear el acceso a los puertos que no se usen, a la vez que no se bloquea el acceso a los puertos usados por los servicios configurados.

For most users, the best tool for configuring a simple firewall is the graphical firewall configuration tool which ships with Red Hat Enterprise Linux: the Herramienta de configuración del nivel de seguridad (system-config-securitylevel). This tool creates broad iptables rules for a general-purpose firewall using a control panel interface.

43.1.7. Herramientas de mejoramiento de la seguridad

En la medida que el tamaño y la popularidad de la Internet crece, así también ha crecido la interceptación de la comunicación. A lo largo de los años se han desarrollado herramientas para encriptar la comunicación cuando estas son llevadas sobre la red.

Red Hat Enterprise Linux se entrega con dos herramientas básicas que usan algoritmos de encriptación basados en criptografía de llaves pública de alto nivel para proteger la información a medida que ésta viaja sobre la red.

  • OpenSSH — Una implementación del protocolo SSH gratuita para la encriptación de las comunicaciones de la red.

  • Gnu Privacy Guard (GPG) — Una implementación gratuita de la aplicación de encriptación PGP (Pretty Good Privacy) para la encriptación de datos.

OpenSSH es una forma más segura de acceder a una máquina remota. Reemplaza los servicios no encriptados anteriores como telnet y rsh. OpenSSH incluye el servicio de red llamado sshd y tres aplicaciones cliente de línea de comandos:

  • ssh — Un cliente seguro de acceso a consola remota.

  • scp — Un comando seguro para hacer copias remotas.

  • sftp — Un cliente seudo ftp que permite sesiones de transferencia de archivos interactivas.

GPG es una excelente forma de asegurar las comunicaciones de correo electrónico. Puede ser usado tanto para enviar información confidencial a través de correo sobre redes públicas, como para proteger los datos confidenciales en los discos duros.

43.2. Seguridad de servidores

Cuando un sistema es usado como un servidor en una red pública, se convierte en un objetivo de ataques. Por esta razón, es de suma importancia para el administrador fortalecer el sistema y bloquear servicios.

Antes de extendernos en problemas particulares, debería revisar los siguientes consejos generales para mejorar la seguridad del servidor:

  • Mantenga todos los servicios actualizados para así protegerse de las últimas amenazas informáticas.

  • Utilice protocolos seguros siempre que sea posible.

  • Proporcione sólo un tipo de servicio de red por máquina siempre que sea posible.

  • Supervise todos los servidores cuidadosamente por actividad sospechosa.

43.2.1. Asegurando los servicios con TCP Wrappers y xinetd

Los TCP wrappers proporcionan control de acceso a una variedad de servicios. La mayoría de los servicios modernos de redes, tales como SSH, Telnet y FTP, utilizan TCP wrappers como guardias entre las peticiones entrantes y el servicio solicitado.

Los beneficios ofrecidos por TCP wrappers son mejorados cuando se usan en conjunto con xinetd, un super servicio que proporciona acceso adicional, conexión, enlace, redirección y control de la utilización de recursos.

Las siguientes subsecciones asumen que ya se tiene un conocimiento básico de cada tópico y se enfoca en opciones de seguridad específicas.

43.2.1.1. Mejorar la seguridad con TCP Wrappers

Los TCP Wrappers son capaces de mucho más que simplemente negar el acceso a servicios. Esta sección ilustra cómo se pueden usar para enviar pancartas de conexión, avisar sobre ataques desde hosts particulares y mejorar la funcionalidad de conexión. Para una lista detallada de la funcionalidad y el lenguaje de control de los TCP Wrappers, consulte la página del manual de hosts_options.

43.2.1.1.1. Los TCP Wrappers y las pancartas de conexión

Al mostrar una pancarta apropiada cuando los usuarios se conectan a un servicio es una buena forma de advertir a cualquier atacante potencial que el administrador del sistema está atento y vigilante. También se puede controlar la información del sistema que se presenta a los usuarios. Para implementar un mensaje de TCP wrapper para un servicio, utilice la opción banner.

Este ejemplo implementa una pancarta para vsftpd. Para comenzar, debe crear un archivo de pancartas. Este puede estar en cualquier lugar en el sistema, pero debe tener el mismo nombre que el demonio. Para este ejemplo, el archivo se llamará /etc/banners/vsftpd.

 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed. 

La señal %c proporciona una variedad de información del cliente, tal como el nombre de usuario y del host o el nombre del usuario y la dirección IP para hacer la conexión aún más intimidante.

Para que esta pancarta sea presentada a las conexiones entrantes, añada la siguiente línea al archivo /etc/hosts.allow:

 vsftpd : ALL : banners /etc/banners/ 
43.2.1.1.2. TCP Wrappers y las advertencias de ataques

Si se ha detectado a un host particular o a una red tratando de atacar al servidor, se pueden usar los TCP Wrappers para advertir de ataques subsecuentes desde esa máquina o red a través de la directiva spawn.

En este ejemplo, se asume que se ha detectado al cracker en la red 206.182.68.0/24 intentando atacar el servidor. Colocando la siguiente línea en el archivo /etc/hosts.deny, se niega el intento de conexión desde la red y se registra a un archivo especial:

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert 

La señal %d suministra el nombre del servicio que el atacante estaba tratando de acceder.

Para permitir la conexión y registrarla, coloque la directiva spawn en el archivo /etc/hosts.allow.

Nota

Puesto que la directiva spawn ejecuta cualquier comando del shell, puede crear un script especial para notificar al administrador o ejecutar una cadena de comandos en el evento de que un cliente particular intente conectarse al servidor.

43.2.1.1.3. TCP Wrappers y el mejoramiento de la conexión

Si ciertos tipos de conexión son de mayor preocupación que otros, se puede subir el nivel de conexión para ese servicio a través de la opción severity.

En este ejemplo, se asume que cualquiera que esté intentando conectarse al puerto 23 (el puerto de Telnet) en un servidor FTP, es un cracker. Para resaltarlo, coloque una bandera emerg en los archivos de registro en vez de la bandera por defecto, info, y niegue la conexión.

Para hacerlo, escriba la siguiente línea en /etc/hosts.deny:

 in.telnetd : ALL : severity emerg 

Esto usará la facilidad de conexión por defecto authpriv, pero subirá el nivel de prioridad del valor por defecto de info a emerg, lo cual manda los mensajes de registro directamente a la consola.

43.2.1.2. Aumentando la seguridad con xinetd

Esta sección se centra en el uso de xinetd para establecer un servicio trampa y controlar el nivel de recursos disponibles para cualquier servicio xinetd. Al establecer límites de recursos para los servicios dificulta los ataques de denegación de servicios (DoS). Para una lista de las opciones disponibles, consulte las páginas man de xinetd y xinetd.conf.

43.2.1.2.1. Colocando una Trampa

Una característica importante de xinetd es la habilidad de añadir hosts a una lista global de no_access. A los hosts en esta lista se les negará conexiones a los servicios manejados por xinetd por un tiempo determinado o hasta que se reinicie xinetd. Esto se logra usando el atributo SENSOR. Esta técnica es una forma fácil de bloquear máquinas que intenten escanear un puerto del servidor.

El primer paso en configurar un SENSOR es seleccionar un servicio que no planea utilizar. Para este ejemplo, se utilizará Telnet.

Modifique el archivo /etc/xinetd.d/telnet y cambie la línea flags para que muestre lo siguiente:

flags           = SENSOR

Agregue la línea siguiente:

deny_time       = 30

Esto negará al host el acceso al puerto por 30 minutos. Otros valores aceptables para el atributo deny_time son FOREVER, que mantiene el bloqueo hasta que se reinicie xinetd, y NEVER, que permite la conexión y la registra.

Finalmente, la última línea debería mostrar lo siguiente:

disable         = no

Esta línea activa la trampa.

Aún cuando el uso de SENSOR es una buena forma de detectar y detener conexiones de máquinas dañinas, tiene dos desventajas:

  • No funcionará contra escaneos sigilosos.

  • Un atacatante que sabe que usted está ejecutando un SENSOR puede montar un ataque DoS en contra de un host particular falsificando sus direcciones IP y conectándose al puerto prohibido.

43.2.1.2.2. Control de recursos del servidor

Otra característica importante de xinetd es la capacidad de controlar la cantidad de recursos que los servicios bajo su control pueden utilizar.

Esto se hace a través de las siguientes directrices:

  • cps = <number_of_connections> <wait_period> — Limita la tasa de conexiones entrantes. Esta directiva acepta dos argumentos:

    • <number_of_connections> — El número de conexiones por segundo que serán manejadas. Si la tasa de conexiones entrantes es mayor que el número de conexiones, el servicio es temporalmente inhabilitado. El valor por defecto es (50).

    • <wait_period> — El número de segundos de espera antes de activar el servicio cuando éste ha sido deshabilitado. El intervalo predeterminado son (10) segundos.

  • instances = <number_of_connections> — Indica el número total de conexiones permitidas al servicio. Esta directiva acepta bien sea un valor entero o UNLIMITED.

  • per_source = <number_of_connections> — Especifica el número de conexiones permitidas al servicio por cada host. Esta directiva acepta un valor entero o UNLIMITED.

  • rlimit_as = <number[K|M]> — Indica la cantidad de espacio de direcciones de memoria -en kilobytes o megabytes- que el servicio puede ocupar. Esta directiva acepta valores enteros o UNLIMITED.

  • rlimit_cpu = <number_of_seconds> — Indica la cantidad de tiempo en segundos que un servicio puede ocupar el CPU. Esta directiva acepta un valor entero o UNLIMITED.

El uso de estas directivas ayuda a prevenir que cualquier servicio xinetd sobresature el sistema, resultando en una denegación de servicio.

43.2.2. Protección de Portmap

El servicio portmap es un demonio de asignación de puertos dinámico para servicios RPC, tales como NIS y NFS. Tiene mecanismos de autenticación débiles y la habilidad de asignar un amplio rango de puertos para los servicios que controla. Por estas razones, es difícil de asegurar.

Nota

El asegurar portmap solamente afecta a las implementaciones de NFSv2 y NFSv3 , puesto que NFSv4 ya no lo requiere. Si planea implementar un servidor NFSv2 o NFSv3, entonces se requiere portmap. La sección siguiente es relevante en dicho caso.

Si está ejecutando servicios RPC, debería seguir algunas reglas básicas.

43.2.2.1. Proteja portmap con TCP Wrappers

Es importante utilizar TCP Wrappers para limitar las redes o máquinas que tienen acceso al servicio portmap puesto que éste no posee autenticación incorporada.

Además, utilice solamente direcciones IP cuando esté limitando el acceso al servicio. Evite los nombres de hosts, pues estos pueden ser falsificados a través de envenenamiento de DNS y otros métodos.

43.2.2.2. Proteja portmap con iptables

Para restringir más aún el acceso al servicio portmap, es aconsejable añadir reglas de iptables al servidor para así limitar el acceso a redes específicas.

A continuación se muestran dos ejemplos de comandos iptables. El primero permite conexiones TCP al puerto 111 (usado por el servicio portmap) desde la red 192.168.0/24. El segundo permite conexiones TCP al mismo puerto desde el host local. Esto es necesario para el servicio sgi_fam utilizado por Nautilus. Todos los demás paquetes son descartados.

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1  --dport 111 -j ACCEPT

Para limitar el tráfico UDP de forma similar, utilice el comando siguiente.

iptables -A INPUT -p udp -s! 192.168.0.0/24  --dport 111 -j DROP

43.2.3. Protección de NIS

El servicio de información de redes (NIS) es un servicio RPC llamado ypserv. Éste es usado en conjunto con portmap y otros servicios relacionados para distribuir mapas de nombres de usuarios, contraseñas y otra información confidencial a cualquier computador que se encuentre dentro de su dominio.

Un servidor NIS esta compuesto de varias aplicaciones. Ellas incluyen las siguientes:

  • /usr/sbin/rpc.yppasswdd — También llamado el servicio yppasswdd, este demonio permite a los usuarios cambiar sus contraseñas NIS.

  • /usr/sbin/rpc.ypxfrd — También llamado ypxfrd, es el demonio responsable de las transferencias de mapas NIS sobre la red.

  • /usr/sbin/yppush — Esta aplicación propaga las bases de datos NIS modificadas a múltiples servidores NIS.

  • /usr/sbin/ypserv — Este es el demonio del servidor NIS.

NIS es inseguro según los estándares actuales. No tiene mecanismos de autenticación de host y pasa toda la información sobre la red sin encriptación -incluyendo las contraseñas. Como consecuencia, se debe tener extremo cuidado cuando se configure una red que utilice NIS. Además, la configuración por defecto de NIS es insegura en sí misma.

Se recomienda que cualquiera que este planeando implementar un servidor NIS, primero asegure el servicio portmap como se describió en la Sección 43.2.2, “Protección de Portmap” y luego considere los siguientes aspectos.

43.2.3.1. Planee la red cuidadosamente

Debido a que NIS pasa información confidencial sin encriptar sobre la red, es importante que se ejecute el servicio detrás de un cortafuegos y en una red segmentada y segura. Cada vez que se transmite información NIS a través de una red insegura, hay riesgos de que sea interceptada. Un cuidadoso diseño de la red en este aspecto puede ayudar a prevenir violaciones de la seguridad.

43.2.3.2. Utilice un nombre de dominio NIS y de host de tipo contraseña

Cualquier máquina dentro de un dominio NIS puede usar comandos para extraer información desde el servidor sin necesidad de autenticación, siempre y cuando el usuario conozca el nombre DNS y del dominio del servidor NIS.

Por ejemplo, si alguien conecta una portátil a la red o irrumpe en la red desde afuera (y logra simular una dirección IP interna), el comando siguiente revelará el mapa /etc/passwd:

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

Si este atacante es un usuario root, podrá obtener el archivo /etc/shadow escribiendo el comando siguiente:

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

Nota

Si se utiliza Kerberos, el archivo /etc/shadow no se almacena dentro del mapa NIS.

Para hacer el acceso a los mapas NIS más difícil para un atacante, cree una cadena de caracteres aleatoria para el nombre DNS de la máquina, tal como o7hfawtgmhwg.domain.com. De la misma manera, cree un nombre aleatorio diferente para el nombre de dominio NIS. Esto hará mucho más difícil a un atacante accesar el servidor NIS.

43.2.3.3. Modifique el archivo /var/yp/securenets

NIS escuchará a todas las redes si el archivo /var/yp/securenets está en blanco o no existe (este es el caso predeterminado después de una instalación). Una de las primeras cosas que debería hacer es colocar los pares máscaras/redes en el archivo para que ypserv sólo responda a las peticiones desde la red adecuada.

A continuación se muestra una entrada de ejemplo de un archivo /var/yp/securenets:

255.255.255.0     192.168.0.0

Aviso

Nunca arranque el servidor NIS por primera vez sin crear el archivo /var/yp/securenets.

Esta técnica no proporciona protección ante un ataque de simulación de IP (IP spoofing), pero al menos coloca límites en qué redes servirá el servidor NIS.

43.2.3.4. Asigne puertos estáticos y uso de reglas iptables

A todos los servidores relacionados con NIS se les pueden asignar puertos específicos excepto por rpc.yppasswdd — el demonio que permite a los usuarios cambiar sus contraseñas de conexión. Asignar puertos a los otros dos demonios de servidores NIS, rpc.ypxfrd y ypserv, permite crear reglas de cortafuegos para proteger aún más los demonios del servidor NIS contra los intrusos.

Para hacer esto, añada las líneas siguientes a /etc/sysconfig/network:

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

Las siguientes reglas iptables se pueden emitir para establecer la red a la cual el servidor escucha a través de estos puertos:

iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 834 -j DROP
iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 835 -j DROP

Lo que significa que el servidor solo permite conexiones a los puertos 834 y 835 si las peticiones provienen de la red 192.168.0.0/24 y sin importar el protocolo.

43.2.3.5. Utilice autenticación Kerberos

Una de las debilidades inherentes más resaltantes cuando se utiliza NIS para autenticación, es que cada vez que un usuario se conecta a una máquina se envia el hash de la contraseña desde /etc/shadow a través de la red. Si un intruso obtiene acceso a un dominio NIS y rastrea el tráfico de la red, puede reunir fácilmente los nombres de usuarios y contraseñas. Con el tiempo suficiente, un programa de descifrado de contraseñas puede adivinar las contraseñas débiles y el atacante puede obtener acceso a una cuenta válida en la red.

43.2.4. Protección de NFS

Importante

La versión de NFS incluida en Red Hat Enterprise Linux, NFSv4, ya no requiere del servicio portmap como se describe en la Sección 43.2.2, “Protección de Portmap”. El tráfico NFS ahora utiliza TCP en todas las versiones, en vez de UDP, y se requiere cuando se utiliza NFSv4. NFSv4 incluye la autenticación de usuarios y grupos de Kerberos, como parte del módulo RPCSEC_GSS. Aún se incluye la información sobre portmap, puesto que Red Hat Enterprise Linux es compatible con NFSv2 y NFSv3 y estos lo necesitan.

43.2.4.1. Planee la red cuidadosamente

Debido a que NFSv4 tiene la habilidad de pasar toda la información encriptada sobre la red usando Kerberos, es importante que el servicio sea configurado correctamente si se encuentra detrás de un cortafuegos o en un segmento de la red. NFSv2 y NFSv3 aún envían la información de forma insegura. Un diseño cuidadoso en este aspecto puede ayudar a prevenir violaciones de la seguridad.

43.2.4.2. Cuidado con los errores sintácticos

El servidor NFS determina cuáles sistemas de archivos exportar y a cuáles máquinas exportar estos directorios a través del archivo /etc/exports. Tenga cuidado de no añadir espacios adicionales cuando edite este archivo.

Por ejemplo, la línea siguiente en el archivo /etc/exports comparte el directorio /tmp/nfs/ al host bob.example.com con permisos de lectura y escritura.

/tmp/nfs/     bob.example.com(rw)

Por otro lado, esta línea en el archivo /etc/exports, comparte el mismo directorio con el host bob.example.com con permisos de sólo lectura y lo comparte con todo el mundo con permisos de lectura y escritura debido al espacio en blanco luego del nombre de la máquina.

/tmp/nfs/     bob.example.com (rw)

Es un buen hábito verificar cualquier directorio compartido NFS usando el comando showmount para verificar que está siendo compartido:

showmount -e <hostname>

43.2.4.3. No utilice la opción no_root_squash

Por defecto, los directorios compartidos NFS cambian el usuario root por el usuario nfsnobody, una cuenta de usuario sin privilegios. De esta forma, todos los archivos creados por root son propiedad del usuario nfsnobody, lo que previene la carga de programas con el bit setuid establecido.

Si se utiliza no_root_squash, los usuarios remotos podrán cambiar cualquier archivo en el sistema de archivos compartido y dejar aplicaciones con troyanos para que otros usuarios las ejecuten inadvertidamente.

43.2.5. Protegiendo el servidor Apache HTTP

El Servidor Apache HTTP es uno de los servicios más estables y seguros que se entregan con Red Hat Enterprise Linux. Hay una cantidad impresionante de opciones y técnicas disponibles para asegurar el servidor Apache HTTP — demasiadas para verlas en profundidad en este documento.

Los administradores de sistemas deben ser cuidadosos cuando utilicen las siguientes opciones de configuración:

43.2.5.1. FollowSymLinks

Esta directiva está activada por defecto, por lo tanto tenga cuidado al crear enlaces simbólicos al documento raíz del servidor Web. Por ejemplo, es una mala idea proporcionar un enlace simbólico a /.

43.2.5.2. La directiva Indexes

Esta directiva está activada por defecto, pero puede que no sea recomendable. Si no desea que los usuarios hojeen los archivos en el servidor, es mejor que elimine esta directiva.

43.2.5.3. La directiva UserDir

La directiva UserDir está desactivada por defecto porque puede confirmar la presencia de una cuenta de usuario en el sistema. Si desea activar la navegación del directorio del usuario en el servidor, utilice las directivas siguientes:

UserDir enabled
UserDir disabled root

Estas directivas activan la navegación del directorio del usuario para todos los directorios de usuarios excepto /root. Si desea añadir usuarios a la lista de cuentas deshabilitadas, añada una lista de usuarios separadas por espacios en la línea UserDir disabled.

43.2.5.4. No elimine la directiva IncludesNoExec

Por defecto, el módulo Server-Side Includes (SSI no pueden ejecutar comandos. No se recomienda modificar esta configuración a menos que tenga absoluta necesidad de hacerlo, puesto que potencialmente habilita a que un atacante pueda ejecutar comandos en el sistema.

43.2.5.5. Limite los permisos para los directorios ejecutables

Asegúrese de que solamente el usuario root tenga permisos de escritura para cualquier directorio que contenga scripts o CGIs. Esto se puede lograr escribiendo los comandos siguientes:

chown root <directory_name>
chmod 755 <directory_name>

Importante

Verifique que cualquier script que esté ejecutando en el sistema funcione como se espera antes de colocarlos en producción.

43.2.6. Protección de FTP

El Protocolo de transferencia de archivos (FTP), es un protocolo TCP antiguo diseñado para transferir archivos sobre la red. Debido a que todas las transacciones con el servidor no son encriptadas, incluyendo la autenticación de usuarios, se considera un protocolo inseguro y debería ser configurado cuidadosamente.

Red Hat Enterprise Linux proporciona tres servidores FTP.

  • gssftpd — Un demonio FTP kerberizado basado en xinetd que no pasa información de autenticación sobre la red.

  • Red Hat Content Accelerator (tux) — Un servidor Web con espacio kernel que posee capacidades de FTP.

  • vsftpd — Una implementación de servicio FTP independiente y orientado a la seguridad.

Las siguientes pautas de seguridad son para la configuración del servicio FTP vsftpd.

43.2.6.1. Pancarta de saludo de FTP

Antes de suministrar un nombre de usuario y contraseña, a todos los usuarios se les presenta una pancarta de saludo. Por defecto, esta pancarta incluye información relacionada con la versión, lo que es útil para los maleantes informáticos que estén intentando averiguar las debilidades del sistema.

Para cambiar la pancarta de bienvenida para vsftpd, añada la directiva siguiente a /etc/vsftpd/vsftpd.conf:

ftpd_banner=<insert_greeting_here>

Reemplace <insert_greeting_here> en la directiva de arriba con el texto de su mensaje de bienvenida.

Para pancartas de varias líneas, es mejor utilizar un archivo de pancartas. Para simplificar la administración de múltiples pancartas, coloque todas las pancartas en un nuevo directorio llamado /etc/banners/. El archivo de pancartas para las conexiones FTP en este ejemplo será /etc/banners/ftp.msg. Abajo se muestra un ejemplo de como se vería tal archivo:

######### # Hola, toda actividad en ftp.example.com es registrada. #########

Nota

No es necesario comenzar cada línea del archivo con 220 como se especifica en la Sección 43.2.1.1.1, “Los TCP Wrappers y las pancartas de conexión”.

Para hacer referencia a este archivo de pancartas desde vsftpd, añada la siguiente directiva al archivo /etc/vsftpd/vsftpd.conf:

banner_file=/etc/banners/ftp.msg

También es posible enviar pancartas adicionales a las conexiones entrantes usando TCP wrappers como se describió en la Sección 43.2.1.1.1, “Los TCP Wrappers y las pancartas de conexión”.

43.2.6.2. Acceso anónimo

La presencia del directorio /var/ftp/ activa la cuenta anónima.

La forma más fácil de crear este directorio es instalando el paquete vsftpd. Este paquete configura un árbol de directorios y configura los permisos en estos directorios como de sólo lectura para los usuarios anónimos.

Por defecto los usuarios anónimos no pueden escribir a estos directorios.

Atención

Si está activando el acceso anónimo a un servidor FTP, tenga cuidado de dónde guarda información confidencial.

43.2.6.2.1. Carga anónima

Si desea permitir a los usuarios anónimos que carguen archivos al servidor, se recomienda que cree un directorio de sólo escritura dentro de /var/ftp/pub/.

Utilice el comando siguiente.

mkdir /var/ftp/pub/upload

Luego, cambie los permisos para que los usuarios anónimos no puedan ver qué hay dentro del directorio:

chmod 730 /var/ftp/pub/upload

Un listado de formato largo del directorio debería verse como:

drwx-wx---    2 root     ftp          4096 Feb 13 20:05 upload

Aviso

Los administradores que permiten a los usuarios anónimos leer y escribir en directorios, a menudo encuentran que sus servidores se convierten en depósitos de software robado.

Adicionalmente, bajo vsftpd, añada la línea siguiente a /etc/vsftpd/vsftpd.conf:

anon_upload_enable=YES

43.2.6.3. Cuentas de usuarios

Debido a que FTP pasa los nombres de usuarios y contraseñas sobre redes inseguras sin encriptar, es una buena idea negar a los usuarios del sistema el acceso al servidor desde sus cuentas de usuario.

Para inhabilitar las cuentas de usuarios en vsftpd, añada la siguiente directiva a /etc/vsftpd/vsftpd.conf:

local_enable=NO
43.2.6.3.1. Restringir cuentas de usuarios

También es posible desactivar las cuentas de usuario dentro de cada servicio directamente.

Para deshabilitar una cuenta de usuario específica en vsftpd, añada el nombre de usuario a /etc/vsftpd.ftpusers.

43.2.6.4. Usar TCP Wrappers para controlar el acceso

Utilice TCP Wrappers para controlar el acceso a cualquier demonio FTP como se describió en la Sección 43.2.1.1, “Mejorar la seguridad con TCP Wrappers”.

43.2.7. Asegurando Sendmail

Sendmail es un Agente de transporte de correos (MTA) que utiliza el protocolo simple de transferencia de correo electrónico (SMTP, según sus siglas en inglés) para entregar mensajes electrónicos entre otros MTA y a clientes de correo o agentes de entrega. Aún cuando muchos MTAs son capaces de encriptar el tráfico entre unos y otros, la mayoría no lo hacen, por tanto el envío de correos electrónicos sobre redes públicas es considerado una forma insegura de comunicación.

Se recomienda que cualquiera que esté planeando implementar un servidor Sendmail, tenga en cuenta los siguientes problemas.

43.2.7.1. Limitar los Ataques de Rechazo de Servicio (DoS)

Debido a la naturaleza del correo electrónico, un atacante determinado puede inundar fácilmente el servidor con correos y de esta manera causar un rechazo de servicio. Se puede limitar la efectividad de tales ataques colocando límites a las siguientes directrices en /etc/mail/sendmail.mc.

  • confCONNECTION_RATE_THROTTLE — El número de conexiones que el servidor puede recibir por segundo. Por defecto, Sendmail no limita el número de conexiones. Si se establece un límite y este es alcanzado, las conexiones siguientes son retrasadas.

  • confMAX_DAEMON_CHILDREN — El máximo número de procesos hijo que se pueden producir por el servidor. Por defecto, Sendmail no asigna un límite al número de procesos hijos. Si se coloca un límite y este es alcanzado, las conexiones siguientes son retrasadas.

  • confMIN_FREE_BLOCKS — El número mínimo de bloques libres que debe haber disponible para que el servidor acepte correos. Por defecto es 100 bloques.

  • confMAX_HEADERS_LENGTH — El tamaño máximo aceptable (en bytes) para la cabecera de un mensaje.

  • confMAX_MESSAGE_SIZE — El tamaño máximo aceptable (en bytes) para cualquier mensaje.

43.2.7.2. NFS y Sendmail

Nunca coloque el directorio spool de correos, /var/spool/mail/, en un volumen compartido NFS.

Debido a que NFSv2 y NFSv3 no mantiene un control sobre los IDs de usuarios y de grupos, dos o más usuarios pueden tener el mismo UID y, por tanto, recibir y leer los correos electrónicos del otro.

Nota

Con NFSv4 usando Kerberos, este no es el caso, puesto que el módulo del kernel SECRPC_GSS no utiliza una autenticación basándose en UID. Sin embargo, se considera una buena práctica el no ubicar el directorio spool de correos en un volumen compartido NFS.

43.2.7.3. Usuarios de correo únicamente

Para ayudar a prevenir explotaciones del usuario local en el servidor Sendmail, es mejor que los usuarios de correo electrónico solamente accedan al servidor Sendmail usando un programa de correo. No deberían permitirse las cuentas shell en el servidor de correo y todos los usuarios shell en el archivo /etc/passwd deberían ser colocados a /sbin/nologin (con la posible excepción del usuario root).

43.2.8. Verificar cuáles puertos están escuchando

Una vez que haya configurado los servicios en la red, es importante poner atención sobre cuáles puertos estan escuchando en realidad en las interfaces de red del sistema. Cualquier puerto abierto puede ser una evidencia de una intrusión.

Existen dos soluciones básicas para listar los puertos que están escuchando en la red. La solución menos confiable es consultar la pila de la red escribiendo comandos tales como netstat -an o lsof -i. Este método es menos confiable puesto que estos programas no conectan a la máquina desde la red, solo verifican que está ejecutándose en el sistema. Por esta razón, estas aplicaciones son objetivos frecuentes de atacantes que reemplazan netstat y lsof con sus propias versiones para intentan cubrir sus rastros cuando abren puertos no autorizados.

Una forma más confiable de verificar qué puertos están escuchando en la red es usar un escaner de puertos como nmap.

El comando siguiente ejecutado desde la consola, determina cuáles puertos están escuchando por conexiones TCP desde la red:

nmap -sT -O localhost

La salida de este comando es parecida a lo siguiente:

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1653 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE
22/tcp    open  ssh 
25/tcp    open  smtp
111/tcp   open  rpcbind
113/tcp   open  auth
631/tcp   open  ipp
834/tcp   open  unknown
2601/tcp  open  zebra
32774/tcp open  sometimes-rpc11
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Uptime 12.857 days (since Sat Sep 11 17:16:20 2004)

Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds

Esta salida muestra que el sistema está ejecutando portmap debido a la presencia del servicio sunrpc. Sin embargo, existe también un servicio misterioso en el puerto 834. Para verificar si el puerto está asociado con la lista oficial de servicios conocidos, escriba:

cat /etc/services | grep 834

Este comando no devuelve ninguna salida. Esto indica que aunque el puerto está en el rango reservado (es decir del 0 al 1023) y requiere acceso root para ser abierto, no está asociado con un servicio conocido.

Luego, puede verificar la información sobre el puerto usando netstat o lsof. Para verificar el puerto 834 usando netstat, utilice el comando siguiente:

netstat -anp | grep 834

El comando devuelve la siguiente salida:

tcp   0    0 0.0.0.0:834    0.0.0.0:*   LISTEN   653/ypbind

La presencia de un puerto abierto en netstat es tranquilizante puesto que un maleante abriendo un puerto furtivamente en un sistema violado, posiblemente no se revelaría a través de este comando. Además, la opción [p] revela el id del proceso (PID) del servicio que abrió el puerto. En este caso, el puerto abierto pertenece a ypbind (NIS), que es un servicio RPC manejado en conjunto con el servicio portmap.

El comando lsof revela información similar a la dada por netstat puesto que es capaz de enlazar puertos abiertos a servicios:

lsof -i | grep 834

A continuación se encuentra la porción relevante de la salida de este comando:

ypbind      653        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      655        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      656        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      657        0    7u  IPv4       1319                 TCP *:834 (LISTEN)

Estas herramientas pueden revelar bastante información sobre el estado de los servicios ejecutándose en la máquina. Estas herramientas son flexibles y pueden proporcionar gran cantidad de información sobre los servicios de red y la configuración. Se recomienda la revisión de las páginas man para lsof, netstat, nmap, y services.

43.3. Single Sign-on (SSO)

43.3.1. Introducción

La funcionalidad SSO de Red Hat Enterprise Linux reduce el número de veces que los usuarios de escritorios Red Hat Enterprise Linux deben introducir sus contraseñas. Varias aplicaciones utilizan los mismos mecanismos de autenticación y autorización para que los usuarios puedan registrarse en Red Hat Enterprise Linux desde una pantalla de registro y luego no tengan que introducir la contraseña de nuevo. Estas aplicaciones se detallan a continuación.

Además, los usuarios pueden registrarse a sus máquinas incluso si no existe una red (modo fuera de línea) o donde la conexión a la red no es confiable, como es el caso del acceso inalámbrico. En este último caso, los servicios son degradados progresivamente.

43.3.1.1. Aplicaciones soportadas

Las siguientes aplicaciones están actualmente soportadas por el esquema de registro unificado en Red Hat Enterprise Linux:

  • Registro

  • Salvapantalla

  • Firefox y Thunderbird

43.3.1.2. Mecanismos de autenticación soportados

Red Hat Enterprise Linux actualmente soporta los siguientes mecanismos de autenticación:

  • Registro nombre/contraseña de Kerberos

  • Tarjetas inteligentes/PIN

43.3.1.3. Tarjetas inteligentes soportadas

Red Hat Enterprise Linux has sido verificado con tarjetas y lectores Cyberflex e-gate pero cualquier tarjata que acate las especificaciones Java card 2.1.1 y Global Platform 2.0.1 debe operar correctamente. Así mismo, cualquier lector que es soportado por PCSC-lite debe funcionar.

Red Hat Enterprise Linux también ha sido probado con tarjetas de acceso común (CAC por sus siglas en inglés). El lector soportado para CAC es SCM SCR 331 USB Reader.

As of Red Hat Enterprise Linux 5.2, Gemalto smart cards (Cyberflex Access 64k v2, standard with DER SHA1 value configured as in PKCSI v2.1) are now supported. These smart cards now use readers compliant with Chip/Smart Card Interface Devices (CCID).

43.3.1.4. Ventajas de SSO en Red Hat Enterprise Linux

Actualmente existen varios mecanismos de seguridad que utilizan un gran número de protocolos y credenciales. Entre éstos se encuentran SSL, SSH, IPsec y Kerberos. SSO de Red Hat Enterprise Linux pretende unificar estos esquemas para soportar los requerimientos listados anteriormente. Esto no significa reemplazar Kerberos con certificados X.509v3, pero unificarlos para reducir la carga tanto en los usuarios de los sistemas como de los administradores que los administran.

Para alcanzar este objetivo, Red Hat Enterprise Linux:

  • Proporciona una biblioteca compartida NSS crypto única en cada sistema operativo.

  • Entrega el sistema de certificados cliente de seguridad empresarial ESC (por sus siglas en inglés Enterprise Security Client) con el sistema operativo base. La aplicación ESC verifica los eventos de inserción de tarjetas inteligentes.Si se detecta que el usuario ha insertado una tarjeta inteligente que fue diseñada para ser usada en el producto servidor de sistema de certificado de Red Hat Enterprise Linux, se mostrará una interfaz de usuario con instrucciones sobre cómo inscribir esa tarjeta inteligente.

  • Unifica Kerberos y NSS para que los usuarios que se registran en el sistema operativo utilizando una tarjeta inteligente también puedan obtener las credenciales de Kerberos (lo cual les permitirá registrarse en servidores de archivos y otros).

43.3.2. Iniciando con su nueva tarjeta inteligente

Antes de que pueda utilizar la tarjeta inteligente para registrarse a su sistema y aprovechar las ventajas de seguridad que esta tecnología proporciona, usted tendrá que ejecutar algunas tareas básicas de instalación y configuración. Estas tareas se describen a continuación:

Nota

Esta sección proporciona una visión general de la utilización de tarjetas inteligentes. Información más detallada puede encontrarse en el Manual de Clientes de Seguridad Empresarial del Sistema de Certificados de Red Hat.

  1. Registrese con su nombre y contraseña de Kerberos

  2. Asegúrese de que el paquete nss-tools esté cargado.

  3. Descargue e instale su certificado root específico para la corporación. Utilice el siguiente comando para instalar el certificado CA root:

    certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" -i ./ca_cert_in_base64_format.crt
    
  4. Verifique que tiene los siguientes RPM instalados en su sistema: esc, pam_pkcs11, coolkey, ifd-egate, ccid, gdm, authconfig y authconfig-gtk.

  5. Activar el soporte de registro de la tarjeta inteligente

    1. En la barra de menú de Gnome, seleccione Sistema->Administración->Autenticación.

    2. Escriba la contraseña de root de su máquina si ésta es necesaria.

    3. En el diálogo de configuración de la autenticación, haga clic en la pestaña Autenticación.

    4. Seleccione la casilla de verificación Activar soporte de tarjetas inteligentes.

    5. Haga clic en el botón Configurar tarjeta inteligente... para ver el diálogo de parámetros de la tarjeta inteligente y especifique los parámetros requeridos:

      • Requiere tarjeta inteligente para entrar — Desactive esta casilla de verificación. Una vez usted ha iniciado una sesión de forma satisfactoria con la tarjeta inteligente, usted puede seleccionar esta opción para prevenir que los usuarios se registren sin tarjetas inteligentes.

      • Acción de remoción de tarjeta — Esto controla la acción a tomar una vez usted remueva la tarjeta inteligente después de haber iniciado la sesión. Las opciones disponibles son:

        • Lock — Al remover la tarjeta se bloqueará la pantalla X.

        • Ignore — La remoción de la tarjeta no tiene ningún efecto.

  6. Si necesita activar el Online Certificate Status Protocol (OCSP), abra el archivo /etc/pam_pkcs11/pam_pkcs11.conf y ubique la línea siguiente:

    enable_ocsp = false;

    Cambie este valor a "true", como se señala a continuación:

    enable_ocsp = true;

  7. Inscriba su tarjeta inteligente

  8. Si está utilizando una tarjeta CAC, deberá también ejecutar los siguientes pasos:

    1. Desde una cuenta de root cree un archivo llamado /etc/pam_pkcs11/cn_map.

    2. Añada la siguiente entrada al archivo cn_map:

      <MY.CAC_CN.123454> -> <mi-login-id>

      Donde <MY.CAC_CN.123454> es el nombre común en su CAC y <mi-login-id> es su login ID de UNIX.

  9. Logout

43.3.2.1. Solución de problemas

Si tiene problemas al tratar de hacer funcionar su tarjeta inteligente, intente el siguiente comando para ubicar la fuente del problema:

pklogin_finder debug

Si ejecuta la herramienta pklogin_finder en modo de depuración mientras un tarjeta inteligente inscrita está conectada, se intentará obtener la información sobre la validez de los certificados y verificará si se puede relacionar el login ID con uno de los certificados presentes en la tarjeta.

43.3.3. Cómo funciona la inscripción de las tarjetas inteligentes

Las tarjetas inteligentes están inscritas cuando han recibido un certificado firmado por una autoridad certificadora (CA por sus siglas en inglés,Certificate Authority). Este proceso incluye los pasos que se describen a continuación:

  1. El usuario introduce la tarjeta inteligente en el lector de tarjatas de la estación de trabajo. Este evento es reconocido por el cliente de seguridad empresarial (ESC).

  2. Se muestra la página de inscripción en el escritorio del usuario. El usuario completa la infromación requerida y el sistema del usuario se conecta al sistema de procesamiento de Token (TPS por sus siglas en inglés, Token Processing System) y al CA.

  3. El TPS inscribe la tarjeta inteligente utilizando el certificado firmado por el CA.

Cómo funciona la inscripción de las tarjetas inteligentes

Cómo funciona la inscripción de las tarjetas inteligentes.

Figura 43.4. Cómo funciona la inscripción de las tarjetas inteligentes

43.3.4. Cómo funciona el registro de las tarjetas inteligentes

Esta sección describe brevemente el proceso de registro utilizando una tarjeta inteligente.

  1. Cuando el usuario inserta la tarjeta inteligente en el lector, la facilidad PAM reconoce el evento y solicita el PIN del usuario.

  2. El sistema luego busca el certificado actual del usuario y verifica su validez. El certificado es luego relacionado con el UID del usuario.

  3. Éste es validado con el KDC y el login es concedido.

Cómo funciona el registro de las tarjetas inteligentes

Cómo funciona el registro de las tarjetas inteligentes.

Figura 43.5. Cómo funciona el registro de las tarjetas inteligentes

Nota

Usted no puede registrarse con una tarjeta que no ha sido inscrita, incluso si ésta tiene el formato correcto. Deberá registrarse con una tarjeta formateada e inscrita -o con otro método diferente, antes de inscribir una nueva tarjeta.

43.3.5. Configuración de Firefox para utilizar Kerberos con SSO

Usted puede configurar Firefox para utilizar Kerberos con SSO. Para que esta funcionalidad funcione apropiadamente, tendrá que configurar su navegador para que envíe credenciales Kerberos al KDC apropiado.

  1. En la barra de direcciones de Firefox, escriba about:config para ver la lista de opciones de configuración actuales.

  2. En el campo Filter escriba negotiate para restringir la lista de opciones.

  3. Haga doble clic en la entrada network.negotiate-auth.trusted-uris para ver la ventana de diálogo Enter string value.

  4. Introduzca el nombre del dominio desde el cual desea llevar a cabo la autenticación (p. ej. .ejemplo.com).

  5. Repita el procedimiento anterior para la entrada network.negotiate-auth.delegation-uris y utilice el mismo dominio.

    Nota

    Puede dejar este valor en blanco ya que el pase de tiquetes de Kerberos no es requerido.

    Si no encuentra estas dos opciones listadas, su versión de Firefox es demasiado vieja y podría no soportar la negociación de la autenticación. En dicho caso, usted debería considerar actualizar Firefox.

Configuración de Firefox para SSO con Kerberos

Configuración de Firefox para utilizar Kerberos con SSO.

Figura 43.6. Configuración de Firefox para SSO con Kerberos

Ahora debe asegurarse de tener tickets de kerberos. En un intérprete de comandos de shell escriba kinit para obtener tickets de Kerberos. Para ver la lista de tickets disponibles escriba klist. A continuación se presenta un ejemplo de la respuesta de dicho comando:

[user@host ~] $ kinit
Password for user@EXAMPLE.COM:

[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: user@EXAMPLE.COM

Valid starting     Expires            Service principal
10/26/06 23:47:54  10/27/06 09:47:54  krbtgt/USER.COM@USER.COM
        renew until 10/26/06 23:47:54

Kerberos 4 ticket cache: /tmp/tkt10920
klist: You have no tickets cached

43.3.5.1. Solución de problemas

Si ha seguido los pasos de configuración anteriores y la negociación de la autenticación no está funcionando, puede activar la salida verbosa del registro del proceso de autenticación. Esto puede ayudarlo a encontrar la causa del problema. Para activar la salida verbosa del registro, utilice el siguiente procedimiento:

  1. Cierre todas las ventanas de Firefox.

  2. Abra una consola e introduzca el siguiente comando:

    export NSPR_LOG_MODULES=negotiateauth:5
    export NSPR_LOG_FILE=/tmp/moz.log
    
  3. Reinicie Firefox desde esa consola y visite el sitio web al cual no pudo autenticarse anteriormente. La información será registrada en /tmp/moz.log. Ésta le dará pistas sobre el problema. Por ejemplo:

    -1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken()
    -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure
    No credentials cache found
    

    Esto indica que usted no tiene tickets de Kerberos y necesita ejecutar kinit.

Si puede ejecutar kinit satisfactoriamente desde su máquina pero no puede autenticarse, verá un mensaje similar al siguiente en el archivo de registro:

-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()
-1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure
Server not found in Kerberos database

Esto generalmente indica que hay un problema en la configuración de Kerberos. Asegúrese de tener las entradas correctas en la sección [domain_realm] del archivo /etc/krb5.conf. Por ejemplo:

.ejemplo.com = EJEMPLO.COM
ejemplo.com = EJEMPLO.COM

Si nada aparece el el archivo de registro es posible que usted esté conectándose a un proxy y que éste está cortando las cabeceras HTTP requeridas para la negociación de la autenticación. Para solucionar este problema, usted puede conectarse al servidor utilizando HTTPS; esto permitirá que la solicitud pase sin ser modificada. Luego continúe con la depuración utilizando el archivo de registro como se describió anteriormente.

43.4. Pluggable Authentication Modules (PAM)

Los programas que conceden accesos a usuarios en un sistema utilizan autenticación para verificar sus identidades (para establecer que un usuario es quien dice ser).

Históricamente, cada programa tiene su forma particular de realizar la autenticación. Bajo Red Hat Enterprise Linux, muchos programas son configurados para usar un proceso de autenticación centralizado llamado PAM (Pluggable Authentication Modules).

PAM utiliza una arquitectura conectable y modular, que otorga al administrador del sistema de una gran flexibilidad en establecer las políticas de autenticación para el sistema.

En la mayoría de los casos, el archivo de configuración PAM predeterminado para una aplicación que soporta PAM es suficiente. Sin embargo, algunas veces es necesario modificar el archivo de configuración. Debido a que un error en la configuración de PAM puede comprometer la seguridad del sistema, es importante que comprenda la estructura del estos archivos antes de hacer cualquier modificación. Consulte Sección 43.4.3, “Formato del archivo de configuración PAM” para obtener mayor información.

43.4.1. Las ventajas de PAM

PAM ofrece las ventajas siguientes:

  • un esquema de autenticación común que se puede usar con una gran variedad de aplicaciones.

  • gran flexibilidad y control de la autentificación tanto para los administradores de sistemas como para los desarrolladores de la aplicación.

  • una biblioteca bien documentada que permite a los desarrolladores de aplicaciones desarrollar programas sin tener que crear sus propios esquemas de autenticación.

43.4.2. archivos de configuración PAM

El directorio /etc/pam.d/ contiene los archivos de configuración de PAM para cada aplicación tipo PAM. En versiones antiguas de PAM se utilizaba /etc/pam.conf, pero este archivo ya no se utiliza y solamente es usado si el directorio /etc/pam.d/ no existe.

43.4.2.1. Archivos de servicios PAM

Cada aplicación tipo PAM o servicios tiene un archivo dentro del directorio /etc/pam.d/. Cada uno de estos archivos llevan el nombre del servicio para el cual controla el acceso.

Depende del programa tipo PAM definir el nombre de su servicio e instalar su archivo de configuración en el directorio /etc/pam.d/. Por ejemplo, el programa login define su nombre de servicio como login e instala el archivo de configuración PAM /etc/pam.d/login.

43.4.3. Formato del archivo de configuración PAM

Cada archivo de configuración PAM contiene un grupo de directivas formateadas como sigue:

<module interface><control flag><module name><module arguments>

En las siguientes secciones se explican cada uno de estos elementos.

43.4.3.1. Interfaz de módulo

Hay cuatro tipos de módulos PAM disponibles. Cada uno corresponde con un aspecto diferente del proceso de autorización:

  • auth — Esta interfaz de módulo autentifican el uso. Por ejemplo, solicita y verifica la validez de una contraseña. Los módulos con esta interfaz también pueden establecer credenciales, tales como membrecías de grupo o tickets Kerberos.

  • account — Esta interfaz de módulo verifica que sea permitido el acceso. Por ejemplo, puede verificar que la cuenta no haya caducado o que el usuario tenga permiso de iniciar sesiones a una hora del día particular.

  • password — Este módulo se usa para establecer y verificar contraseñas.

  • session — Esta interfaz de módulo configura y administra las sesiones de usuarios. Los módulos con esta interfaz también pueden realizar tareas adicionales que son requeridas para permitir acceso, como el montaje de directorios principales de usuarios y hacer el buzón de correo del usuario disponible.

Nota

Un módulo individual puede proporcionar una o todas las interfaces de módulos mencionadas anteriormente. Por ejemplo, pam_unix.so proporciona todas las cuatro interfaces.

En un archivo de configuración PAM, la interfaz del módulo es el primer campo a definir. Por ejemplo, una línea típica de una configuración sería:

auth        required        pam_unix.so

Esto provoca que PAM utilice la interfaz pam_unix.so del módulo auth.

43.4.3.1.1. Apilar interfaces de módulos

Las directivas de interfaces de módulos pueden ser apiladas o colocadas una sobre otra para que se puedan usar múltiples módulos para un mismo propósito. Si la opción de control de un módulo utiliza los valores "sufficient" o "requisite" (consulte la Sección 43.4.3.2, “Indicadores de control” para obtener información acerca de estos valores) el orden de una pila de módulos es importante en el procedimiento de autenticación.

El hecho de apilarlos hace que sea más fácil para que el administrador exija diversas condiciones antes de permitir la autenticación del usuario. Por ejemplo, el comando reboot utiliza generalmente una pila de módulos, como se ve en su archivo de configuración:

[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth        sufficient        pam_rootok.so
auth        required        pam_console.so
#auth        include        system-auth
account        required        pam_permit.so
  • La primera línea es un comentario y no es procesada.

  • auth sufficient pam_rootok.so — Esta línea utiliza el módulo pam_rootok.so para revisar si el usuario actual es root, verificando que su UID sea igual a 0. Si esta prueba tiene éxito, ningún otro módulo es consultado y el comando es ejecutado. De lo contrario se consultará el siguiente módulo.

  • auth required pam_console.so — Esta línea utiliza el módulo pam_console.so para intentar autenticar al usuario. Si este usuario ya tiene una sesión en la consola, pam_console.so revisa si hay un archivo en el directorio /etc/security/console.apps/ con el mismo nombre que el servicio (reboot). Si dicho archivo existe, la autenticación pasa y el control es pasado al siguiente módulo.

  • #auth include system-auth — Esta línea es un comentario y no será procesada.

  • account required pam_permit.so — Esta línea utiliza el módulo pam_permit.so para permitir que el usuario root o cualquiera con una sesión en la consola puede reiniciar el sistema.

43.4.3.2. Indicadores de control

Todos los módulos PAM generan un resultado de éxito o fracaso cuando se les llama. Los indicadores de control le dicen a PAM qué hacer con el resultado. Como los módulos pueden apilarse en un determinado orden, los indicadores de control le dan la posibilidad de fijar la importancia de un módulo con respecto al objetivo final del proceso de autenticación para el servicio.

Hay cuatro indicadores de control definidos:

  • required — El resultado del módulo debe ser exitoso para que la autenticación continue. Si la prueba falla, el usuario no es notificado hasta que los resultados en todos los módulos referenciando esa interfaz sean completados.

  • requisite — El resultado del módulo debe ser exitoso para que la autenticación continúe. Sin embargo, si la prueba falla, el usuario es notificado inmediatamente con un mensaje reflejando el primer módulo requiredorequisite fallido.

  • sufficient — El resultado del módulo es ignorado si falla. Pero si el resultado del módulo con el indicador sufficient es exitoso y ningún módulo con indicador required ha fallado, entonces no se requiere ningún otro resultado y el usuario es autenticado para el servicio.

  • optional — Se ignora el resultado del módulo.Un módulo con una bandera optional sólo es necesario para la autenticación exitosa cuando no hay otros módulos haciendo referencia a la interfaz.

Importante

El orden en el cual se llaman los módulos required no es crítico. Las banderas o indicadores de control sufficient y requisite provocan que el orden se vuelva importante.

Ahora PAM dispone de una nueva sintaxis de control de banderas que permite un control más preciso.

La página man de pam.d y la documentación de PAM, ubicadas en directorio /usr/share/doc/pam-<version-number>/ (donde <version-number> es el número de versión para PAM) describe esta nueva sintaxis detalladamente.

43.4.3.3. Nombre del módulo

El nombre del módulo le proporciona a PAM el nombre del módulo que contiene la interfaz del módulo especificada. Bajo las versiones anteriores de Red Hat Enterprise Linux, se proporcionaba la ruta completa al módulo dentro del archivo de configuración PAM. Sin embargo, desde el advenimiento de sistemas multilib, que almacenan módulos PAM de 64-bits dentro del directorio /lib64/security/, el nombre del directorio es omitido debido a que las aplicaciones son enlazadas a la versión apropiada de libpam, el cual puede ubicar la versión correcta del módulo.

43.4.3.4. Argumentos de módulo

PAM utiliza argumentos para transmitir información a un módulo conectable durante la autenticación para algunos módulos.

Por ejemplo, el módulo pam_userdb.so usa información almacenados en un archivo Berkeley DB para autenticar a los usuarios. La base de datos Berkeley DB es una base de datos de código abierto incorporada en muchas aplicaciones. El módulo toma un argumento db para que la base de datos Berkeley DB conozca qué base de datos usar para el servicio solicitado.

La línea pam_timestamp siguiente es común en la configuración PAM. El <path-to-file> es la ruta completa al archivo de base de datos Berkeley DB:

auth        required        pam_userdb.so db=<path-to-file>

Los argumentos inválidos generalmente son ignorados y no afectan en ningún modo el éxito o fracaso del módulo PAM. Sin embargo, algunos módulos reportarán un error al archivo /var/log/secure.

43.4.4. Muestras de archivos de configuración PAM

A continuación se presenta una muestra de archivo de configuración de la aplicación PAM:

#%PAM-1.0
auth        required  pam_securetty.so
auth        required  pam_unix.so nullok
auth        required  pam_nologin.so
account        required  pam_unix.so
password        required  pam_cracklib.so retry=3
password        required  pam_unix.so shadow nullok use_authtok
session        required  pam_unix.so
  • La primera línea es un comentario como lo es toda línea que inicie con el carácter #.

  • Las líneas dos, tres y cuatro apilan tres módulos a usar para autentificaciones de inicio de sesión.

    auth required pam_securetty.so — Este módulo se asegura de que si el usuario está tratando de conectarse como root, el tty en el cual el usuario se está conectando está listado en el archivo /etc/securetty, si ese archivo existe.

    Si el tty no se lista en el archivo, cualquier intento de iniciar una sesión como root fallará con el mensaje Login incorrect.

    auth required pam_unix.so nullok — Este módulo le solicita al usuario una contraseña y luego verifica la contraseña usando la información almacenada en /etc/passwd y, si existe, en /etc/shadow.

    • El argumento nullok instruye al módulo pam_unix.so a que permita una contraseña en blanco.

  • auth required pam_nologin.so — Este es el paso final de la autenticación. Verifica si el archivo /etc/nologin existe. Si existe y el usuario no es root, la autenticación falla.

    Nota

    En este ejemplo, los tres módulos auth son revisados, aún si el primer módulo auth falla. Esto previene que el usuario sepa en qué nivel la autenticación falla. Tal conocimiento en las manos de una persona mal intencionada le permitiría violar el sistema fácilmente.

  • account required pam_unix.so — Este módulo realiza cualquier verificación de cuenta necesaria. Por ejemplo, si las contraseñas shadow han sido activadas, el componente de la cuenta del módulo pam_unix.so verificará para ver si la cuenta ha expirado o si el usuario no ha cambiado la contraseña dentro del período de gracia otorgado.

  • password required pam_cracklib.so retry=3 — Si la contraseña ha expirado, el componente de la contraseña del módulo pam_cracklib.so le pide una nueva contraseña. Luego evalúa la nueva contraseña para ver si puede ser fácilmente determinada por un programa que descubre las contraseñas basadas en diccionarios.

    • El argumento retry=3 especifica que si la prueba falla la primera vez, el usuario tiene dos opciones más para crear una contraseña mejor.

  • password required pam_unix.so shadow nullok use_authtok — Esta línea especifica que si el programa cambia la contraseña del usuario, debe utilizar la interfaz password del módulo pam_unix.so para hacerlo.

    • El argumento shadow le dice al módulo que cree contraseñas shadow cuando se actualiza la contraseña del usuario.

    • El argumento nullok indica al módulo que permita al usuario cambiar su contraseña desde una contraseña en blanco, de lo contrario una contraseña vacía o en blanco es tratada como un bloqueo de cuenta.

    • El argumento final de esta línea, use_authtok, proporciona un buen ejemplo de la importancia del orden al apilar módulos PAM. Este argumento advierte al módulo a no solicitar al usuario una nueva contraseña. En su lugar se acepta cualquier contraseña que fue registrada por un módulo de contraseña anterior. De este modo, todas las nuevas contraseñas deben pasar el test de pam_cracklib.so para contraseñas seguras antes de ser aceptado.

  • session required pam_unix.so — La última línea especifica que el componente de la sesión del módulo pam_unix.so gestionará la sesión. Este módulo registra el nombre de usuario y el tipo de servicio a /var/log/secure al inicio y al final de cada sesión. Puede ser complementado apilándolo con otros módulos de sesión si necesita más funcionalidad.

43.4.5. Creación de módulos PAM

Puede crear o añadir nuevos módulos PAM en cualquier momento para utilizar con aplicaciones que soporten PAM.

Por ejemplo, un desarrollador puede crear un método de creación de contraseña de una sola vez y escribir un módulo PAM que lo soporte. Los programas que soporten PAM pueden inmediatamente usar el nuevo módulo y el método de contraseña sin tener que compilar de nuevo o realizar alguna otra modificación.

Esto le permite a los desarrolladores y administradores de sistemas mezclar y coincidir, así como también evaluar, métodos de autenticación para programas diferentes sin tener que compilarlos nuevamente.

La documentación acerca de cómo escribir módulos se incluye en el directorio /usr/share/doc/pam-<version-number>/, en donde <version-number> es el número de versión de PAM.

43.4.6. PAM y el caché de credenciales administrativas

Varias herramientas gráficas administrativas bajo Red Hat Enterprise Linux otorgan a los usuarios privilegios especiales por un tiempo máximo de 5 minutos a través del módulo pam_timestamp.so. Es importante entender cómo funciona este mecanismo puesto que un usuario que deja su terminal mientras pam_timestamp.so está en efecto, deja la máquina abierta a la manipulación por cualquiera con acceso físico a la consola.

Bajo el esquema de marcas de tiempo de PAM, la aplicación administrativa gráfica pide al usuario la contraseña de root cuando se ejecuta. Una vez autenticado, el módulo pam_timestamp.so crea un archivo de marca de tiempo (timestamp) dentro del directorio /var/run/sudo/ por defecto. Si el archivo timestamp ya existe, otros programas gráficos administrativos no le pedirán la contraseña. En vez de esto, el módulo pam_timestamp.so refrescará el archivo timestamp, reservando unos cinco minutos extra de acceso administrativo para el usuario.

Puede verificar el estado actual del archivo timestamp inspeccionando el archivo /var/run/sudo/<user>. Para el escritorio, el archivo relevante es unknown:root. Si está presenta y la marca de tiempo es menos de cinco minutos, las credenciales son válidas.

La existencia de archivos timestamp se indica con un icono de autenticación que aparece en el área de notificación del panel.

El icono de autenticación

Ilustración del icono de autenticación.

Figura 43.7. El icono de autenticación

43.4.6.1. Eliminar el archivo timestamp

Es recomendable que antes de dejar desatendida una consola donde está activo un timestamp PAM, se destruya el archivo timestamp. Para hacerlo desde un ambiente gráfico, pulse en el icono de autenticación en el panel. Cuando aparezca una ventana de diálogo, pulse en el botón Olvidar autorización

Diálogo de rechazo de la autenticación

Ilustración del diálogo de rechazo de autenticación.

Figura 43.8. Diálogo de rechazo de la autenticación

Debe tener en cuenta los siguientes siguientes aspectos acerca del archivo timestamp de PAM:

  • Si está conectándose a un sistema remotamente usando ssh, utilice el comando /sbin/pam_timestamp_check -k root para destruir el archivo timestamp.

  • Debe ejecutar el comando /sbin/pam_timestamp_check -k root desde la misma ventana de terminal desde la cual usted ejecutó la acción privilegiada.

  • Debe estar conectado como el usuario que invocó originalmente el módulo pam_timestamp.so para poder utilizar el comando /sbin/pam_timestamp_check -k. No se conecte como usuario root para ejecutar este comando.

  • Si desea eliminar las credenciales en el escritorio (sin utilizar Olvidar autorización en el icono), utilice el siguiente comando:

    /sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
    

    Si el uso de este comando falla, sólo se removerá la credencial (si ésta existe) del pty donde se ejecuta el comando.

Para información sobre cómo destruir el archivo timestamp usando pam_timestamp_check, refiérase a la página man de pam_timestamp_check.

43.4.6.2. Directivas pam_timestamp comunes

El módulo pam_timestamp.so acepta muchas directivas. Abajo están las opciones más comúnmente usadas:

  • timestamp_timeout — Especifica el número de segundos durante los cuales el archivo timestamp es válido. El valor por defecto es 300 segundos (cinco minutos).

  • timestampdir — Especifica el directorio en el cual se almacena el archivo de estampilla de tiempo. El valor por defecto es /var/run/sudo.

Para más información sobre el control del módulo pam_timestamp.so, refiérase a la Sección 43.4.8.1, “Documentación instalada”.

43.4.7. PAM y propiedad del dispositivo

Red Hat Enterprise Linux permite que el primer usuario que se conecte en una consola física de la máquina pueda manipular algunos dispositivos y realizar algunas tareas normalmente reservadas para el usuario root. Esto es controlado por un módulo PAM llamado pam_console.so.

43.4.7.1. Propiedad del dispositivo

Cuando un usuario inicia una sesión en un sistema Red Hat Enterprise Linux, el módulo pam_console.so es llamado por login o los programas de inicio de sesión gráfica, gdm, kdm y xdm. Si este usuario es el primero en conectarse en la consola física — llamado usuario de consola — el módulo le concede al usuario la propiedad de algunos dispositivos que normalmente pertenecen a root. El usuario de la consola posee estos dispositivos hasta que la última sesión local para ese usuario finalice. Una vez que el usuario se ha desconectado, la propiedad de los dispositivos vuelve a root.

Los dispositivos afectados incluyen, pero no son limitados, las tarjetas de sonido, las unidades de disco y las unidades de CD-ROM.

Esto permite que el usuario local manipule estos dispositivos sin llegar a tener acceso root simplificando así las tareas comunes para el usuario de la consola.

Puede modificar la lista de dispositivos controlados por pam_console.so si se editan las siguientes lineas:

  • /etc/security/console.perms

  • /etc/security/console.perms.d/50-default.perms

Usted puede cambiar los permisos de diferentes dispositivos que aquellos listados en los archivos anteriores o sobreescribir las especificaciones predeterminadas. En vez de modificar el archivo 50-default.perms, usted debe crear un nuevo archivo (por ejemplo, xx-name.perms) e introducir la modificación requerida. El número del nuevo archivo predeterminado debe iniciar con un número superior a 50 (por ejemplo 51-default.perms). Esto sobreescribirá los valores predeterminados en el archivo 50-default.perms

Atención

Si el archivo de configuración del gestor de ventanas gdm, kdm o xdm ha sido alterado para permitir a los usuarios remotos conectarse y la máquina está configurada para ejecutarse en el nivel de ejecución 5, se recomienda cambiar las directivas <console> y <xconsole> dentro de /etc/security/console.perms a los valores siguientes:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 
<xconsole>=:0\.[0-9] :0

Ésto previene que los usuarios remotos obtengan acceso a los dispositivos y a las aplicaciones restringidas en la máquina.

Si el archivo de configuración del gestor de ventanas gdm, kdm o xdm ha sido alterado para permitir a los usuarios remotos conectarse y la máquina está configurada para ejecutarse en un nivel diferente al 5, se recomienda cambiar las directivas <xconsole> y <console> a los valores siguientes:

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

43.4.7.2. Acceso de la aplicación

También se le permite al usuario de la consola el acceso a ciertos programas configurados para este fin en /etc/security/console.apps/.

Este directorio contiene archivos de configuración que permiten que el usuario de la consola ejecute ciertas aplicaciones en /sbin y /usr/sbin.

Estos archivos de configuración tienen el mismo nombre que las aplicaciones que configuran.

Un grupo notable de aplicaciones a las que tiene acceso el usuario de la consola son tres programas que cierran o abren el sistema:

  • /sbin/halt

  • /sbin/reboot

  • /sbin/poweroff

Debido a que estas aplicaciones soportan PAM, ellas llaman al módulo pam_console.so como un requerimiento para el uso.

Para mayor información, consulte la Sección 43.4.8.1, “Documentación instalada”.

43.4.8. Recursos adicionales

Los siguientes recursos explican los métodos para el uso y configuración de PAM. Además de estos recursos, lea los archivos de configuración de PAM en el sistema para entender mejor como están estructurados.

43.4.8.1. Documentación instalada

  • Las páginas man relacionadas con PAM — Hay un número de páginas man para las diferentes aplicaciones y archivos de configuración relacionados con PAM. :La lista siguiente muestra algunas de las páginas man más importantes.

    Archivos de configuración
    • pam — Información de introducción sobre PAM. Incluye la estructura y propósitos de los archivos de configuración de PAM.

      Tenga en cuenta que esta página man discute tanto /etc/pam.conf como los archivos de configuración individuales en el directorio /etc/pam.d/. Por defecto, Red Hat Enterprise Linux utiliza los archivos de configuración individuales en el directorio /etc/pam.d/, ignorando /etc/pam.conf incluso si éste existe

    • pam_console — Describe el propósito del módulo pam_console.so. También describe la sintaxis adecuada para una entrada en el archivo de configuración PAM.

    • console.apps — Describe el formato y las opciones disponibles dentro de /etc/security/console.apps, el archivo de configuración que define cuáles aplicaciones permiten acceso al usuario de la consola asignado por PAM.

    • console.perms — Describe el formato y las opciones disponibles dentro de /etc/security/console.perms, el archivo de configuración para los permisos del usuario de la consola asignado por PAM.

    • pam_timestamp — Describe el módulo pam_timestamp.so.

  • /usr/share/doc/pam-<version-number>— Contiene un Manual para administradores de sistemas, un Manual para escritores de módulos y el Manual para los desarrolladores de aplicaciones, así como también una copia del estándar PAM, DCE-RFC 86.0 (reemplace <version-number> con el número de la versión de PAM).

  • /usr/share/doc/pam-<version-number>/txts/README.pam_timestamp — Contiene información sobre el módulo PAM pam_timestamp.so, en donde <version-number> es el número de versión de PAM.

43.4.8.2. Sitios web útiles

  • http://www.kernel.org/pub/linux/libs/pam/ — El sitio web de distribución primario para el proyecto Linux-PAM, conteniendo información sobre varios módulos PAM, una sección FAQ y documentación PAM adicional.

    Nota

    La documentación en el sitio web mencionado anteriormente describe la última versión de PAM y puede que no sea completamente compatible con la versión de PAM incluida en Red Hat Enterprise Linux.

43.5. TCP Wrappers y xinetd

El control del acceso a los servicios de red es una de las tareas de seguridad más importantes que un administrador de servidores debe enfrentar. Red Hat Enterprise Linux, proporciona un gran número de herramientas encargadas de ésta tarea. Por ejemplo, un cortafuegos basado en iptables deja afuera los paquetes de red que no son bienvenidos dentro de la pila de red del kernel. Para los servicios de red que lo utilizan, los TCP wrappers añaden una capa adicional de protección mediante la definición de cuáles hosts tienen permitido conectarse a los servicios de red encapsulados ("wrapped"). Uno de los servicios de red wrapped es el super servicioxinetd. Este servicio se le llama super servicio porque controla la conexión a un subconjunto de servicios de red y refina aún más el control de acceso.

Figura 43.9, “Control de acceso a los servicios de red” es una ilustración básica de cómo estas herramientas funcionan para proteger los servicios de red.

Control de acceso a los servicios de red

Presentación A: Diagrama de flujo del control de acceso a los servicios de red

Figura 43.9. Control de acceso a los servicios de red

43.5.1. Wrappers TCP

El paquete TCP wrappers (tcp_wrappers) está instalado por defecto y proporciona control de acceso basado en host a los servicios de red. El componente más importante dentro del paquete es la biblioteca /usr/lib/libwrap.a. En términos generales, un servicio TCP wrapped es uno que ha sido compilado con la biblioteca libwrap.a.

Cuando un intento de conexión es hecho a un servicio encapsulado con TCP-wrappers, el servicio referencia primero los archivos de acceso a host (/etc/hosts.allow y /etc/hosts.deny) para determinar si el cliente tiene permitido conectarse. En la mayoría de los casos, se utiliza luego el demonio syslog (syslogd) para escribir el nombre del host solicitante y el servicio solicitado a /var/log/secure o /var/log/messages.

Si a un cliente se le permite conectarse, los TCP Wrappers liberan el control de la conexión al servicio solicitado y no interfieren más con la comunicación entre el cliente y el servidor.

Además del control de acceso y registro, los TCP Wrappers pueden activar comandos para interactuar con el cliente antes de negar o liberar el control de la conexión al servicio solicitado.

Puesto que los TCP Wrappers son una utilidad de gran valor dentro de las herramientas de seguridad de cualquier administrador de servidores, la mayoría de los servicios de red dentro de Red Hat Enterprise Linux están enlazados con la biblioteca libwrap.a. Algunas de tales aplicaciones incluyen /usr/sbin/sshd, /usr/sbin/sendmail, y /usr/sbin/xinetd.

Nota

Para determinar si un servicio de red binario está enlazado con la librería libwrap.a, escriba el comando siguiente como usuario root:

ldd <binary-name> | grep libwrap

Reemplace <binary-name> con el nombre del binario de servicio de red.

Si el comando retorna al intérprete de comandos sin ninguna salida, entonces el servicio de red no está enlazado con libwrap.a.

El siguiente ejemplo muestra que /usr/sbin/sshd está enlazado a libwrap.a:

[root@myserver ~]# ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 =
> /usr/lib/libwrap.so.0 (0x00655000)
[root@myserver ~]#

43.5.1.1. Ventajas de los TCP Wrappers

Los TCP Wrappers ofrecen las siguientes ventajas básicas comparado con las otras técnicas de control de servicios de red:

  • Transparencia tanto para el host cliente y el servicio de red encapsulado — Tanto el cliente que está realizando la conexión como el servicio de red encapsulado no están al tanto de que TCP Wrappers está siendo usado. Los usuarios legítimos son registrados y conectados al servicio solicitado mientras que las conexiones de clientes prohibidos fallan.

  • Administración centralizada de múltiples protocolos. — Los TCP Wrappers operan separadamente de los servicios de red que ellos protegen, permitiendo a muchas aplicaciones de servidor compartir un conjunto común de archivos de configuración para una administración más sencilla.

43.5.2. Archivos de configuración de Wrappers TCP

Para determinar si una máquina cliente tiene permitido conectarse a un servicio, los TCP Wrappers consultan los siguientes dos archivos, los cuales se conocen comúnmente como archivos de acceso a host:

  • /etc/hosts.allow

  • /etc/hosts.deny

Cuando un servicio que usa TCP-wrappers recibe una petición de un cliente, se siguen los siguientes pasos:

  1. Referencias a /etc/hosts.allow. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincide, permite la conexión. De lo contrario continúa con el paso siguiente.

  2. Referencia a /etc/hosts.deny. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.deny. Si encuentra una regla que coincide, rechaza la conexión. De lo contrario, el acceso al servicio es coincidido.

Los puntos siguientes se deben considerar cuando se usen TCP-wrappers para proteger servicios de red:

  • Puesto que las reglas de acceso en hosts.allow son aplicadas primero, ellas toman precedencia sobre las reglas en hosts.deny. Por lo tanto, si se permite el acceso a un servicio en hosts.allow, una regla negando el acceso al mismo servicio en hosts.deny es ignorada.

  • Las reglas en cada archivo son leídas de arriba hacia abajo y la primera regla que coincida para un servicio dado es la única aplicada. Por lo tanto el orden de las reglas es extremadamente importante.

  • Si no se encuentra ninguna regla para el servicio en ninguno de los archivos, o si no existe ninguno de los archivos, se concede el acceso al servicio.

  • Los sevicios encapsulados con TCP wrappers no hacen caché de las reglas desde los archivos de acceso de host, por lo tanto cualquier cambio a hosts.allow o a hosts.deny tomarán efecto de inmediato sin tener que reiniciar el servicio de red.

Aviso

Si la última línea de un archivo de acceso a host no es un caracter de nueva línea (creado al presionar la tecla Intro), la última regla en el archivo fallará y se registrará un error bien sea a /var/log/messages o a /var/log/secure. Este es también el caso para reglas que se expanden en múltiples líneas sin usar la barra oblicua. El ejemplo siguiente ilustra la porción relevante del mensaje registrado por una falla de una regla debido a alguna de estas circunstancias:

warning: /etc/hosts.allow, line 20: missing newline or line too long

43.5.2.1. Formatear reglas de acceso

Los formatos para /etc/hosts.allow y /etc/hosts.deny son idénticos. Cualquier línea en blanco o que comience con un símbolo de numeral (#) será ignorada.

Las reglas se tienen que formatear de la siguiente manera:

<daemon list>: <client list> [: <option>: <option>: ...]
  • <daemon list> — Una lista separada por comas de los nombres de procesos (no de los nombres de servicios) o el comodín ALL (consulte Sección 43.5.2.1.4, “Operadores”) para permitir mayor flexibilidad.

  • <client list> — Una lista separada por comas de nombres de host, direcciones IP, patrones especiales o comodines que identifican los hosts afectados por la regla. La lista de clientes también acepta operadores listados en la Sección 43.5.2.1.4, “Operadores” para permitir mayor flexibilidad.

  • <option> — Una acción opcional o una lista separada con puntos y comas de acciones realizadas cuando la regla es activada. Los campos de opciones soportan expansiones, lanzan comandos desde el shell, otorgan o prohiben el acceso y alteran el comportamiento de la conexión.

Nota

En esta guía puede encontrar mayor información sobre los términos especializados arriba mencionados:

A continuación una muestra básica de una regla de acceso:

vsftpd : .example.com

Esta regla instruye a los TCP Wrappers a que estén atentos por conexiones al demonio FTP (vsftpd) desde cualquier host en el dominio example.com. Si esta regla aparece en hosts.allow, la conexión será aceptada. Si esta regla aparece en hosts.deny, la conexión será rechazada.

El próximo ejemplo de regla de acceso es un poco más compleja y utiliza dos campos de opciones:

sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny

Note que cada campo de opción está precedido por una barra oblicua invertida (\). Use la barra para prevenir que falle la regla debido al largo de la misma.

Esta regla de ejemplo indica que si una conexión al demonio SSH (sshd) se intenta desde un host en el dominio example.com, el comando echo es ejecutado para añadir el intento a un archivo de registro especial y la conexión es rechazada. Puesto que se usa la directiva opcional deny, esta línea rechazará el acceso aún si aparece en el archivo hosts.allow. Para más detalles sobre las opciones disponibles, consulte la Sección 43.5.2.2, “Campos de opciones”.

43.5.2.1.1. Comodines

Los comodines permiten a los TCP Wrappers coincidir más fácilmente grupos de demonios o hosts. Son usados con mayor frecuencia en el campo de lista de cliente de las reglas de acceso.

Se pueden utilizar los siguientes comodines:

  • ALL — Hace corresponder todo. Se puede usar tanto para la lista de demonios como para la lista de clientes.

  • LOCAL — Hace corresponder todos los nombres de máquinas que no contengan un punto (.), tal como localhost.

  • KNOWN — Hace corresponder todas las máquinas cuyos nombres y direcciones son conocidos o donde el usuario es conocido.

  • UNKNOWN — Hace corresponder todas las máquinas cuyos nombres y direcciones sean desconocidas o en el caso en el que se desconozca el usuario.

  • PARANOID — Hace corresponder todas las máquinas cuyo nombre no se corresponda con la dirección.

Atención

Los comodines KNOWN, UNKNOWN y PARANOID que usarse con cuidado ya que dependen de servidores DNS en funcionamiento para una correcta operación. Cualquier error en la resolución de nombres puede impedir que usuarios legítimos accedan al servicio.

43.5.2.1.2. Patrones

Los patrones se pueden utilizar en el campo de lista de cliente de las reglas de acceso para especificar de forma más precisa grupos de host clientes.

La siguiente es una lista de los patrones más comúnmente aceptados para una entrada de lista de cliente:

  • Nombre de host comenzando con un punto (.) — Al colocar un punto al comienzo de un nombre de host, se hace coincidir todos los hosts compartiendo los componentes listados del nombre. El ejemplo siguiente aplicaría a cualquier host dentro del dominio example.com:

    ALL : .example.com
    
  • Dirección IP que termina con un punto (.) — Al colocar un punto al final de una dirección IP hace corresponder todos los hosts compartiendo el grupo numérico inicial de una dirección IP. El ejemplo siguiente aplicará a cualquier host dentro de la red 192.168.x.x:

    ALL : 192.168.
    
  • Par dirección IP/máscara — Las expresiones de máscaras de red también pueden ser usadas como un patrón de control de acceso a un grupo particular de direcciones IP. El ejemplo siguiente aplicaría a cualquier host con una dirección de 192.168.0.0 hasta 192.168.1.255:

    ALL : 192.168.0.0/255.255.254.0
    

    Importante

    Cuando se esté trabajando en el espacio de direcciones de IPv4, no se soporta el largo del par dirección/prefijo (prefixlen). Sólo las reglas IPv6 pueden utilizar este formato.

  • Par [Dirección IPv6]/prefixlen — Los pares [net]/prefixlen también pueden ser usadas como un patrón de control de acceso a un grupo particular de direcciones IPv6. El ejemplo siguiente aplicaría a cualquier host con una dirección de 3ffe:505:2:1:: hasta 3ffe:505:2:1:ffff:ffff:ffff:ffff:

    ALL : [3ffe:505:2:1::]/64
    
  • El asterisco (*) — Los asteriscos pueden ser usados para coincidir grupos completos de nombres de host o direcciones IP, siempre y cuando no se mezclen en la lista de cliente conteniendo otros tipos de patrones. El ejemplo siguiente aplicaría a cualquier host dentro del dominio example.com:

    ALL : *.example.com
    
  • La barra oblicua (/) — Si una lista de cliente inicia con una barra, ésta es tratada como un nombre de archivo. Esta característica es útil si se necesitan reglas que especifiquen un gran número de hosts. El ejemplo siguiente se refiere a los TCP Wrappers en el archivo /etc/telnet.hosts para todas las conexiones de Telnet:

    in.telnetd : /etc/telnet.hosts
    

Otros patrones menos usados son también aceptados por los TCP Wrappers. Consulte la página man (5) de hosts_access para obtener mayor información.

Aviso

Preste espacial atención al usar nombres de host y de dominio. Los invasores pueden usar una variedad trucos para burlar las resolución de nombres. Además, cualquier interrupción en el servicio DNS podría impedir el acceso a servicios incluso a la usuarios que tienen el permiso. Lo mejor es utilizar direcciones IP siempre que sea posible.

43.5.2.1.3. Portmap y Wrappers TCP

La implementación Portmap de TCP Wrappers no soporta búsquedas de host, lo cual quiere decir que portmap no puede utilizar hostnames para identificar hosts. Por lo cual, las reglas de control de acceso para portmap en hosts.allow o hosts.deny deben usar direcciones IP, o la palabra clave ALL, para especificar los hosts.

Cambios a las reglas de control de acceso de portmap pueden que no tomen efecto de inmediato. Usted si no se reinicia el servicio portmap.

Los servicios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por lo tanto esté consciente de estas limitaciones.

43.5.2.1.4. Operadores

Actualmente, las reglas de control de acceso aceptan un operador, EXCEPT. Se puede usar tanto en la lista de demonios como en la lista de cliente de una regla.

El operador EXCEPT permite excepciones específicas a coincidencias más amplias dentro de la misma regla.

En el ejemplo siguiente desde un archivo hosts.allow, todos los hosts de example.com pueden conectarse a todos los servicios excepto cracker.example.com:

ALL: .example.com EXCEPT cracker.example.com

En el otro ejemplo desde un archivo hosts.allow, clientes desde la red 192.168.0.x pueden usar todos los servicios excepto para FTP:

ALL EXCEPT vsftpd: 192.168.0.

Nota

Organizacionalmente, a menudo es más fácil evitar el uso de operadores EXCEPT. Esto permite a otros administradores escanear rápidamente los archivos adecuados para ver qué hosts deberían tener o no acceso a los servicios, sin tener que revisar varios operadores EXCEPT.

43.5.2.2. Campos de opciones

Además de las reglas básicas para permitir o prohibir el acceso, la implementación de Red Hat Enterprise Linux de TCP Wrappers soporta extensiones al lenguaje de control de acceso a través de los campos de opciones. Mediante el uso de campos de opciones dentro de las reglas de acceso al host, los administradores pueden llevar a cabo una gran variedad de tareas tales como alterar el comportamiento del registro, consolidar el control de acceso y lanzar comandos del shell.

43.5.2.2.1. Registro

Los campos de opciones le permiten a los administradores cambiar fácilmente la facilidad de registro y el nivel de prioridad para una regla usando la directiva severity.

En el ejemplo siguiente, las conexiones al demonio SSH desde cualquier host en el dominio example.com son registrados a la facilidad por defecto authprivsyslog (debido a que no se especifica un valor de facilidad) con una prioridad de emerg:

sshd : .example.com : severity emerg

Es también posible especificar una facilidad utilizando la opción severity. El ejemplo siguiente registra cualquier intento de conexión SSH por cualquier hosts desde el dominio example.com a la facilidad local0 con una prioridad de alert:

sshd : .example.com : severity local0.alert

Nota

En práctica, este ejemplo no funcionará hasta que el demonio syslog (syslogd) sea configurado para registrar a la facilidad local0. Consulte la página del manual de syslog.conf para información sobre la configuración de las facilidades de registro personalizadas.

43.5.2.2.2. Control de acceso

Los campos de opciones también le permiten a los administradores explícitamente otorgar o prohibir el acceso de máquinas en un sola regla, añadiendo la directiva allow o deny al final de la opción.

Por ejemplo, las dos reglas siguientes permiten conexiones SSH desde client-1.example.com, pero prohiben conexiones desde client-2.example.com:

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

Al permitir el control de acceso por regla, el campo de opciones permite a los administradores consolidar todas las reglas de acceso en un sólo archivo: bien sea hosts.allow o hosts.deny. Algunos consideran que esta es una forma más fácil de organizar reglas de acceso.

43.5.2.2.3. Comandos de la Shell

Los campos de opciones permiten a las reglas de acceso lanzar comandos de la shell a través de las directivas siguientes:

  • spawn — Lanza un comando de la shell como un proceso hijo. Esta directiva de opción puede realizar tareas como el uso de /usr/sbin/safe_finger para obtener más información sobre el cliente solicitante o la creación de archivos de registro especiales usando el comando echo.

    En el ejemplo siguiente, los clientes intentando acceder a servicios de Telnet desde el dominio example.com son registrados discretamente a un archivo especial:

    in.telnetd : .example.com \
            : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \
            : allow
    
  • twist — Reemplaza el servicio solicitado con el comando especificado. Esta directriz se utiliza a menudo para colocar trampas para intrusos (también llamados "potes de miel"). También se puede utilizar para enviar mensajes a los clientes que se estan conectando. La directriz twist debe estar al final de la línea de la regla.

    En el ejemplo siguiente, los clientes que intentan acceder al servicio FTP desde el dominio example.com se les envía un mensaje a través del comando echo:

    vsftpd : .example.com \
            : twist /bin/echo "421 This domain has been black-listed. Access denied!"
    

Para obtener mayor información sobre las opciones de comando de la shell, consulte la página del manual de hosts_options.

43.5.2.2.4. Expansiones

Las expansiones, cuando se utilizan en conjunto con las directrices spawn y twist, proporcionan información sobre el cliente, servidor y los procesos relacionados.

A continuación se presenta una lista de las expansiones soportadas:

  • %a — Suministra la dirección IP del cliente.

  • %A — Suministra la dirección IP del servidor.

  • %c — Proporciona información variada sobre el cliente, como el nombre de usuario y el de la máquina o el nombre del usuario y la dirección IP.

  • %d — Proporciona el nombre del proceso demonio.

  • %h — Suministra el nombre de la máquina del cliente (o la direccción IP, si el nombre de la máquina no está disponible).

  • %H — Suministra el nombre de la máquina del servidor (o la dirección IP si el nombre de la máquina no está disponible).

  • %n — Proporciona el nombre de la máquina del cliente. Si no está disponible aparecerá unknown. Si el nombre de la máquina y la dirección de la máquina no corresponden, aparecerá paranoid.

  • %N — Proporciona el nombre de la máquina del servidor. Si no está disponible aparecerá unknown. Si el nombre de la máquina y su dirección no coinciden, aparecerá paranoid.

  • %p — Suministra el ID del proceso demonio.

  • %s — Suministra información varia del servidor como el proceso demonio y la máquina o la dirección IP del servidor.

  • %u — Proporciona el nombre de usuario del cliente. Si no está disponible aparecerá unknown.

El ejemplo siguiente usa una expansión en conjunto con el comando spawn para identificar el host cliente en un archivo de registro personalizado.

Cuando se intentan conexiones al demonio SSH (sshd) desde un host en el dominio example.com, ejecute el comando echo para registrar el intento, incluyendo el nombre del host cliente (usando la expansión %h), a un archivo especial:

sshd : .example.com  \
        : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
        : deny

De forma similar, las expansiones se pueden utilizar para personalizar mensajes de vuelta al cliente. En el ejemplo siguiente, los clientes que intentan acceder al servicio FTP desde el dominio example.com son informados que se les ha prohibido acceder al servidor:

vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"

Para una explicación completa de las expansiones disponibles, así como también opciones de control de acceso adicionales, revise la sección 5 de la página man para hosts_access (man 5 hosts_access) y la página man de hosts_options.

Consulte Sección 43.5.5, “Recursos adicionales” para obtener mayor información sobre TCP Wrappers.

43.5.3. xinetd

El demonio xinetd es un super servicio que utiliza TCP-wrappers. Éste controla el acceso a un subconjunto de servicios de red populares incluyendo FTP, IMAP y Telnet. También proporciona opciones de configuración específicas al servicio para el control de acceso, registro mejorado, redireccionamiento y control de utilización de recursos.

Cuando un cliente intenta conectarse a un servicio de red controlado por xinetd, el super servicio recibe la petición y revisa las reglas de control de acceso de TCP Wrappers.

Si el acceso es permitido, xinetd verifica que la conexión este permitida bajo sus propias reglas de acceso para ese servicio. Asimismo verifica que el servicio no tiene más recursos asignados a él y que éste cumpla las reglas definidas.

Si todas estas condiciones son cumplidas (se permite al acceso al servicio; el servicio no ha llegado a su límite de recursos; y el servicio no viola ninguna regla), xinetd inicia una instancia del servicio solicitado y pasa el control de la conexión a éste. Una vez la conexión se ha establecido, xinetd no toma parte en la comunicación entre el servidos y el cliente.

43.5.4. Archivos de configuración de xinetd

Los archivos de configuración para xinetd son los siguientes:

  • /etc/xinetd.conf — El archivo de configuración global de xinetd.

  • /etc/xinetd.d/ — El directorio que contiene todos los archivos específicos al servicio.

43.5.4.1. El archivo /etc/xinetd.conf

El archivo /etc/xinetd.conf contiene parámetros de configuración generales los cuales afectan cada servicio bajo el control de xinetd. Se lee una vez cuando el servicio xinetd es iniciado, por esto, para que los cambios de la configuración tomen efecto, el administrador debe reiniciar el servicio xinetd. Abajo se muestra un ejemplo del archivo /etc/xinetd.conf:

defaults
{
         instances               = 60        
         log_type                = SYSLOG        authpriv
         log_on_success          = HOST PID
         log_on_failure          = HOST
         cps                     = 25 30
}
includedir /etc/xinetd.d

Estas líneas controlan los siguientes aspectos de xinetd:

  • instances — Configura el máximo número de peticiones que xinetd puede manejar simultáneamente.

  • log_type — Configura xinetd para usar la facilidad de registro authpriv, el cual escribe las entradas de registro al archivo /var/log/secure. Al agregar una directiva tal como FILE /var/log/xinetdlog aquí, creará un archivo de registro personalizado llamado xinetdlog en el directorio /var/log/.

  • log_on_success — Configura xinetd a registrar si la conexión es exitosa. Por defecto, la dirección IP del host remoto y el ID del proceso del servidor procesando la petición son grabados.

  • log_on_failure — Configura xinetd para registrar si hay una falla de conexión o si la conexión no es permitida.

  • cps — Configura xinetd para no permitir más de 25 conexiones por segundo a cualquier servicio dado. Si se alcanza este límite, el servicio es retirado por 30 segundos.

  • includedir/etc/xinetd.d/ — Incluye las opciones declaradas en los archivos de configuración específicos del servicio localizados en el directorio /etc/xinetd.d/. Consulte la Sección 43.5.4.2, “El directorio /etc/xinetd.conf” para más información sobre este directorio.

Nota

A menudo, las configuraciones log_on_success y log_on_failure en /etc/xinetd.conf son modificadas aún más en los archivos de registro específicos al servicio. Por esta razón, puede que aparezca más información en el registro de un servicio dado que lo que puede indicar el archivo/etc/xinetd.conf. Consulte la Sección 43.5.4.3.1, “Opciones de registro” para más información.

43.5.4.2. El directorio /etc/xinetd.conf

El directorio /etc/xinetd.d/ contiene los archivos de configuración para cada servicio manejado por xinetd y los nombres de los archivos que se correlacionan con el servicio. Como sucede con xinetd.conf, este archivo sólo es leído cuando el servicio xinetd es arrancado. Para que los cambios tengan efecto, el administrador debe reiniciar el servicio xinetd.

El formato de los archivos en el directorio /etc/xinetd.d/ usan las mismas convenciones que /etc/xinetd.conf. La razón principal por la que la configuración para cada servicio es almacenada en un archivo separado es hacer más fácil la personalización y que sea menos probable afectar otros servicios.

Para tener una idea de cómo estos archivos están estructurados, considere el archivo /etc/xinetd.d/krb5-telnet:

service telnet
{
         flags           = REUSE
         socket_type     = stream
         wait            = no
         user            = root
         server          = /usr/kerberos/sbin/telnetd
         log_on_failure  += USERID
         disable         = yes
}

Estas líneas controlan varios aspectos del servicio telnet:

  • service — Define el nombre del servicio, usualmente uno listado en el archivo /etc/services.

  • flags — Configura cualquier número de atributos para la conexión. REUSE instruye xinetd a reutilizar el socket para una conexión Telnet.

    Nota

    La opción REUSE está fuera de uso. Todos los servicios utilizan implicitamente la opción REUSE.

  • socket_type — Configura el socket de red a escribir a stream.

  • wait — Define si el servicio es de un sólo hilo (yes) o de múltiples hilos (no).

  • user — Define bajo qué ID de usuario se ejecutará el proceso.

  • server — Define el binario ejecutable a lanzar.

  • log_on_failure — Define los parámetros de registro para log_on_failure además de aquellos ya definidos en xinetd.conf.

  • disable — Especifica si el servicio está desactivado (yes) o activado (no).

Consulte la página man de xinetd.conf para obtener mayor información sobre estas opciones y su uso.

43.5.4.3. Modificando los archivos de configuración de xinetd

Existe una gran cantidad de directivas disponibles para los servicios protegidos por xinetd. Esta sección resalta algunas de las opciones usadas más comúnmente.

43.5.4.3.1. Opciones de registro

Las siguientes opciones de registro están disponibles para /etc/xinetd.conf y los archivos de configuración específicos al servicio en el directorio /etc/xinetd.d/.

A continuación se presenta una lista de las opciones de registro usadas más comúnmente:

  • ATTEMPT — Indica que se intentó realizar una conexión pero que ésta falló (log_on_failure).

  • DURATION — Indica el tiempo que un sistema remoto usa un servicio (log_on_success).

  • EXIT — Indica el estado de salida o la señal de término del servicio (log_on_success).

  • HOST — Indica la dirección IP de la máquina remota (log_on_failure y log_on_success).

  • PID — Indica el ID del proceso del servidor que recibe la petición (log_on_success).

  • USERID — Registra el usuario remoto que está usando el método definido en RFC 1413 para todos los servicios de multi procesos (log_on_failure y log_on_success).

Para obtener una lista completa de las opciones de registro, consulte la página de manual de xinetd.conf.

43.5.4.3.2. Opciones de control de acceso

Los usuarios de servicios xinetd pueden seleccionar usar reglas de acceso TCP Wrappers a hosts, proporcionar control de acceso a través de los archivos de configuración xinetd, o una mezcla de ambos. La información concerniente al uso de los archivos de control de acceso TCP Wrappers a hosts se puede encontrar en la Sección 43.5.2, “Archivos de configuración de Wrappers TCP”.

Esta sección discute el uso de xinetd para controlar el acceso a servicios.

Nota

A diferencia de los TCP Wrappers, los cambios al control de acceso sólo tengan efecto si el administrador de xinetd reinicia el servicio xinetd.

A diferencia de los TCP Wrappers, el control de acceso a través de xinetd sólo afecta a los servicios controlados por xinetd mismo.

El control de acceso de xinetd es diferente del método usado por los TCP Wrappers. Mientras que los TCP Wrappers colocan toda la configuración del acceso dentro de dos archivos, /etc/hosts.allow y /etc/hosts.deny, el control de acceso de xinetd se encuentra en el archivo de configuración de cada servicio dentro del directorio /etc/xinetd.d.

Las opciones de acceso a host siguientes son soportadas por xinetd:

  • only_from — Sólo permite que las máquinas específicas usen el servicio.

  • no_access — Impide que estas máquinas usen el servicio.

  • access_times — Especifica el intervalo de tiempo en el que un determinado servicio puede ser usado. El rango de tiempo debe especificarse en formato de 24 horas, HH:MM-HH:MM.

Las opciones only_from y no_access pueden usar una lista de direcciones IP o nombres de hosts, o pueden especificar una red completa. Como los TCP Wrappers, combinando el control del acceso xinetd con una configuración de conexión apropiada puede mejorar la seguridad mediante el bloqueo de peticiones de hosts vetados mientras que graba cada intento de conexión.

Por ejemplo, el siguiente archivo /etc/xinetd.d/telnet puede ser usado para bloquear el acceso a Telnet desde un un grupo de red particular y restringir el rango de tiempo general que inclusive los usuarios permitidos pueden conectarse:

service telnet
{
         disable         = no
         flags           = REUSE
         socket_type     = stream
         wait            = no
         user            = root
         server          = /usr/kerberos/sbin/telnetd
         log_on_failure  += USERID
         no_access       = 172.16.45.0/24
         log_on_success  += PID HOST EXIT
         access_times    = 09:45-16:15
}

En este ejemplo, cuando un sistema cliente desde la red 10.0.1.0/24, tal como 10.0.1.2, intenta acceder el servicio Telnet, recibirá un mensaje indicando lo siguiente:

Connection closed by foreign host.

Además, sus intentos de conexión son registrados en /var/log/messages como sigue:

Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)

Cuando esté usando TCP Wrappers en conjunto con controles de acceso xinetd, es importante entender la relación entre los dos mecanismos de control de acceso.

A continuación se muestra el orden de las operaciones seguido por xinetd cuando un cliente solicita una conexión:

  1. El demonio xinetd accede a las reglas de acceso a hosts TCP Wrappers a través de una llamada a la librería libwrap.a. Si alguna regla de rechazo coincide con el host cliente, la conexión se rechaza. Si una regla de aceptación coincide con el host cliente, la conexión pasa a xinetd.

  2. El demonio xinetd verifica sus propias reglas de acceso para el servicio xinetd y el servicio solicitado. Si una regla de rechazo coincide con el host cliente la conexión es rechazada. De lo contrario, xinetd inicia una instancia del servicio solicitado y pasa el control de la conexión al mismo.

Importante

Se debe tener especial cuidado cuando se use el control de acceso wrappers TCP en conjunto con los controles xinetd. Un error en la configuración puede generar resultados no deseados.

43.5.4.3.3. Vincular y redirigir opciones

Los ficheros de configuración de servicios para el comando xinetd también soportan la vinculación del servicio a una dirección IP y el desvío de las peticiones entrantes para dicho servicio a otra dirección IP, nombre de la máquina o puerto.

La vinculación es controlada con la opción bind que se encuentra en el archivo de configuración específico del servicio, y une específicamente el servicio a una dirección IP del sistema. Una vez configurada, la opción bind sólo permite peticiones para la dirección IP apropiada para acceder al servicio. De esta forma se pueden vincular servicios diferentes a interfaces de red diferentes según sea necesario.

Esto es útil sobre todo para los sistemas con múltiples adaptadores de red o con múltiples direcciones IP. En tales sistemas, los servicios inseguros como Telnet, se pueden configurar de modo que solo escuche a la interfaz conectada a una red privada, y no a la interfaz conectada a Internet.

La opción redirect acepta la dirección IP o el nombre de la máquina seguido del número de puerto. Dice al servicio que desvíe todas las peticiones para dicho servicio a una localización y número de puerto específicos. Esta característica se usa para establecer otro número de puerto en el mismo sistema, desviar la petición a otra dirección IP en la misma máquina, cambiar la petición a otro sistema y puerto completamente diferentes o con la combinación de cualquiera de estas opciones. De esta manera, un usuario que está conectado a un determinado servicio en un sistema puede ser redirigido a otro sistema sin ninguna interrupción.

El demonio xinetd lleva a cabo este desvío lanzando un proceso que mantenga la conexión entre la máquina cliente que está mandando la petición y la máquina que está dando en ese momento el servicio, transfiriendo los datos de un sistema a otro.

El mayor beneficio de estas dos opciones (bind y redirect) se obtiene cuando se usan juntas. Vinculando un servicio a una dirección IP determinada en un sistema y luego desviando las peticiones de dicho servicio a una segunda máquina que sólo puede ver la primera máquina, se puede usar un sistema interno que ofrezca servicios para una red completamente diferente. Alternativamente, estas opciones se pueden usar para limitar la exposición de un servicio determinado a una dirección IP conocida, así como desviar todas las peticiones a ese servicio a otra máquina configurada específicamente para ese objetivo.

Por ejemplo, considere un sistema que se usa como firewall con la característica siguiente para su servicio Telnet:

service telnet
{
         socket_type                = stream
         wait                        = no
         server                        = /usr/kerberos/sbin/telnetd
         log_on_success                += DURATION USERID
         log_on_failure                += USERID
         bind                    = 123.123.123.123
         redirect                = 10.0.1.13 23
}

Las opciones bind y redirect en este archivo aseguran que el servicio Telnet en la máquina esté enlazado con la dirección IP externa (123.123.123.123), la que se encarga de Internet. Además, todas las peticiones del servicio Telnet enviadas a 123.123.123.123 son redirigidas a través de una segunda tarjeta de red a una dirección IP interna (10.0.1.13) a la que solo tienen acceso el firewall y los sistemas internos. El firewall manda luego la comunicación entre los dos sistemas y el sistema que se está conectando piensa que está conectado a 123.123.123.123 mientras que, de hecho, está conectado a otra máquina.

Esta característica es útil para los usuarios con conexiones de banda ancha y con una única dirección IP fija. Cuando se usa la NAT (de las siglas en inglés de Network Address Translation ), los sistemas detrás de la máquina gateway, que están usando direcciones IP internas, no están disponibles desde afuera del sistema gateway. Sin embargo, cuando determinados servicios controlados por xinetd son configurados con las opciones bind y redirect, la máquina gateway puede funcionar como un proxy entre los sistemas externos y una máquina interna particular configurada para proporcionar el servicio. Además, las opciones de control de acceso xinetd y de conexión están también disponibles para protección adicional.

43.5.4.3.4. Opciones de administración de recursos

El demonio xinetd puede añadir un nivel básico de protección de un ataque Denial of Service (DoS). Abajo se encuentra una lista de las directivas que pueden ayudar en limitar la efectividad de tales ataques:

  • per_source — Define el número máximo de instancias para un servicio por dirección IP. Acepta sólo enteros como argumentos y puede ser usado en xinetd.conf y los archivos de configuración específicos al servicio xinetd.d/.

  • cps — Define el máximo número de conexiones por segundo. Esta directiva toma dos argumentos enteros separados por un espacio en blanco. El primero es el número máximo de conexiones permitidas por segundo. El segundo es el número de segundos que xinetd debe esperar antes de reactivar el servicio. Sólo acepta enteros como argumentos y puede ser usado en ambos xinetd.conf y los archivos de configuración específicos al servicio en el directorio xinetd.d/.

  • max_load — Indica el umbral de uso del CPU para un servicio. Acepta un argumento en forma de número de punto flotante.

    El promedio de carga es una medición aproximada del número de procesos que están activos en un tiempo dado. Vea los comandos uptime, who, procinfo para obtener mayor información sobre el promedio de carga.

Hay más opciones de administración de recursos disponibles para xinetd. Consulte la página del manual de xinetd.conf.

43.5.5. Recursos adicionales

En la documentación del sistema y en el web puede encontrar información adicional concerniente a los TCP Wrappers y a xinetd.

43.5.5.1. Documentación instalada

La documentación en su sistema es un buen lugar para comenzar a buscar información sobre los Wrappers TCP, xinetd y las opciones de control de acceso.

  • /usr/share/doc/tcp_wrappers-<version>/ — Contiene un archivo README que discute cómo los TCP Wrappers funcionan y los diferentes riesgos de spoofing de host y de direcciones IP que existen.

  • /usr/share/doc/xinetd-<version>/ — Incluye un archivo README que discute aspectos del control de acceso y un archivo sample.conf con varias ideas para la modificación de archivos de configuración específicos al servicio en el directorio /etc/xinetd.d/.

  • Las páginas man relacionadas a TCP wrappers y xinetd — Hay un buen número de páginas man para las varias aplicaciones y archivos de configuración relacionados con TCP wrappers y xinetd. La siguiente es una lista con las páginas man más importantes.

    Aplicaciones de servidor
    • man xinetd — La página del manual para xinetd.

    Archivos de configuración
    • man 5 hosts_access — La página del manual para los archivos de control de acceso TCP Wrappers.

    • man hosts_options — La página del manual para los campos de opciones de TCP Wrappers.

    • man xinetd.conf — La página del manual listando las opciones de configuración xinetd.

43.5.5.2. Sitios Web de utilidad

  • http://www.xinetd.org/ — El sitio principal de xinetd, contiene archivos de configuración de ejemplo, una lista completa de las características y una sección de Preguntas más frecuentes FAQ.

  • http://www.macsecurity.org/resources/xinetd/tutorial.shtml — Un tutorial completo que discute las diferentes formas de ajustar los archivos de configuración xinetd por defecto para cubrir objetivos específicos.

43.5.5.3. Libros relacionados

  • Hacking Linux Exposed por Brian Hatch, James Lee y George Kurtz; Osbourne/McGraw-Hill — Un recurso excelente de seguridad con información sobre TCP Wrappers y xinetd.

43.6. Redes privadas virtuales (VPNs)

Las organizaciones con varias oficinas satelitales se conectan a menudo con líneas dedicadas para proteger los datos confidenciales en tránsito. Por ejemplo, muchos negocios utilizan frame relay o líneas ATM (Asynchronous Transfer Mode), como una solución de redes para enlazar una oficina con las otras. Esto puede ser una propuesta costosa, especialmente para negocios pequeños o medianos (SMB) que desean extenderse sin tener que pagar los altos costos asociados a circuitos digitales dedicados de nivel corporativo.

Para resolver este problema, se desarrollaron las Redes privadas virtuales (VPN). Siguiendo los mismos principios funcionales de los circuitos dedicados, las VPN permiten una comunicación digital segura entre dos partes (o redes), creando una red de área amplia (WAN) a partir las Redes de área local (LAN) existentes. La diferencia con respecto a frame relay o ATM está en el medio de transporte. Las VPN transmiten sobre IP usando datagramas como capa de transporte, haciendo un conducto seguro a través de la Internet hasta la dirección de destino. La mayoría de las implementaciones de software libre de VPN incorporan estándares abiertos y encriptación para enmascarar aún más el tránsito de datos.

Algunas organizaciones emplean soluciones de hardware VPN para aumentar la seguridad, mientras que otras utilizan las implementaciones basadas en software o protocolos. Hay muchos fabricantes con soluciones de hardware VPN tales como Cisco, Nortel, IBM y Checkpoint. Hay una solución libre de VPN basada en software para Linux llamada FreeS/Wan que utiliza una implementación estandarizada de IPSec (o Protocolo de Seguridad de Internet). Estas soluciones VPN, sin importar si están basadas en hardware o software, actúan como enrutadores especializados que se colocan entre la conexión IP desde una oficina a la otra.

43.6.1. ¿Cómo funciona un VPN?

Cuando un paquete es transmitido desde un cliente, éste se envía a través de un router o gateway VPN, el cual añade el Encabezado de autenticación (AH) para enrutamientos y autenticación. Los datos son luego encriptados y, finalmente, cerrados con una Carga de seguridad de encapsulación (ESP). Esta última constituye las instrucciones de control y desencriptación.

El enrutador VPN receptor extrae la información, desencripta los datos y la enruta a su destino (bien sea una estación de trabajo o un nodo en la red). Usando una conexión de red-a-red, el nodo receptor en la red local recibe los paquetes descifrados y listos para ser procesados. El proceso de encriptación/descifrado en una conexión VPN de red-a-red es transparente al nodo local.

Con tal nivel de seguridad, un cracker debe no sólo interceptar un paquete, sino además descifrarlo. Los intrusos que empleen el tipo de ataque "Hombre en el medio" entre un servidor y el cliente deben también tener acceso al menos a una de las llaves privadas para la autenticación de sesiones. Puesto que solamente emplean varias capas de autenticación y encriptación, las VPN son una forma efectiva y segura de conectar nodos remotos múltiples para actuar como una única Intranet.

43.6.2. VPNs y Red Hat Enterprise Linux

Red Hat Enterprise Linux proporciona varias opciones para implementar una solución de software para conectarse de forma segura a sus WAN. El Internet Protocol Security o IPsec es la implementación VPN soportada por Red Hat Enterprise Linux que resuelve de forma completa las necesidades de utilización de las organizaciones con sucursales o con usuarios remotos.

43.6.3. IPsec

Red Hat Enterprise Linux es compatible con IPsec para la conexión entre hosts y redes remotos utilizando un túnel seguro en un transportador de red común tal como la Internet. IPsec se puede implementar usando una conexión host-a-host (una computadora a la otra) o de red-a-red (una LAN/WAN a la otra).

La implementación IPsec en Red Hat Enterprise Linux utiliza el Intercambio de llaves en Internet (IKE), el cual es un protocolo implementado por el Internet Engineering Task Force (IETF), a ser usado para la autenticación mutua y asociaciones seguras entre sistemas conectándose.

43.6.4. Creando una conexión IPsec

Una conexión IPsec se divide en dos fases lógicas. En la fase 1, un nodo IPsec inicializa la conexión con el nodo o red remota. El nodo/red remota verifica las credenciales del nodo solicitante y ambos lados negocian el método de autenticación para la conexión.

En sistemas Red Hat Enterprise Linux, una conexión IPsec utiliza el método de llave pre-compartida de autenticación de nodo IPsec. En una conexión IPsec de llaves precompartidas, ambos hosts deben utilizar la misma llave para pasar a la fase dos de la conexión IPsec.

Es en la fase 2 de la conexión IPsec donde se crea una asociación de seguridad (SA) entre nodos IPsec. Esta fase establece una base de datos SA con información de configuración, tal como el método de encriptación, parámetros de intercambio de llaves secretas y más. Esta fase maneja realmente la conexión IPsec entre nodos remotos y redes.

La implementación de Red Hat Enterprise Linux de IPsec utiliza IKE para compartir las llaves entre hosts a través de la Internet. El demonio de manejo de llaves racoon se encarga de la distribución e intercambio de llaves IKE. Consulte las páginas man de racoon para obtener mayor información sobre este demonio.

43.6.5. Instalación de IPsec

La implementación de IPsec requiere que esté instalado el paquete RPM ipsec-tools en todos los hosts IPsec (si se está utilizando una configuración de host-a-host) o enrutadores (si se está usando una configuración de red-a-red). El paquete RPM contiene las bibliotecas esenciales, los demonios y los archivos de configuración para ayudar en la configuración de una conexión IPsec, incluyendo:

  • /sbin/setkey — manipula la administración de llaves y los atributos de seguridad de IPsec en el kernel. Este ejecutable es controlado por el demonio de manejo de llaves racoon. Para más información sobre setkey, consulte la página man setkey(8).

  • /sbin/racoon — El demonio de administrador de llave IKE, utilizado para administrar y controlar asociaciones de seguridad y llaves compartidas entre sistemas conectados a través de IPsec.

  • /etc/racoon/racoon.conf — El archivo de configuración del demonio racoon utilizado para configurar los diferentes aspectos de la conexión IPsec, incluyendo los métodos de autenticación y algoritmos de encriptación usados en la conexión. Para ver un listado completo de las directivas disponibles, consulte la página man de racoon.conf(5).

Para configurar IPsec en Red Hat Enterprise Linux, usted puede utilizar la Herramienta de administración de red o editar manualmente los archivos de configuración de red y IPsec.

43.6.6. Configuración IPsec de host-a-host

IPsec se puede configurar para conectar un escritorio o estación de trabajo a otro a través de una conexión host-a-host. Este tipo de conexión utiliza la red a la cual están conectados los hosts para crear un túnel seguro entre ellos. Los requerimientos de una conexión host-a-host son mínimos, como lo es la configuración de IPsec en cada host. Los hosts solamente necesitan una conexión dedicada al transportador de red (tal como la Internet) y Red Hat Enterprise Linux para crear la conexión IPsec.

43.6.6.1. Configuración host-a-host

Una conexión IPsec host-a-host en una conexión encriptada entre dos sistemas que ejecutan IPsec con la misma llave de autenticación. Con la conexión IPsec activa, todo el tráfico de red entre los dos hosts es encriptada.

Para configurar una conexión IPsec, utilice los siguientes pasos para cada host:

Nota

Debe ejecutar los siguientes pasos en la máquina que esta configurando. Evite configurar y establecer conexiones IPsec remotamente.

  1. En un intérprete de comandos escriba system-config-network para iniciar la Herramienta de administración de redes.

  2. En la pestaña IPsec, haga clic en Nuevo para iniciar el ayudante de configuración.

  3. Haga clic en Adelante para iniciar la configuración de una conexión IPsec de host-a-host:

  4. Introduzca un nombre único para la conexión, por ejemplo, ipsec0. Si se requiere, seleccione la casilla de verificación para automáticamente activar la conexión cuando el computador inicie. Haga clic en Adelante para continuar.

  5. Seleccione Encriptación de host a host como tipo de conexión y haga clic en Adelante.

  6. Seleccione el tipo de encriptación a usar: manual o automática.

    Si selecciona encriptación manual, una llave de encriptación debe ser proporcionada posteriormente. Si selecciona encriptación automática, el demonio racoon administra la llave de encriptación. El paquete ipsec-tools debe ser instalado si desea utilizar encriptación automática.

    Haga clic en Adelante para continuar.

  7. Introduzca la dirección IP del host remoto.

    Para determinar la dirección IP del host remoto, utilice el siguiente comando en el host remoto:

    [root@myServer ~] # /sbin/ifconfig <device>
    

    en donde <device> es el dispositivo Ethernet que desea utilizar para la conexión VPN.

    Si sólo una tarjeta Ethernet existe en su sistema, el nombre de dispositivo es generalmente eth0. El siguiente ejemplo muestra la información relevante de este comando (tenga en cuenta que es un ejemplo de la salida únicamente):

    eth0      Link encap:Ethernet  HWaddr 00:0C:6E:E8:98:1D
              inet addr:172.16.44.192  Bcast:172.16.45.255  Mask:255.255.254.0
    

    La dirección IP es el número que va después de inet addr:

    Nota

    Para las conexiones host-a-host, ambos host deben tener una dirección pública y enrutable. Alternativamente, ambos hosts pueden tener una dirección privada no enrutable (por ejemplo, de los rangos 10.x.x.x o 192.168.x.x) si ambos están en la misma LAN.

    Si los hosts están en diferentes LANs, o un host tiene una dirección pública y el otro una privada, consulte la Sección 43.6.7, “Configuración de IPsec de red-a-red”.

    Haga clic en Adelante para continuar.

  8. Si la encriptación manual fue seleccionada en el paso 6, especifique la llave de encriptación a usar o haga clic en Generar para crear una llave.

    1. Especifique una llave de autenticación o haga clic en Generar para generar una llave. Puede ser cualquier combinación de números y letras.

    2. Haga clic en Adelante para continuar.

  9. Verifique la información en la página IPsec — Resumen y haga clic en Aplicar.

  10. Haga clic en Archivo => Guardar para guardar la configuración.

    Podría tener que reiniciar la red para que los cambios surtan efecto. Para reiniciar la red utilice el siguiente comando:

    [root@myServer ~]# service network restart
    
  11. Seleccione la conexión IPsec desde la lista y haga clic en Activar.

  12. Repita todo el procedimiento para el otro host. Es importante que se utilice la misma llave del paso 8 en los otros hosts. De lo contrario IPsec no funcionará.

Después de configurar la conexión IPsec, aparecerá en la lista IPsec tal y como se muestra en la Figura 43.10, “Conexión IPsec”.

Conexión IPsec

Conexión IPsec

Figura 43.10. Conexión IPsec

Los siguientes archivos son creados cuando la conexión IPsec es configurada:

  • /etc/sysconfig/network-scripts/ifcfg-<nickname>

  • /etc/sysconfig/network-scripts/keys-<nickname>

  • /etc/racoon/<remote-ip>.conf

  • /etc/racoon/psk.txt

Si se selecciona la encriptación automática, el archivo /etc/racoon/racoon.conf es también creado.

Cuando la interfaz está activa, /etc/racoon/racoon.conf se modifica para incluir <remote-ip>.conf.

43.6.6.2. Configuración manual de IPsec de host-a-host

El primer paso en la creación de una conexión es reunir la información del sistema y de la red de cada estación de trabajo. Para una conexión host-a-host, necesita la información siguiente:

  • La dirección IP para ambos hosts

  • Un nombre único, por ejemplo, ipsec1. Éste es utilizado para identificar la conexión IPsec y para distinguirla de otros dispositivos y conexiones.

  • Una llave encriptada fija o una generada automáticamente por racoon

  • Una llave de autenticación pre-compartida que se utiliza para iniciar la conexión e intercambiar las llaves de encriptación durante la sesión

Por ejemplo, suponga que la Estación A y la Estación B desean conectarse a través de un túnel IPsec. Ellas desean conectarse usando una llave pre-compartida con el valor de Key_Value01 y los usuarios acuerdan dejar que racoon automáticamente genere y comparta una llave de autenticación entre cada host. Ambos usuarios de los hosts deciden nombrar sus conexiones como ipsec1.

Nota

Usted debería escoger un PSK que utilice mayúsculas y minúsculas, números y caracteres de puntuación. Un PSK que sea fácil de adivinar constituye un riesgo de seguridad.

No es necesario utilizar el mismo nombre de conexión para cada host. Debería escoger un nombre que es significativo y conveniente para su instalación.

El siguiente es el archivo de configuración IPsec para una conexión IPsec de host-a-host para la Estación A con la Estación B. El nombre único para identificar la conexión en este ejemplo es ipsec1, por lo cual el archivo resultante es llamado /etc/sysconfig/network-scripts/ifcfg-ipsec1

DST=X.X.X.X
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK

Para la Estación A, X.X.X.X es la dirección IP de la Estación B. Para la Estación B, X.X.X.X es la dirección IP de la Estación A. Esta conexión no está configurada para iniciarse durante el inicio del sistema (ONBOOT=no) y utiliza el método de autenticación de llave pre-compartida (IKE_METHOD=PSK).

El siguiente es el contenido del archivo de llave pre-compartida (llamado /etc/sysconfig/network-scripts/keys-ipsec1) que ambas estaciones de trabajo necesitan para autenticarse mutuamente. Los contenidos de este archivo deberían ser idénticos en ambas estaciones de trabajo y solamente el usuario root debería ser capaz de leer o escribir en el mismo.

IKE_PSK=Key_Value01

Importante

Para cambiar el archivo keys-ipsec1 para que solamente el usuario root pueda leerlo o modificarlo, ejecute el comando siguiente después de crear el archivo:

[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para cambiar la llave de autenticación en cualquier momento, modifique el archivo keys-ipsec1 en ambas estaciones de trabajo. Ambas llaves deben ser idénticas para una conectividad apropiada.

El siguiente ejemplo muestra la configuración específica para la fase 1 de la conexión al host remoto. El archivo es llamado X.X.X.X.conf (reemplace X.X.X.X con la dirección IP del enrutador IPsec remoto). Observe que este archivo es generado automáticamente una vez que el túnel IPsec es activado y no se debería modificar directamente.

remote X.X.X.X
{
         exchange_mode aggressive, main;
         my_identifier address;
         proposal {
                 encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

El archivo de configuración predeterminado para la fase 1 creado cuando se inicializa una conexión IPsec contiene las siguientes declaraciones utilizadas por la implementación Red Hat Enterprise Linux de IPsec:

remote X.X.X.X

Especifica que las estrofas subsecuentes de este archivo de configuración sólo se aplican al nodo remoto identificado por la dirección IP X.X.X.X

exchange_mode aggressive

La configuración predeterminada para IPsec en Red Hat Enterprise Linux utiliza un método de autenticación agresivo, que reduce la sobrecarga de la conexión a la vez que permite la configuración de muchas conexiones IPsec con múltiples hosts.

my_identifier address

Define el método de autenticación a utilizar cuando se autentifican nodos. Red Hat Enterprise Linux utiliza direcciones IP para identificar a los nodos.

encryption_algorithm 3des

Define el cifrado de encriptación utilizado durante la autenticación. Por defecto, se utiliza Triple Data Encryption Standard (3DES).

hash_algorithm sha1;

Especifica el algoritmo hash utilizado durante la negociación de la fase 1 entre nodos. Por defecto, se utiliza el Secure Hash Algorithm versión 1.

authentication_method pre_shared_key

Define el método de autenticación utilizado durante la negociación de nodos. Por defecto, Red Hat Enterprise Linux utiliza llaves pre-compartidas para la autenticación.

dh_group 2

Especifica el número de grupo Diffie-Hellman para establecer llaves de sesión generadas dinámicamente. Por defecto, se utiliza modp1024 (grupo 2).

43.6.6.2.1. El archivo de configuración de Racoon

El archivo /etc/racoon/racoon.conf debería ser idéntico en todos los nodos IPsec excepto por la declaración include "/etc/racoon/X.X.X.X.conf". Esta declaración (y el archivo que referencia) es generado cuando se activa el túnel IPsec. Para la Estación A, X.X.X.X en la declaración include, es la dirección IP de la Estación B. Lo contrario es también cierto para la Estación B. A continuación se muestra un archivo racoon.conf típico cuando se activa la conexión IPsec.

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";

Este archivo racoon.conf predeterminado incluye rutas definidas para la configuración de IPsec, archivos de llaves pre-compartidas y certificados. Los campos en sainfo anonymous describen la fase 2 SA entre nodos IPsec — la naturaleza de la conexión IPsec (incluyendo los algoritmos de encriptación soportados) y el método de intercambio de llaves. La lista siguiente define los campos de la fase 2.

sainfo anonymous

Denota que SA puede inicializarse de forma anónima con cualquier par siempre que las credenciales IPsec coincidan.

pfs_group 2

Define el protocolo de intercambio de llaves Diffie-Hellman, el cual determina el método en el cual los nodos IPsec establecen una sesión temporal mutua para la segunda fase de conectividad de IPsec. Por defecto, la implementación de Red Hat Enterprise Linux de IPsec utiliza el grupo 2 (o modp1024) de los grupos de intercambio de llaves criptográficas de Diffie-Hellman. El grupo 2 utiliza un exponente modular de 1024 bits que evita que los atacantes descifren transmisiones IPsec previas aún si una llave privada está comprometida.

lifetime time 1 hour

Este parámetro especifica el ciclo de vida de un SA y se puede cuantificar por veces o por bytes de datos. La implementación predeterminada de Red Hat Enterprise Linux de IPsec especifica un tiempo de vida de una hora.

encryption_algorithm 3des, blowfish 448, rijndael

Especifica los códigos de encriptación soportados para la fase 2. Red Hat Enterprise Linux soporta 3DES, 448-bit Blowfish y Rijndael (el código utilizado en el Advanced Encryption Standard o AES).

authentication_algorithm hmac_sha1, hmac_md5

Lista los algoritmos hash soportados para la autenticación. Los modos soportados son los códigos de autenticación de mensajes en hash (HMAC) sha1 y md5.

compression_algorithm deflate

Define el algoritmo de compresión Deflate para el soporte de IP Payload Compression (IPCOMP), lo que permite transmisiones potenciales más rápidas de datagramas IP sobre conexiones más lentas.

Para iniciar la conexión, utilice el siguiente comando en cada host:

[root@myServer ~]# /sbin/ifup <nickname>

en donde <nickname> es el nombre que especificó para la conexión IPsec.

Para verificar la conexión IPsec, ejecute la utilidad tcpdump para ver los paquetes de red que están siendo transferidos entre los hosts y verificar que están encriptados con IPsec. El paquete debería incluir una cabecera AH y se deberían mostrar como paquetes ESP. ESP significa que están encriptados. Por ejemplo:

[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem>

IP 172.16.45.107 
> 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)

43.6.7. Configuración de IPsec de red-a-red

IPsec también se puede configurar para conectar una red completa (tal como una LAN o una WAN) a una red remota a través de una conexión red-a-red. Una conexión de red-a-red requiere la configuración de enrutadores IPsec en cada lado de las redes conectantes para procesar y enrutar la información de forma transparente desde un nodo en una LAN a otro nodo en una LAN remota. La Figura 43.11, “Una conexión en túnel IPsec de red-a-red” muestra una conexión IPsec de red-a-red en túnel.

Una conexión en túnel IPsec de red-a-red

Una conexión en túnel IPsec de red-a-red

Figura 43.11. Una conexión en túnel IPsec de red-a-red

El diagrama muestra dos LAN separadas por la Internet. Estas LAN utilizan enrutadores IPsec para autenticar e iniciar una conexión usando un túnel seguro a través de la Internet. Los paquetes que son interceptados en tránsito requerirán un descifrado de fuerza bruta para poder descifrar el código protegiendo los paquetes entre las LAN. El proceso de comunicación desde un nodo en el intervalo IP 192.168.1.0/24 al otro en 192.168.2.0/24 es completamente transparente a los nodos puesto que el procesamiento, encriptación/descifrado y el enrutamiento de los paquetes IPsec es manejado completamente por el enrutador IPsec.

La información necesaria para la conexión red-a-red incluye:

  • Las direcciones IP accesibles externamente de los enrutadores IPsec dedicados

  • Los intervalos de direcciones de red de las LAN/WAN servidas por los enrutadores IPsec (tales como 192.168.0.0/24 o 10.0.1.0/24)

  • Las direcciones IP de los dispositivos de puertas de enlace que enrutan los datos desde un nodo de la red a la Internet:

  • Un nombre único, por ejemplo, ipsec1. Éste es utilizado para identificar la conexión IPsec y para distinguirla de otros dispositivos y conexiones.

  • Una llave encriptada fija o una generada automáticamente por racoon

  • Una llave de autenticación pre-compartida que se utiliza para iniciar la conexión e intercambiar las llaves de encriptación durante la sesión

43.6.7.1. Conexión (VPN) de red-a-red

Una conexión IPsec de red-a-red utiliza dos routers IPsec, uno para cada red, por los cuales el tráfico de red para la subred privada es dirigido.

Por ejemplo, como se muestra en la figura Figura 43.12, “IPsec de red-a-red”, si la red privada 192.168.1.0/24 envía tráfico de red a la red privada 192.168.2.0/24, los paquetes pasan por gateway0, a ipsec0, a través de Internet, a ipsec1, a gateway1, y a la subred 192.168.2.0/24.

Los enrutadores IPsec requieren direcciones IP públicamente accesibles y un segundo dispositivo de Ethernet conectado a sus respectivas redes privadas. El tráfico sólo pasa a través de enrutador IPsec si es dirigido a otro enrutador IPsec con el cual tiene una conexión encriptada.

IPsec de red-a-red

IPsec de red-a-red

Figura 43.12. IPsec de red-a-red

Entre las opciones de configuración de red alternativas se encuentra un cortafuego entre cada enrutador IP y la Internet y un cortafuegos de intranet entre cada enrutador IPsec y la puerta de enlace de la subred. El enrutador IPsec y la puerta de enlace para la subred pueden ser un sistema con dos dispositivos Ethernet: uno con una dirección IP pública que actúa como enrutador IPsec y otro con una dirección IP privada que actúa como puerta de enlace para la subred privada. Cada enrutador IPsec puede utilizar la puerta de enlace para su red privada o una puerta de enlace pública para enviar los paquetes al otro enrutador IPsec.

Utilice el siguiente procedimiento para configurar una conexión IPsec de red-a-red:

  1. En un intérprete de comandos escriba system-config-network para iniciar la Herramienta de administración de redes.

  2. En la pestaña IPsec, haga clic en Nuevo para iniciar el ayudante de configuración.

  3. Haga clic en Adelante para iniciar la configuración de una conexión IPsec de red-a-red.

  4. Introduzca un sobrenombre único para la conexión, por ejemplo, ipsec0. Si se requiere, seleccione la casilla de verificación para activar automáticamente la conexión cuando el computador inicie. Haga clic en Adelante para continuar.

  5. Seleccione Encriptación de red a red (VPN) como el tipo de conexión y haga clic en Adelante.

  6. Seleccione el tipo de encriptación a usar: manual o automática.

    Si selecciona encriptación manual, una llave de encriptación debe ser proporcionada posteriormente. Si selecciona encriptación automática, el demonio racoon administra la llave de encriptación. El paquete ipsec-tools debe ser instalado si desea utilizar encriptación automática.

    Haga clic en Adelante para continuar.

  7. En la página Red Local introduzca la siguiente información:

    • Dirección de red local — La dirección IP del dispositivo en el enrutador IPsec conectado a la red privada.

    • Máscara de subred local — La máscara de subred de la dirección IP de la red local.

    • Puerta de enlace local — La puerta de enlace para la puerta de enlace privada.

    Haga clic en Adelante para continuar.

    Información de red local

    Información de red local

    Figura 43.13. Información de red local

  8. En la página Red remota, introduzca la siguiente información:

    • Dirección IP remota — La dirección IP públicamente accesibles del enrutador IPsec para la otra red privada. En nuestro ejemplo, para ipsec0, introduzca la dirección IP públicamente accesible de ipsec11 y viceversa.

    • Dirección de red remota — La dirección de red de la subred privada detrás del otro enrutador IPsec. En nuestro ejemplo, introduzca 192.168.1.0 si se está configurando ipsec1, e introduzca 192.168.2.0 si configura ipsec0.

    • Máscara de subred remota — La máscara de subred de la dirección IP remota.

    • Puerta de enlace remota — La dirección IP de la puerta de enlace para la dirección de red remota.

    • Si se seleccionó la encriptación manual en el 6, especifique la llave de encriptación a utilizar o haga clic en Generar para crear una nueva.

      Especifique una llave de autenticación o haga clic en Generar para generar una. Esta llave puede ser una combinación de números y letras.

    Haga clic en Adelante para continuar.

    Información de red remota

    Información de red remota

    Figura 43.14. Información de red remota

  9. Verifique la información en la página IPsec — Resumen y haga clic en Aplicar.

  10. Seleccione Archivo => Guardar para guardar la configuración.

  11. Seleccione la conexión IPsec desde la lista y haga clic en Activar para activar la conexión.

  12. Activar reenvío IP

    1. Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1.

    2. Utilice el siguiente comando para activar el cambio:

      [root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf
      

El script de red para activar la conexión IPsec crea automáticamente los enrutadores de red para enviar los paquetes a través del enrutador IPsec si es necesario.

43.6.7.2. Configuración manual de IPsec de red-a-red

Suponga que LAN A (lana.example.com) y LAN B (lanb.example.com) desean conectarse entre ellas a través de un túnel IPsec. La dirección de red para la LAN A están en el intervalo 192.168.1.0/24, mientras que LAN B utiliza el intervalo 192.168.2.0/24. La dirección IP de la puerta de enlace es 192.168.1.254 para LAN A y 192.168.2.254 para LAN B. Los enrutadores IPsec están separados de cada puerta de enlace de las LAN y utilizan dos dispositivos de redes: eth0 está asignado a una dirección IP estática accesible externamente que tiene acceso a la Internet, mientras que eth1 actúa como un punto de enrutamiento para procesar y transmitir paquetes LAN desde un nodo de la red a los nodos de redes remotos.

La conexión IPsec entre cada red utiliza una llave pre-compartida con el valor de r3dh4tl1nux y los administradores de A y B acuerdan dejar que racoon genere automáticamente y comparta una llave de autenticación entre cada enrutador IPsec. El administrador de la LAN A decide nombrar la conexión IPsec ipsec0, mientras que el administrador de la LAN B llama a su conexión IPsec ipsec1.

El siguiente ejemplo muestra el contenido de un archivo ifcfg para una conexión IPsec de red-a-red para la LAN A. El nombre único para identificar la conexión en este ejemplo es ipsec0, por lo que el archivo resultante es llamado /etc/sysconfig/network-scripts/ifcfg-ipsec0.

TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X

La siguiente lista describe el contenido de este ejemplo:

TYPE=IPSEC

Especifica el tipo de conexión.

ONBOOT=yes

Especifica que la conexión debe ser iniciada durante el periodo de arranque.

IKE_METHOD=PSK

Especifica que la conexión utiliza llaves el método de autenticación de llaves pre-compartidas.

SRCGW=192.168.1.254

La dirección IP de la puerta de enlace fuente. Para LAN A, la puerta de enlace de LAN A, y para LAN B, la puerta de enlace LAN B.

DSTGW=192.168.2.254

La dirección IP de la puerta de enlace del destino. Para LAN A, la puerta de enlace LAN B, para LAN B, la puerta de enlace LAN A.

SRCNET=192.168.1.0/24

Especifica la red fuente para la conexión IPsec. En este ejemplo es el rango de red para LAN A.

DSTNET=192.168.2.0/24

Especifica la red de destino para la conexión IPsec. En este ejemplo es el rango de red para LAN B.

DST=X.X.X.X

Las direcciones IP accesibles externamente de LAN B.

El siguiente ejemplo muestra el contenido de un archivo de llave pre-compartida llamado /etc/sysconfig/network-scripts/keys-ipsecX (donde X es 0 para la LAN A y 1 para la LAN B) que ambas redes utilizan para autenticarse mutuamente. Los contenidos de este archivo deberían ser idénticos y solamente el usuario root debería tener acceso a leer o escribir en este archivo.

IKE_PSK=r3dh4tl1nux

Importante

Para cambiar el archivo keys-ipsecX para que solamente el usuario root pueda leerlo o modificarlo, ejecute el comando siguiente después de crear el archivo:

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para cambiar la llave de autenticación en algún momento, modifique el archivo keys-ipsecX en ambos enrutadores IPsec. Ambas llaves deber ser idénticas para obtener una conectividad apropiada.

El siguiente ejemplo muestra el contenido del archivo de configuración /etc/racoon/racoon.conf para la conexión IPsec. Observe que la línea include al final del archivo es generada automáticamente y solamente aparece si el tunel IPsec se está ejecutando.

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
  
sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

A continuación se muestra la configuración específica para la conexión a la red remota. El archivo es llamado X.X.X.X.conf (reemplace X.X.X.X con la dirección IP del enrutador IPsec remoto). Observe que este archivo es generado automáticamente una vez que el túnel IPsec es activado y no se debería modificar directamente.

remote X.X.X.X
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

Antes de iniciar la conexión IPsec, se debería activar el reenvío IP en el kernel. Para activar el reenvío IP:

  1. Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1.

  2. Utilice el siguiente comando para activar el cambio:

    [root@myServer ~] # sysctl -p /etc/sysctl.conf
    

Para iniciar la conexión IPsec, ejecute el comando siguiente en cada enrutador:

[root@myServer ~] # /sbin/ifup ipsec0

Las conexiones son activadas y ambas LAN A y LAN B son capaces de comunicarse entre ellas. Los enrutadores se crean automáticamente a través del script de inicialización que se llama ejecutando ifup en la conexión IPsec. Para mostrar una lista de rutas para la red, ejecute el comando siguiente:

[root@myServer ~] # /sbin/ip route list

Para evaluar la conexión IPsec, ejecute la utilidad tcpdump en el dispositivo enrutable externamente (eth0 en este ejemplo) para así ver los paquetes de red que están siendo transmitidos entre los hosts (o redes) y verificar que están encriptados a través de IPsec. Por ejemplo, para verificar la conectividad IPsec de la LAN A, escriba lo siguiente:

[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com

El paquete debería incluir una cabecera AH y se deberían mostrar como paquetes ESP. ESP significa que están encriptados. Por ejemplo (las barras oblícuas denotan la continuación de una línea):

12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
        lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
        (ipip-proto-4)

43.6.8. Iniciando y deteniendo conexiones IPsec

Si la conexión IPsec no fue configurada para activar durante el inicio, usted puede controlarla desde la línea de comandos.

Para iniciar la conexión, utilice el siguiente comando para cada host en una conexión IPsec de host-a-host o cada enrutador IPsec para una conexión IPsec de red-a-red:

[root@myServer ~] # /sbin/ifup <nickname>

donde <nickname> es el apodo configurado anteriormente, por ejemplo ipsec0.

Para detener la conexión utilice el siguiente comando:

[root@myServer ~] # /sbin/ifdown <nickname>

43.7. IPTables

Red Hat Enterprise Linux contiene herramientas avanzadas para el filtrado de paquetes de red — el proceso de controlar los paquetes de red al entrar, mientras se mueven y cuando salen de la red dentro del kernel. Los kernels anteriores al 2.4 dependían en ipchains para el filtrado de paquetes y usaban listas de reglas aplicadas a los paquetes en cada paso del proceso de filtrado. La introducción de kernel 2.4 trajo consigo iptables (también llamado netfilter); aunque es similar a ipchains, expande enormemente el ámbito y el control disponible para el filtrado de paquetes de red.

Este capítulo se centra en las nocivas básicas del filtrado de paquetes, define las diferencias entre ipchains e iptables, explica las diferentes opciones disponibles con comandos iptables y muestra cómo se pueden preservar las reglas de filtrado durante reinicios del sistema.

Para instrucciones sobre cómo construir reglas iptables y configurar un cortafuegos basado en estas reglas, consulte la Sección 43.7.7, “Recursos adicionales”.

Aviso

El mecanismo predeterminado de cortafuegos en la versión 2.4 y posterior del kernel es iptables, pero éste no se puede usar si ya se está ejecutando ipchains. Si ipchains está presente durante el arranque, el kernel emitirá un error y no podrá arrancar iptables.

Estos errores no afectan la funcionalidad del comando ipchains.

43.7.1. Filtrado de paquetes

El kernel de Linux utiliza Netfilter para filtrar paquetes, permitiendo aceptar algunos de ellos en el sistema mientras que intercepta y detiene otros. Esta utilidad es interna en el kernel de Linux e incorpora las siguientes tres tablas o listas de reglas:

  • filter — La tabla por defecto para el manejo de paquetes de red.

  • nat — Usada para alterar paquetes que crean una nueva conexión y utilizada para la Traducción de direcciones de red (Network Address Translation, NAT).

  • mangle — Usada por tipos específicos de alteración de paquetes.

Cada una de estas tablas tiene un grupo de cadenas incorporadas que corresponden a las acciones llevadas a cabo en el paquete por netfilter.

Las cadenas internas para la tabla filtro son las siguientes:

  • INPUT — Aplica a los paquetes recibidos a través de una interfaz de red.

  • OUTPUT — Esta cadena sirve para paquetes enviados por medio de la misma interfaz de red que recibió los paquetes.

  • FORWARD — Esta cadena sirve para paquetes recibidos en una interfaz de red y enviados en otra.

Las cadenas internas para la tabla nat son las siguientes:

  • PREROUTING — Altera los paquetes de red cuando estos llegan.

  • POSTROUTING — Esta cadena altera paquetes antes de que sean enviados por medio de una interfaz de red.

  • POSTROUTING — Altera los paquetes de red cuando estos son enviados.

PREROUTING — Esta cadena altera paquetes recibidos por medio de una interfaz de red cuando llegan.

  • OUTPUT — Esta cadena altera paquetes generados localmente antes de que sean dirigidos por medio de una interfaz de red.

  • POSTROUTING — Esta cadena altera paquetes antes de que sean enviados por medio de una interfaz de red.

  • Las cadenas internas para la tabla mangle son las siguientes:

  • PREROUTING — Esta cadena altera paquetes recibidos por medio de una interfaz de red antes de que sean dirigidos.

  • POSTROUTING — Altera los paquetes de red cuando estos son enviados.

Cada paquete de red recibido o enviado desde un sistema Linux está sujeto a al menos una tabla. Sin embargo, un paquete puede estar sometido a múltiples reglas dentro de cada tabla antes de emerger al final de la cadena. La estructura y propósito de estas reglas puede variar, pero normalmente buscan identificar un paquete que viene de o se dirige hacia una direccción IP en particular, o un conjunto de direcciones, cuando utiliza un determinado protocolo y servicio de red.

Nota

Por defecto. las reglas del cortafuegos son guardadas en los archivos /etc/sysconfig/iptables o /etc/sysconfig/ip6tables.

El servicio iptables es iniciado antes que el resto de servicios relacionados con DNS cuando un sistema Linux es iniciado. Esto significa que las reglas del cortafuegos solo pueden ser referenciadas a través de las direcciones IP (por ejemplo 192.168.0.1). Los nombres de dominios (por ejemplo, host.example.com) en dichas reglas producen errores.

Independientemente de su destino, cuando un paquete cumple una regla en particular en una de las tablas, se les aplica un objetivo (target) o acción. Si la regla especifica un objetivo ACCEPT para un paquete que coincida, el paquete salta el resto de las verificaciones de la regla y se le permite continuar hacia su destino. Si una regla especifica un objetivo DROP, al paquete se le niega el acceso al sistema y no se envía nada de vuelta al servidor que envió el paquete. Si una regla especifica un objetivo QUEUE, el paquete pasa al espacio del usuario. Si una regla especifica el objetivo opcional REJECT, el paquete es descartado, pero se envía un paquete de error al que envió el paquete.

Cada cadena tiene una política por defecto de ACCEPT, DROP, REJECT, o QUEUE. Si ninguna de estas reglas en la cadena se aplican al paquete, entonces el paquete es tratado de acuerdo a la política por defecto.

El comando iptables configura estas tablas, así como también configura nuevas tablas si es necesario.

43.7.2. Diferencias entre IPTables y IPChains

Tanto ipchains como iptables usan cadenas de reglas que operan dentro del kernel de Linux para decidir qué hacer con los paquetes que cumplen determinadas reglas. Sin embargo, iptables proporciona un método de filtrado de paquetes que puede ser extendido más fácilmente, brindando al administrador un nivel de control mucho más refinado sin tener que aumentar la complejidad del sistema entero.

Tenga en cuenta las siguientes diferencias entre iptables y ipchains:

Si se utiliza iptables, cada paquete filtrado se procesa utilizando reglas de una cadena y no de múltiples cadenas.

Por ejemplo, un paquete FORWARD que llega a un sistema usando ipchains tendrá que pasar por las cadenas INPUT, FORWARD, y OUTPUT para llegar a su destino. Sin embargo, iptables sólo envía paquetes a la cadena INPUT si su destino es el sistema local y tan sólo los envía a la cadena OUTPUT si el sistema local es quien genera los paquetes. Por esta razón, es importante que coloque la regla designada para capturar un paquete particular dentro de la regla que en verdad maneja el paquete.

El objetivo DENY ha sido cambiado a DROP.

En ipchains, los paquetes que coincidan con una regla en una cadena podrían ser dirigidos al objetivo DENY. Este objetivo debe ser cambiado a DROP bajo iptables.

El orden de las opciones en una regla es importante.

En ipchains, el orden de las opciones de la regla no importa.

El comando iptables usa una sintaxis más estricta. En comandos iptables, el protocolo (ICMP, TCP o UDP) debe ser especificado antes del puerto fuente o destino.

Las interfaces de red deben ser asociadas con la cadena correcta en las reglas del cortafuegos.

Por ejemplo, las interfaces de entrada (opción -i) sólo pueden ser usadas en cadenas INPUT o FORWARD. Asimismo, interfaces de salida (opción -o) sólo pueden ser usadas en cadenas FORWARD o OUTPUT.

En otras palabras, las cadenas INPUT y las interfaces de entrada trabajan juntas; las cadenas OUTPUT y las interfaces de salida trabajan juntas. Las cadenas FORWARD trabajan tanto con las interfaces de entrada como con las interfaces de salida.

Las cadenas OUTPUT ya no se utilizan en interfaces de entrada; asimismo los paquetes que van a las interfaces de salida no ven las cadenas INPUT.

Esta no es una lista completa de los cambios. Consulte la Sección 43.7.7, “Recursos adicionales” para obtener mayor información.

43.7.3. Opciones de comandos para IPTables

Las reglas para el filtrado de paquetes se crean con el comando iptables. Las siguientes características del paquete son con frecuencia utilizadas como criterio:

  • Tipo de paquete — Dicta qué tipo de paquetes filtra el comando.

  • Fuente/Destino del paquete — Especifica cuáles paquetes filtra el comando basándose en el origen o destino del paquete.

  • Objetivo — Indica qué acción es tomada en paquetes que cumplen los criterios mencionados anteriormente.

Consulte la Sección 43.7.3.4, “Opciones de coincidencia para IPTables” y la Sección 43.7.3.5, “Opciones del objetivo” para obtener mayor información sobre las opciones específicas que conciernen estos aspectos de un paquete.

Las opciones usadas con las reglas iptables dadas deben estar agrupadas lógicamente, basándose en el propósito y en las condiciones de la regla general, para que la regla sea válida. El resto de esta sección explica las opciones más usadas para el comando iptables.

43.7.3.1. Estructura de las opciones del comando para IPTables

Muchos comandos iptables tienen la siguiente estructura:

 iptables [-t <table-name>] <command><chain-name> \ <parameter-1><option-1> \ <parameter-n><option-n>

<table-name> — Especifica la tabla sobre la cual la tabla es aplicada. Si se omite, se utiliza la tabla filter.

<command> — Especifica la acción a ejecutar,tal como la adición o borrado de reglas.

<chain-name> — Especifica la cadena a editar, crear o borrar.

<parameter>-<option> pareja — los parámetros y las opciones asociadas que especifican cómo procesar un paquete que coincide con la regla.

El largo y complejidad de un comando iptables puede cambiar significativamente según su propósito.

Por ejemplo, un comando para remover una regla de una cadena puede ser muy corto:

iptables -D <chain-name> <line-number>

En contraste, un comando que añade una regla que filtra paquetes desde una subnet particular utilizando una variedad de parámetros y opciones específicos puede ser bastante largo. Al construir comandos iptables, es importante recordar que algunos parámetros y opciones requieren parámetros y opciones adicionales para construir una regla válida. Esto puede producir una reacción en cadena, si el parámetro adicional requiere más parámetros. Hasta que no se satisfagan todos los parámetros y opciones, la regla no es válida.

Escriba iptables -h para ver una lista detallada de la estructura del comando iptables.

43.7.3.2. Opciones de comandos

Las opciones de comandos le dicen a iptables que realice una acción específica. Solo se permite una opción de comando por cada comando iptables. Excepto el comando de ayuda, todos los comandos se escriben en mayúsculas.

Los comandos de iptables son los siguientes:

  • -A — Añade la regla al final de la cadena especificada. A diferencia de la opción -I descrita a continuación, no requiere un entero como argumento. Siempre añade una regla al final de la cadena especificada.

  • -C — Verifica una regla en particular antes de añadirla en la cadena especificada por el usuario. Este comando puede ser de ayuda para construir reglas iptables complejas pidiéndole que introduzca parámetros y opciones adicionales.

  • -D <integer> | <rule> — Borra una regla de una cadena en particular según su número (5 para la quinta regla de una cadena). Puede también teclear la regla entera y iptables borrará la regla en la cadena que corresponda.

  • -E — Renombra una cadena definida por el usuario. Una cadena definida por el usuario es cualquier cadena diferente a las cadenas predeterminadas. (Consulte la opción -N, para obtener mayor información sobre cómo crear cadenas definidas por el usuario.) Este es un cambio superficial que no afecta la estructura de la tabla.

    Nota

    Si usted intenta renombrar una de las cadenas predeterminadas, el sistema reportará el error Match not found (No se encontró una coincidencia). No se pueden renombrar las cadenas predeterminadas.

  • -F — Libera la cadena seleccionada, borrando cada una de las reglas de la cadena. Si no se especifica ninguna cadena, este comando libera cada regla de cada cadena.

  • -h — Proporciona una lista de estructuras de comandos, así como también un resúmen rápido de parámetros de comandos y opciones.

  • -I [<integer>] — Inserta una regla en una cadena en un punto especificado por un valor entero definido por el usuario. Si no se especifica ningún número, la regla será ubicada en la parte superior de la cadena.

    Atención

    Como se mencionó anteriormente, el orden de reglas en una cadena determina cuáles reglas se deben aplicar a cuáles paquetes. Esto es importante de recordar cuando se añaden reglas con la opción -A o -I.

    Este factor es importante al añadir reglas utilizando -I con un entero. Si usted especifica un número existente al añadir una regla a una cadena, iptables añade una nueva regla antes (o después) de la regla existente.

  • -L — Lista todas las reglas de la cadena especificada tras el comando. Para ver una lista de todas las reglas en todas las cadenas en la tabla por defecto filter, no especifique ninguna cadena o tabla. De lo contrario, la sintaxis siguiente deberá utilizarse para listar las reglas en una cadena específica en una tabla en particular:

     iptables -L <chain-name> -t <table-name>
    

    En la Sección 43.7.3.6, “Opciones de listado” se describen opciones adicionales para la opción de comando -L, que proporcionan números de reglas y permiten descripciones más detalladas.

  • -N — Crea una nueva cadena con un nombre especificado por el usuario. El nombre de la cadena debe ser único, de lo contrario un mensaje de error será reportado.

  • -P — Configura la política por defecto para una cadena en particular, de tal forma que, cuando los paquetes atraviesen la cadena completa sin cumplir ninguna regla, serán enviados a un objetivo en particular, como puedan ser ACCEPT o DROP.

  • -R — Reemplaza una regla en una cadena particular. El número de la regla debe ser especificado después del nombre de la cadena. La primera regla en una cadena corresponde a la regla número uno.

  • -X — Borra una cadena especificada por el usuario. No se permite borrar ninguna de las cadenas predefinidas.

  • -Z — Pone ceros en los contadores de byte y de paquete en todas las cadenas de una tabla en particular.

43.7.3.3. Opciones de parámetros en IPTables

Una vez que se especifiquen ciertos comandos iptables, incluyendo aquellos para añadir, anexar, eliminar, insertar o reemplazar reglas dentro de una cadena, se requieren parámetros para construir una regla de filtrado de paquetes.

  • -c — Resetea los contadores de una regla en particular. Este parámetro acepta las opciones PKTS y BYTES para especificar qué contador hay que resetear.

  • -d — Configura el nombre de la máquina destino, dirección IP o red de un paquete que coincide con la regla. Cuando se coincida una red, se soportan los siguientes formatos de direcciones IP o máscaras de red:

    • N.N.N.N/M.M.M.M — Donde N.N.N.N es el rango de direcciones IP y M.M.M.M es la máscara de la red.

    • N.N.N.N/M — Donde N.N.N.N es el rango de direcciones IP y M es la máscara de bit.

  • -f — Aplica esta regla sólo a los paquetes fragmentados.

    Usando la opción ! después de este parámetro, únicamente se harán coincidir los paquetes no fragmentados.

    Nota

    La distinción entre paquetes fragmentados y sin fragmentar es conveniente, sin importar que los paquetes fragmentados son parte del estándar del protocolo IP.

    Originalmente diseñado para permitir que los paquetes IP viajen sobre redes con diferentes tamaños de marco, la fragmentación es comúnmente utilizada para generar ataques DoS (negación de servicio) con paquetes mal formados. Es importante tener en cuenta que IPv6 no permite la fragmentación.

  • -i — Configura la interfaz de red entrante, tal como eth0 o ppp0. Con iptables, este parámetro opcional puede ser usado solamente con las cadenas INPUT y FORWARD cuando es usado con la tabla filter y la cadena PREROUTING con las tablas nat y mangle.

    Este parámetro también soporta las siguientes opciones especiales:

    • El carácter de exclamación ! — Invierte la directriz, es decir, se excluye de esta regla cualquier interfaz especificada.

    • El caráter de suma + — Un caracter tipo comodín utilizado para coincidir todas las interfaces con una cadena de caracteres especificada. Por ejemplo, el parámetro -i eth+ aplicará esta regla a cualquier interfaz Ethernet pero excluirá cualquier otra interfaz, tal como, ppp0.

    Si el parámetro -i se utiliza sin especificar ninguna interfaz, todas las interfaces estarán afectadas por la regla.

  • -j — Salta al objetivo especificado cuando un paquete coincide con una regla particular.

    Los objetivos estándar son ACCEPT, DROP, QUEUE y RETURN.

    Las opciones extendidas también están disponibles a través de los módulos cargados por defecto con el RPM de iptables en Red Hat Enterprise Linux. Entre los objetivos válidos de estos módulos están LOG, MARK y REJECT, entre otros. Consulte la página man de iptables para más información sobre esto y otros objetivos.

    Esta opción puede ser usada para dirigir un paquete que coincide con una regla particular a una cadena definida por el usuario que se encuentra fuera de la cadena actual. De esta forma, otras reglas pueden ser aplicadas al paquete.

    Si no especifica ningún objetivo, el paquete pasa la regla sin llevar a cabo ninguna acción. A pesar de todo, el contador para esta regla se sigue incrementando en uno.

  • -o — Configura la interfaz de red de salida para una regla. Esta opción es válida únicamente con las cadenas OUTPUT y FORWARD en la tabla de filter y la cadena POSTROUTING en las tablas nat y mangle. Estos parámetros aceptan las mismas opciones que aquellos de la interfaz de entrada (-i).

  • -p — Configura el protocolo IP afectado por la regla. Puede ser icmp, tcp, udp, o all; puede ser un valor numérico que representa uno de estos protocolos o uno diferente. Puede usar cualquier protocolo listado en /etc/protocols.

    El protocolo "all" significa que la regla es aplicable a todos los protocolos conocidos. Si no hay protocolos listados con esta regla, el valor predeterminado es "all".

  • -s — Configura la fuente para un paquete particular usando la misma sintaxis que el parámetro (-d).

43.7.3.4. Opciones de coincidencia para IPTables

Diferentes protocolos de red proporcionan opciones especializadas de coincidencia que pueden ser configuradas para coincidir con un paquete particular usando ese protocolo. Sin embargo, primero se debe especificar el protocolo con el comando iptables. Por ejemplo, -p <protocolo> activa las opciones para el protocolo especificado. Tenga en cuenta que usted puede utilizar el ID del protocolo en vez del nombre. Revise los siguientes ejemplos, cada uno de éstos tiene el mismo efecto:

 iptables -A INPUT -p icmp --icmp-type any -j ACCEPT  iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT 

La definición de servicios se proporciona en el archivo /etc/services. Para facilitar la lectura, se recomienda utilizar el nombre del servicio y no el número de puerto.

Importante

Asegure el archivo /etc/services para evitar que sea editado sin autorización. Si este archivo puede ser editado, crackers pueden utilizarlo para abrir puertos en su máquina que usted ha cerrado. Para asegurar este archivo, escriba el comando siguiente como root:

 [root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services 

Esto previene que el archivo sea renombrado, borrado o que se creen enlaces a éste.

43.7.3.4.1. Protocolo TCP

Estas opciones de identificación están disponibles en el protocolo TCP (opción -p tcp):

  • --dport — Establece el puerto de destino para el paquete.

    Para configurar esta opción utilice el nombre del servicio (tal como www o smtp), un número de puerto o un rango de números de puertos.

    Para especificar un rango de números de puertos, separe los dos números con dos puntos (:), tal como -p tcp --dport 3000:3200. El rango más grande aceptable es 0:65535.

    Use un carácter de exclamación (!) después de la opción --dport para que los paquetes que no utilizan el servicio de red o puerto coincidan.

    Para ver los nombres y aliases de los servicios de red y números de puertos que utilizan, revise el archivo /etc/services.

    La opción de coincidencia --destination-port es igual a --dport.

  • --sport — Configura el puerto fuente del paquete usando las mismas opciones que --dport. La opción --source-port es sinónimo con --sport.

  • --syn — Se aplica a todos los paquetes TCP designados a iniciar la comunicación, comúnmente llamados paquetes SYN. Cualquier paquete que esté llevando un payload de datos no será tocado.

    Utilice el carácter de exclamación (!) después de --syn para coincidir los paquetes que nos sean SYN.

  • --tcp-flags <tested flag list> <set flag list> Permite a los paquetes TCP con bits o banderas específicas, ser coincididos con una regla.

    La opción --tcp-flags acepta dos parámetros. El primer parámetro es la máscara, una lista de banderas a ser examinadas en el paquete. El segundo parámetro es una lista de banderas separadas por comas que se deben establecer para que la regla coincida.

    Las banderas posibles son:

    • ACK

    • FIN

    • PSH

    • RST

    • SYN

    • URG

    • ALL

    • NONE

    Por ejemplo, una regla iptables que contenga la siguiente especificación solo coincidirá con paquetes TCP que tengan la bandera SYN activa y las banderas ACK y FIN sin activar.

    --tcp-flags ACK,FIN,SYN SYN

    Usando el caracter de exclamación (!) después de --tcp-flags reversa el efecto de la opción de coincidencia.

  • --tcp-option — Intenta seleccionar con opciones específicas de TCP que pueden estar activas en un paquete en particular. Esta opción se puede revertir con el punto de exclamación (!).

43.7.3.4.2. Protocolo UDP

Estas opciones de selección están disponibles para el protocolo UDP (-p udp):

  • --dport — Especifica el puerto destino del paquete UDP, usando el nombre del servicio, número de puerto, o rango de números de puertos. La opción de coincidencia --destination-port es sinónimo con --dport.

  • --sport — Configura el puerto fuente del paquete UDP, usando el nombre de puerto, número de puerto o rango de números de puertos. La opción --source-port es sinónimo con --sport.

Para especificar un rango de números de puertos para las opciones --dport y --sport, separe los dos números con dos puntos (:). Por ejemplo, -p tcp --dport 3000:3200. El rango más grande aceptable es 0:65535.

43.7.3.4.3. Protocolo ICMP

Las siguientes opciones de coincidencia están disponibles para el Protocolo de mensajes de Internet (ICMP) (-p icmp):

  • --icmp-type — Selecciona el nombre o el número del tipo ICMP que concuerde con la regla. Se puede obtener una lista de nombres válidos ICMP escribiendo el comando iptables -p icmp -h.

43.7.3.4.4. Módulos con opciones de coincidencias adicionales

Opciones adicionales de coincidencia están disponibles a través de los módulos cargados por el comando iptables.

Para usar un módulo de opciones de coincidencia, cargue el módulo por nombre usando -m <nombre-modulo> (reemplazando <nombre-modulo> con el nombre del módulo).

Un gran número de módulos están disponibles por defecto. Es posible crear sus módulos para proporcionar funcionalidades adicionales.

Lo siguiente, es una lista parcial de los módulos usados más comúnmente:

  • módulo limit — Permite colocar un límite en cuántos paquetes son coincididos a una regla particular.

    Cuando se usa en conjunto con el objetivo LOG, el módulo limit puede prevenir que una inundación de paquetes coincidentes sobrecarguen el registro del sistema con mensajes repetitivos o usen los recursos del sistema.

    Consulte la Sección 43.7.3.5, “Opciones del objetivo” para obtener mayor información sobre los objetivos LOG.

    El módulo limit habilita las opciones siguientes:

    • --limit — Configura el número de coincidencias en un intervalo de tiempo, especificado con un número y un modificador de tiempo ordenados en el formato <número>/<tiempo>. Por ejemplo, si usamos --limit 5/hour sólo dejaremos que una regla sea efectiva cinco veces por hora.

      Se pueden especificar los periodos en segundos, minutos, horas o días.

      Si no se utiliza ningún número ni modificador de tiempo, se asume el siguiente valor por defecto: 3/hour.

    • --limit-burst — Configura un límite en el número de paquetes capaces de cumplir una regla en un determinado tiempo.

      Esta opción deberá ser usada junto con la opción --limit, y acepta un número entero.

      Si no se utiliza ningún valor, se asume el valor por defecto (5).

  • módulo state — Habilita la coincidencia de estado.

    El módulo state tiene las siguientes opciones:

    • --state — coincide un paquete con los siguientes estados de conexión:

      • ESTABLISHED — El paquete coincidente se asocia con otros paquetes en una conexión establecida. Usted necesita aceptar este estado si desea mantener una conexión entre un cliente y un servidor.

      • INVALID El paquete seleccionado no puede ser asociado a una conexión conocida.

      • NEW — El paquete coincidente o bien está creando una nueva conexión o bien forma parte de una conexión de dos caminos que antes no había sido vista. Usted necesita aceptar este estado si desea permitir nuevas conexiones a un servicio.

      • RELATED — El paquete coincidente está iniciando una nueva conexión relacionada de alguna manera a una conexión existente.Un ejemplo es FTP, el cual utiliza una conexión para control de tráfico (puerto 21) y una conexión separada para transferencia de datos (puerto 20).

      Estos estados de conexión se pueden utilizar en combinación con otros separándolos mediante comas como en -m state --state INVALID, NEW.

  • módulo mac — Habilita la coincidencia de direcciones MAC de hardware.

    El módulo mac activa las opciones siguientes:

    • --mac-source — Coincide una dirección MAC a la tarjeta de red que envió el paquete. Para excluir una dirección MAC de la regla, coloque un símbolo de exclamación (!) después de la opción --mac-source.

Consulte la página man de iptables para obtener más opciones disponibles a través de los módulos.

43.7.3.5. Opciones del objetivo

Una vez que un paquete ha coincidido con una regla, la regla puede dirigir el paquete a un número de objetivos diferentes que determinan la acción apropiada. Cada cadena tiene un objetivo por defecto, el cual es usado si ninguna de las reglas en esa cadena coinciden con un paquete o si ninguna de las reglas que coinciden con el paquete especifica un objetivo.

Los siguientes son los objetivos estándar:

  • <user-defined-chain> — Una cadena definida por el usuario dentro de una tabla. Los nombres de cadenas definidas por el usuario deben ser únicos. Este objetivo pasa el paquete a la cadena especificada.

  • ACCEPT — Permite que el paquete se mueva hacia su destino o hacia otra cadena.

  • DROP — Deja caer el paquete sin responder al solicitante. El sistema que envia el paquete no es notificado de esta falla.

  • QUEUE — El paquete se pone en una cola para ser manejado por una aplicación en el espacio de usuario.

  • RETURN — Detiene la verificación del paquete contra las reglas de la cadena actual. Si el paquete con un destino RETURN cumple una regla de una cadena llamada desde otra cadena, el paquete es devuelto a la primera cadena para retomar la verificación de la regla allí donde se dejó. Si la regla RETURN se utiliza en una cadena predefinida y el paquete no puede moverse hacia la cadena anterior, el objetivo por defecto de la cadena actual es utilizado.

Además, hay otras extensiones que permiten especificar otros objetivos. Estas extensiones son llamadas módulos de objetivos o módulos de opciones de coincidencia. La mayoría sólo se aplican a tablas y situaciones especificas. Consulte la Sección 43.7.3.4.4, “Módulos con opciones de coincidencias adicionales” para obtener mayor información sobre los módulos de opciones de coincidencia.

Existen varios módulos extendidos de objetivos, la mayoría de los cuales tan sólo se aplican a tablas o situaciones específicas. Algunos de los módulos de objetivos más comunes incluidos en Red Hat Enterprise Linux son:

  • LOG — Registra todos los paquetes que coinciden con esta regla. Puesto que los paquetes son registrados por el kernel, el archivo /etc/syslog.conf determina dónde estas entradas de registro serán escritas. Por defecto, son colocadas en el archivo /var/log/messages.

    Se pueden usar varias opciones adicionales tras el objetivo LOG para especificar la manera en la que tendrá lugar el registro:

    • --log-level — Configura el nivel de prioridad del registro de eventos. Una lista de los niveles de prioridad se puede encontrar en la página man de syslog.conf.

    • --log-ip-options — Registra cualquier opción en la cabecera de un paquete IP.

    • --log-prefix — Coloca una cadena de hasta 29 caracteres antes de la línea de registro cuando es escrita. Esto es muy útil para la escritura de filtros de syslog para usarlos en conjunto con el registro de paquetes.

      Nota

      Debido a un problema con esta opción, se debe añadir un espacio al valor log-prefix.

    • --log-tcp-options — Cualquier opción colocada en la cabecera de un paquete TCP es registrada.

    • --log-tcp-sequence Escribe el número de secuencia TCP del paquete en el registro del sistema.

  • REJECT — Envia un paquete de error de vuelta al sistema remoto y deja caer el paquete.

    El objetivo REJECT acepta --reject-with <tipo> (donde <tipo> es el tipo de rechazo) el cual permite devolver información más detallada con el paquete de error. El mensaje port-unreachable es el tipo de error por defecto dado si no se usa otra opción. Para una lista completa de las opciones <tipo>, consulte la página man de iptables.

Otras extensiones de objetivos, incluyendo muchas que son útiles para el enmascaramiento de IP usando la tabla nat o con alteración de paquetes usando la tabla mangle, se puede encontrar en la página man de iptables.

43.7.3.6. Opciones de listado

El comando predeterminado para listar, iptables -L [<nombre-cadena>], proporciona una vista muy básica de los filtros por defecto de las cadenas actuales de la tabla. Las opciones adicionales proporcionan más información:

  • -v — Muestra la salida por pantalla con detalles, como el número de paquetes y bytes que cada cadena ha procesado, el número de paquetes y bytes que cada regla ha coincidido y qué interfaces se aplican a una regla en particular.

  • -x — Expande los números en sus valores exactos. En un sistema ocupado, el número de paquetes y bytes vistos por una cadena en concreto o por una regla puede estar abreviado en Kilobytes, Megabytes o Gigabytes. Esta opción fuerza a que se muestre el número completo.

  • -n Muestra las direcciones IP y los números de puertos en formato numérico, en lugar de utilizar el nombre del servidor y la red tal y como se hace por defecto.

  • --line-numbers — Proporciona una lista de cada cadena junto con su orden numérico en la cadena. Esta opción puede ser útil cuando esté intentando borrar una regla específica en una cadena o localizar dónde insertar una regla en una cadena.

  • -t <nombre-tabla> — Especifica un nombre de tabla. Si se omite, el valor predeterminado es la tabla de filtro (filter)

Los siguientes ejemplos ilustran el uso de varias de esas opciones. Note la diferencia en los byte mostrados al incluir la opción -x.

 [root@myserver ~]# iptables -L OUTPUT -v -n -x Chain OUTPUT (policy ACCEPT 64005 packets, 6445791 bytes) pkts bytes target prot opt in out source destination 1593 133812 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#iptables -L OUTPUT -v -n Chain OUTPUT (policy ACCEPT 64783 packets, 6492K bytes) pkts bytes target prot opt in out source destination 1819 153K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]# 

43.7.4. Guardando reglas IPTables

Las reglas creadas con el comando iptables son almacenadas en memoria. Si el sistema es reiniciado antes de guardar el conjunto de reglas iptables, se perderán todas las reglas. Para que las reglas de filtrado de red persistan luego de un reinicio del sistema, éstas necesitan ser guardadas. Para hacerlo, escriba el siguiente comando como root:

 /sbin/service iptables save 

Esto ejecuta el script de inicio iptables, el cual ejecuta el programa /sbin/iptables-save y escribe la configuración actual de iptables a /etc/sysconfig/iptables. El archivo /etc/sysconfig/iptables existente es guardado como /etc/sysconfig/iptables.save.

La próxima vez que se inicie el sistema, el script de inicio de iptables volverá a aplicar las reglas guardadas en /etc/sysconfig/iptables usando el comando /sbin/iptables-restore.

Aún cuando siempre es una buena idea probar una regla de iptables antes de confirmar los cambios al archivo /etc/sysconfig/iptables, es posible copiar reglas iptables en este archivo desde otra versión del sistema de este archivo. Esto proporciona una forma rápida de distribuir conjuntos de reglas iptables a muchas máquinas.

Es posible guardar las reglas iptables en un archivo separado para ser distribuido, como copia de seguridad o bajo algún otro propósito. Para guardar sus reglas iptables, escriba el siguiente comando como root:

 [root@myserver ~]# iptables-save > <archivo>
en donde <archivo> es un nombre definido por el usuario para ese juego de reglas.

Importante

Si se está distribuyendo el archivo /etc/sysconfig/iptables a otras máquinas, escriba /sbin/service iptables restart para que las nuevas reglas surtan efecto.

Nota

Note la diferencia entre el comandoiptables (/sbin/iptables), el cual es utilizado para manipular las tablas y las cadenas que constituyen la funcionalidad de iptables, y el servicioiptables (/sbin/iptables service), utilizado para activar o desactivar el servicio iptables.

43.7.5. Scripts de control de IPTables

Hay dos métodos básicos para controlar iptables en Red Hat Enterprise Linux:

  • /sbin/service iptables <opción> — Utilizado para manipular varias funciones de iptables a través de su script de inicio. Dispone de las siguientes opciones:

    • start — Si se tiene un cortafuegos configurado (es decir, si /etc/sysconfig/iptables existe), todos los iptables en ejecución son detenidos completamente y luego arrancados usando el comando /sbin/iptables-restore. Esta opción solo funcionará si no se carga el módulo del kernel ipchains. Para revisar si este módulo está cargado, ejecute como root el siguiente comando:

       [root@MyServer ~]# lsmod | grep ipchains 
      

      Si este comando no retorna ninguna salida, significa que el módulo no está cargado. De ser necesario, utilice /sbin/rmmod para remover el módulo.

    • stop — Si el cortafuegos está en ejecución, se descartan las reglas del cortafuegos que se encuentran en memoria y todos los módulos iptables y ayudantes son descargados.

      Si se cambia la directiva IPTABLES_SAVE_ON_STOP dentro del archivo de configuración /etc/sysconfig/iptables-config de su valor por defecto a yes, se guardan las reglas actuales a /etc/sysconfig/iptables y cualquier regla existente se moverá al archivo /etc/sysconfig/iptables.save.

      Para mayor información sobre el archivo de configuración iptables-config, consulte la Sección 43.7.5.1, “Archivo de configuración de scripts de control de IPTables”.

    • restart — Si el cortafuegos está en ejecución, las reglas del mismo que se encuentran en memoria se descartan y se vuelva a iniciar el cortafuegos si está configurado en /etc/sysconfig/iptables. La directriz restart sólo funcionará si no está cargado el módulo del kernel ipchains.

      Si la directiva IPTABLES_SAVE_ON_RESTART dentro del archivo de configuración /etc/sysconfig/iptables-config se cambia de su valor por defecto a yes, las reglas actuales son guardadas a /etc/sysconfig/iptables y cualquier regla existente se moverán al archivo /etc/sysconfig/iptables.save.

      Para mayor información sobre el archivo de configuración iptables-config, consulte la Sección 43.7.5.1, “Archivo de configuración de scripts de control de IPTables”.

    • status — Muestra el estado del cortafuegos y lista todas las reglas activas.

      La configuración por defecto para esta opción muestra las direcciones IP en cada regla. Para mostrar el nombre de dominio y el nombre de host, edite el archivo /etc/sysconfig/iptables-config y cambie el valor de IPTABLES_STATUS_NUMERIC a no. Consulte la Sección 43.7.5.1, “Archivo de configuración de scripts de control de IPTables” para más información sobre el archivo iptables-config.

    • panic — Descarta todas las reglas del cortafuegos. La política de todas las tablas configuradas es establecida a DROP.

      Esta opción puede ser útil si se sabe que un servidor está comprometido. En vez de desconectar físicamente el servidor de la red o apagar el sistema, usted puede utilizar esta opción para detener el tráfico pero dejando la máquina en un estado que puede ser utilizado para análisis.

    • save — Guarda las reglas del cortafuegos a /etc/sysconfig/iptables usando iptables-save. Para más información, consulte la Sección 43.7.4, “Guardando reglas IPTables”.

Sugerencia

Para utilizar los mismos comandos initscript para controlar el filtrado de la red para IPv6, sustituya ip6tables por iptables en los comandos /sbin/service listados en esta sección. Para más información sobre IPv6 y el filtrado de red (netfilter), consulte la Sección 43.7.6, “IPTables y IPv6”.

43.7.5.1. Archivo de configuración de scripts de control de IPTables

El comportamiento de los scripts de inicio de iptables es controlado por el archivo de configuración /etc/sysconfig/iptables-config. A continuación se presenta una lista de las directivas contenidas dentro de este archivo:

  • IPTABLES_MODULES — Especifica una lista separada por espacios de módulos iptables adicionales a cargar cuando se activa un cortafuegos. Esto puede incluir seguimiento de conexiones y ayudantes NAT.

  • IPTABLES_MODULES_UNLOAD — Descarga los módulos al iniciar o al detenerse. Esta directiva acepta los valores siguientes:

    • yes — El valor por defecto. Esta regla debe establecerse para alcanzar un estado correcto para reiniciar o detener un cortafuegos.

    • no — Esta opción solamente debería ser configurada si hay problemas al descargar los módulos de filtrado de paquetes de red.

  • IPTABLES_SAVE_ON_STOP — Guarda las reglas del cortafuegos actuales a /etc/sysconfig/iptables cuando se detiene el cortafuegos. Esta directiva acepta los valores siguientes:

    • yes — Guarda las reglas existentes a /etc/sysconfig/iptables cuando se detiene el cortafuegos, moviendo la versión anterior al archivo /etc/sysconfig/iptables.save.

    • no — El valor por defecto. No guarda las reglas existentes cuando se detiene el cortafuegos.

  • IPTABLES_SAVE_ON_RESTART — Guarda las reglas actuales del cortafuegos cuando este se reinicia. Esta directiva acepta los valores siguientes:

    • yes — Guarda las reglas existentes a /etc/sysconfig/iptables cuando se reinicia el cortafuegos, moviendo la versión anterior al archivo /etc/sysconfig/iptables.save.

    • no — El valor por defecto. No guarda las reglas existentes cuando se reinicia el cortafuegos.

  • IPTABLES_SAVE_COUNTER — Guarda y restaura todos los paquetes y contadores de bytes en todas las cadenas y reglas. Esta directiva acepta los valores siguientes:

    • yes — Guarda los valores del contador.

    • no — El valor por defecto. No guarda los valores del contador.

  • IPTABLES_STATUS_NUMERIC — Muestra direcciones IP en una salida de estado en vez de dominios y nombres de host. Esta directiva acepta los valores siguientes:

    • yes — El valor por defecto. Solamente devuelve direcciones IP dentro de una salida de estado.

    • no — Devuelve dominios o nombres de host en la salida de estado.

43.7.6. IPTables y IPv6

Si el paquete iptables-ipv6 es instalado, netfilter en Red Hat Enterprise Linux puede filtrar el protocolo de Internet IPv6. El comando utilizado para manipular los filtros de red IPv6 es ip6tables.

La mayoría de las directivas para este comando son idéntica a aquellas usadas por iptables, excepto que la tabla nat aún no es compatible. Esto significa que todavía no es posible realizar tareas de traducción de direcciones de red IPv6, tales como enmascarado y reenvío de puertos.

Las reglas guardadas para ip6tables son almacenadas en el archivo /etc/sysconfig/ip6tables. Las reglas viejas guardadas por los scripts de inicio de ip6tables son guardadas en el archivo /etc/sysconfig/ip6tables.save.

Las opciones de configuración para los script de inicio de ip6tables es /etc/sysconfig/ip6tables-config y los nombres para cada directriz varían ligeramente de sus contrapartes en iptables.

Por ejemplo, la directriz IPTABLES_MODULES en iptables-config es la equivalente a IP6TABLES_MODULES en el archivo ip6tables-config.

43.7.7. Recursos adicionales

Consulte las fuentes siguientes para obtener información adicional sobre filtrado de paquetes con iptables.

43.7.7.1. Documentación instalada

  • man iptables — Contiene una descripción de iptables así como también una lista detallada de objetivos, opciones y extensiones de coincidencia.

43.7.7.2. Sitios web útiles

  • http://www.netfilter.org/ — El sitio principal del proyecto de netfilter/iptables. Contiene información varia sobre iptables, incluyendo una sección FAQ detallando problemas específicos y varias guías de ayuda escritas por Rusty Russell, el mantenedor del cortafuegos IP de Linux. Los documentos HOWTO del sitio cubren aspectos tales como conceptos básicos de redes, filtrado de paquetes del kernel y configuraciones NAT.

  • http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — una visión básica y general sobre la forma cómo los paquetes se mueven dentro del kernel de Linux, además de una introducción sobre cómo se construyen comandos iptables simples.



[11] Debido a que los sistemas BIOS varían de acuerdo al fabricante, puede que algunos no soporten la protección con contraseñas de ningún tipo, mientras que otros pueden soportar un tipo pero no el otro.

[12] GRUB también acepta contraseñas no encriptadas, pero se recomienda que utilice un hash md5 para mayor seguridad.

[13] Este acceso está sujeto a las restricciones impuestas por SELinux, si éste está activado.

Capítulo 44. Seguridad y SELinux

44.1. Mecanismos de Control de Acceso (ACMs)

Esta sección proporciona una introducción básica a los Mecanismos de Control de Acceso (ACMs). Los ACMs proporcionan un medio para los administradores de sistemas para controlar que usuarios y que porcesos pueden acceder a diferentes archivos, disositivos, interfaces, etc, en un sistema de computador. Es una de las consideraciones principales al asegurar un sistema de computadores o una red de cualquier tamaño.

44.1.1. Control de Acceso Discrecional (DAC)

Control de Acceso Discrecional (DAC) edfine los controles de acceso básicos en un sistema de archivos. Este es el típico control de acceso que proporcionan los permisos de archivos, etc. Tal acceso se encentra generalmente a la discreción del dueño del objeto (archivo, directorio, dispositivo, etc).

DAC proporciona un medio para restringir el acceso a objetos con base en la identidad de los usuarios o de los grupos (sujetos) que tratan de acceder a esos objetos. Dependiendo de los permisos de acceso de un sujeto tambien es posible que puedan pasar permisos a otros sujetos.

44.1.2. Control de Acceso Mandatorio (MAC)

El Control de Acceso Mandatorio (MAC) es un mecanismo de seguridad que restringe el nivel de control que los usuarios (sujetos) tienen sobre otros objetos que crean. DE manera opuesta que en una implementación DAC, en donde los usuarios tienen control total sobre sus propios archivos, directorios, etc, MAC añade etiquetas adicionales o categorías a todos los objetos del sistema de archivos. Los usuarios y los procesos tienen que tener el acceso apropiado a estas categorias antes de que puedan interactuar con estos objetos.

En Red Hat Enterprise Linux, SELinux refuerza MAC. Para obtener mayor información, refiérase a Sección 44.2, “Introducción a SELinux”.

44.1.3. Control de Acceso basado en Roles (RBAC)

El Control de Acceso basado en Roles (RBAC) es un método alternativo de controlar el acceso de los usuarios a objetos del sistema de archivos. En vez de que los permisos de usuario controlen el acceso, el administrador del sistema establece Roles basados en requeriemeintos funcionales empresariales o un criterio similar. Estos Roles tienen diferentes tipos y distintos niveles de acceso a objetos.

En contraste con los sistemas DAC o MAC, en donde los usuarios tienen acceso a los objetos basados en su propios permisos y en los de los objetos, los usuarios en un sistema RBAC tienen que ser miembros del grupo o Rol apropiado antes de que puedan interactuar con archivos, directorios, dispositivos, etc.

Desde un punto de vista administrativo, esto hace mucho más fácil controlar quienes tienen acceso a varias partes del sistema de archivos con tan sólo controlar sus mermbresías a grupos.

44.1.4. Seguridad Multi-Nivel (MLS)

Multi-Level Seguridad Multi-Nivel (MLS) es un esquema de seguridad específico del Control de Acceso Mandatorio (MAC). Bajo este esquema los procesos se denominan Sujetos. Los archivos, enchufes y otras entidades pasivas del sistema operativo se llaman Objetos. Para obtener más información vaya a Sección 44.6, “Seguridad Multi-Nivel (MLS)”.

44.2. Introducción a SELinux

Security-Enhanced Linux (SELinux) es una arquitectura de seguridad integrada en el kernel 2.6.x utilizando los Módulos de seguridad de Linux (LSM). Es un proyecto de la agencia de seguridad de los Estados Unidos (NSA) y la comunidad SELinux. La integración de SELinux en Red Hat Enterprise Linux fue un esfuerzo conjunto entre NSA y Red Hat.

44.2.1. Sinopsis de SELinux

SELinux proporciona un sistema de Control de acceso obligatorio (MAC) construido en el kernel de Linux. Bajo el Control de acceso discrecional (DAC), de Linux una ejecución o proceso ejecutándose como un usuario (UID o SUID) tiene los permisos del usuario para objetos como archivos, sockets y otros procesos. Al ejecutar el kernel MAC se protege al sistema de aplicaciones malintencionadas o maliciosas que pueden dañar o destruir el sistema.

SELinux define los derechos de acceso y transmisión de cada usuario, aplicación, proceso y archivo en el sistema. SELinux gobierna luego la interacción de estas entidades mediante el uso de políticas de seguridad que especifican qué tan estricto debe ser una instalación de Red Hat Enterprise Linux.

Diariamente, los usuarios del sistema no son concientes de la presencia de SELinux. Sólo los administradores de sistemas necesitan considerar qué tan estricta debe ser la política implementada en los entornos de los servidores. Las políticas pueden ser tan estrictas o indulgentes como sea necesario. Las políticas son bastante detalladas, lo cual proporciona un control detallado y completo del kernel de SELinux sobre el sistema entero.

El proceso de toma de decisiones de SELinux

Cuando un sujeto, por ejemplo una aplicación, intenta acceder a un objeto, un archivo por ejemplo, el servidor de ejecución de políticas en el kernel revisa un caché de vector de acceso (AVC), en donde los permisos del sujeto y del objeto son guardados. Si no se puede tomar la decisión con los datos obtenidos en el AVC, la petición continúa al servidor de seguridad, el cual revisa el contexto de seguridad de la aplicación y el archivo en la matriz. El permiso es luego concedido o negado; en este último caso, se produce un mensaje de información avc: denied en /var/log/messages. El contexto de seguridad de sujetos y objetos es aplicado desde la política instalada. Éste también proporciona la información para llenar la matriz del servidor de seguridad.

Consulte el siguiente diagrama:

Proceso de decisión de SELinux

Proceso de decisión de SELinux.

Figura 44.1. Proceso de decisión de SELinux

Modos de operación de SELinux

En vez de ejecutarse en el modo obediente, SELinux puede ejecutarse en el modo permisivo, en donde el AVC es revisado y las negaciones son registradas sin que SELinux aplique la política. Esta propiedad es útil durante el periodo de soluciones de errores y para desarrollar o mejorar políticas de SELinux.

Para obtener mayor información acerca de cómo funciona SELinux, consulte Sección 44.2.3, “Recursos adicionales”.

44.2.2. Archivos relacionados con SELinux

Las siguientes secciones describen los archivos de configuración de SELinux y los sistemas de archivos relacionados.

44.2.2.1. El seudo sistema de archivos de SELinux

El seudo sistema de archivos /selinux/ contiene comandos que son utilizados por el subsistema del kernel. Esta clase de sistema de archivos es similar al seudo sistema de archivos /proc/.

Ni los administradores ni los usuarios necesitan normalmente manipular este componente.

El siguiente ejemplo muestra contenidos de ejemplo del directorio /selinux/:

-rw-rw-rw-  1 root root 0 Sep 22 13:14 access
dr-xr-xr-x  1 root root 0 Sep 22 13:14 booleans
--w-------  1 root root 0 Sep 22 13:14 commit_pending_bools
-rw-rw-rw-  1 root root 0 Sep 22 13:14 context
-rw-rw-rw-  1 root root 0 Sep 22 13:14 create
--w-------  1 root root 0 Sep 22 13:14 disable
-rw-r--r--  1 root root 0 Sep 22 13:14 enforce
-rw-------  1 root root 0 Sep 22 13:14 load
-r--r--r--  1 root root 0 Sep 22 13:14 mls
-r--r--r--  1 root root 0 Sep 22 13:14 policyvers
-rw-rw-rw-  1 root root 0 Sep 22 13:14 relabel
-rw-rw-rw-  1 root root 0 Sep 22 13:14 user

Por ejemplo, al ejecutar el comando cat en el archivo enforce revela 1 para el modo obediente o 0 para el modo permisivo.

44.2.2.2. Archivos de configuración de SELinux

Las siguientes secciones describen los archivos de políticas y configuración de SELinux y los sistemas de archivos relacionados ubicados en el directorio /etc/.

44.2.2.2.1. El archivo de configuración /etc/sysconfig/selinux

There are two ways to configure SELinux under Red Hat Enterprise Linux: using the SELinux Administration Tool (system-config-selinux), or manually editing the configuration file (/etc/sysconfig/selinux).

El archivo /etc/sysconfig/selinux es el archivo de configuración principal para activar o desactivar SELinux. También permite establecer la política a cumplir y la forma en que ésta debe ser seguida.

Nota

El archivo /etc/sysconfig/selinux es un enlace simbólico al archivo de configuración /etc/selinux/config.

A continuación se muestran los grupos de opciones disponibles para la configuración:

  • SELINUX=enforcing|permissive|disabled — Define el estado principal de SELinux en un sistema.

    • enforcing (obediente) — La política de seguridad de SELinux entra en vigor.

    • permissive (permisiva) — El sistema SELinux crea advertencias pero no aplica la política.

      Esta opción es útil durante la depuración y solución de errores. En el modo permisivo, muchas más negaciones son registradas ya que los sujetos pueden continuar con las acciones que de otra forma serían negadas en el modo obediente. Por ejemplo, al explorar el árbol de un directorio en modo permisivo crearía mensajes avc: denied por cada nivel del directorio que sea leído. En modo obediente, SELinux detendría la exploración inicial evitando así la ocurrencia de más mensajes de negación.

    • disabled (deshabilitado) — SELinux es completamente desactivado. Los enlaces de SELinux son desprendidos del kernel y se borra el registro del seudo sistema de archivos.

      Sugerencia

      Las acciones que son ejecutadas mientras SELinux está desactivado pueden resultar en la perdida de los contextos de seguridad correctos del sistema de archivos. En otras palabras, la pérdida de los contextos de seguridad definidos por la política. La manera más adecuada de recuperar los contextos es creando el archivo ./autorelabel y reiniciando la máquina. Esto hace que la etiquetas sean creadas durante las primeras etapas del proceso de arranque, antes de que cualquier servicio este siendo ejecutado en el sistema. Al usar este procedimiento se asegura que ningún proceso cree accidentalmente archivos con un contexto erróneo o sean iniciados en un contexto erróneo.

      Es posible utilizar el comando fixfiles relabel antes de activar SELinux para etiquetar el sistema de archivos. Este método no es recomendado porque es posible que algunos procesos permanezcan en ejecución dentro del contexto erróneo después de que el comando ha etiquetado el sistema de archivos. Estos procesos podrían crean archivos que también estarían en un contexto erróneo.

    Nota

    Espacios en blanco adicionales al final de las líneas de configuración o como líneas extras al final del archivo pueden causar comportamientos inesperados. Por seguridad, remueva los espacios en blanco que no sean necesarios.

  • SELINUXTYPE=targeted|strict — Especifica la política que debe ser aplicada por SELinux.

    • targeted — Sólo se protegen los demonios de red objetivos.

      Importante

      Los siguientes demonios están protegidos en la política de objetivos predeterminada: dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid y syslogd. El resto del sistema se ejecuta en el dominio unconfined_t. Este dominio le permite a los sujetos y objetos con este contexto de seguridad operar utilizando la seguridad estándar de Linux.

      Los archivos de políticas para esos demonios están en /etc/selinux/targeted/src/policy/domain/program. Estos archivos están sujetos a cambios en las nuevas versiones de Red Hat Enterprise Linux.

      Policy enforcement for these daemons can be turned on or off, using Boolean values controlled by the SELinux Administration Tool (system-config-selinux).

      Al establecer el valor booleano para el dominio objetivo a o (cero) se desactiva la transición de políticas para ese demonio. Por ejemplo, puede establecer dhcpd_disable_trans a 0 para que init no haga la transición de dhcpd del dominio unconfined_t al dominio especificado en dhcpd.te.

      Utilice el comando getsebool -a para listar todos los valores booleanos de SELinux. El siguiente es un ejemplo de uso del comando setsebool para establecer un booleano de SELinux. La opción -P hace que el cambio sea permanente. Si esta opción no se especifica, el valor booleano regresará a 1 durante el inicio del sistema.

      setsebool -P dhcpd_disable_trans=0
      
    • strict — Protección completa de SELinux para todos los demonios. Los contextos de seguridad para todos los sujetos y objetos son definidos. Cada acción es procesada por el servidor de ejecución de políticas.

  • SETLOCALDEFS=0|1 — Controla cómo se debe establecer las definiciones locales (usuarios y booleanos). Establezca este valor a 1 para que las definiciones sean controladas por load_policy desde los archivos en /etc/selinux/<nombrepolítica>. O establezca el valor a 0 para que sean controlados por semanage.

    Precaución

    Usted no debe cambiar esta valor (0) a menos que sepa con toda certeza el impacto que dicho cambio conlleva.

44.2.2.2.2. El directorio /etc/selinux/

El directorio /etc/selinux/ es la ubicación predeterminada para todos los archivos de políticas así como para el principal archivo de configuración.

El siguiente ejemplo muestra contenidos de ejemplo del directorio /etc/selinux/:

-rw-r--r--  1 root root  448 Sep 22 17:34 config
drwxr-xr-x  5 root root 4096 Sep 22 17:27 strict
drwxr-xr-x  5 root root 4096 Sep 22 17:28 targeted

Los dos subdirectorios, strict/ y targeted/, son los directorios específicos donde los archivos de políticas del mismo nombre (strict y targeted) se encuentran.

44.2.2.3. Utilidades SELinux

Las siguientes son las utilidades de SELinux más comúnmente usadas:

  • /usr/sbin/setenforce — Modifica en tiempo real el modo en que — se ejecuta.

    Por ejemplo:

    setenforce 1 — SELinux se ejecuta en modo obediente (enforce).

    setenforce 0 — SELinux se ejecuta en modo permisivo.

    Para desactivar SELinux, necesitará especificar el parámetro setenforce apropiado en /etc/sysconfig/selinux o pasar el parámetro selinux=0 al kernel, ya sea en /etc/grub.conf o durante el tiempo de inicio.

  • /usr/sbin/sestatus -v — Muestra en detalle el estado de un sistema que está ejecutando SELinux. El siguiente ejemplo muestra un extracto de la salida de sestatus -v.

    SELinux status:                 enabled
    SELinuxfs mount:                /selinux
    Current mode:                   enforcing
    Mode from config file:          enforcing
    Policy version:                 21
    Policy from config file:        targeted
    
    Process contexts:
    Current context:                user_u:system_r:unconfined_t:s0
    Init context:                   system_u:system_r:init_t:s0
    /sbin/mingetty                  system_u:system_r:getty_t:s0
    
  • /usr/bin/newrole — Ejecuta una nueva shell en un nuevo contexto o rol. La política debe permitir la transición al nuevo rol.

    Nota

    Este comando sólo estará disponible si tiene el paquete policycoreutils-newrole instalado. Esta paquete es requerido por las políticas strict y MLS.

  • /sbin/restorecon — Establece el contexto de seguridad de uno o más archivos marcando los atributos extendidos con el archivo o el contexto de seguridad apropiado.

  • /sbin/fixfiles — Revisa o corrige la base de datos de contextos de seguridad en el sistema de archivos.

Consulte las páginas man relacionadas con estas utilidades para obtener mayor información.

Consulte el contenido de los paquetes setools o policycoreutils para obtener mayor información sobre las utilidades binarias disponibles. Para ver el contenido de un paquete, utilice el siguiente comando:

rpm -ql <nombre-paquete>

44.2.3. Recursos adicionales

Consulte los siguientes recursos para obtener mayor información sobre SELinux.

44.2.3.1. Documentación instalada

  • /usr/share/doc/setools-<número-versión>/ Toda la documentación de las utilidades contenidas en el paquete setools. Entre éstos se encuentran los script de ayuda, ejemplos de archivos de configuración y la documentación.

44.2.3.2. Sitios web de interés

  • http://www.nsa.gov/selinux/ Página principal del equipo de desarrollo de SELinux NSA. Muchos de los recursos están disponibles en HTML y PDF. Aunque muchos de los enlaces no son específicos de SELinux, algunos de los conceptos son aplicables.

  • http://fedora.redhat.com/docs/ Página principal del proyecto de documentación de Fedora que contiene material específico a Fedora Core. Ésta documentación puede llegar a ser más actual ya que el ciclo de lanzamiento es más corto.

  • http://selinux.sourceforge.net Página principal de la comunidad SELinux.

44.3. Antecedentes e historia de SELinux

SELinux fue originalmente un proyecto desarrollado por la agencia nacional de seguridad (NSA ) [14] y otros. Es una implementación de la arquitectura de seguridad del sistema operativo Flask . [15] El NSA integró SELinux en el kernel de Linux utilizando el framework Linux Security Modules (LSM ). SELinux motivó la creación de LSM, bajo la sugerencia de Linus Torvalds, quien buscaba un acercamiento más modular a la seguridad, en vez de sólo aceptar SELinux en el kernel

Originalmente, la implementación SELinux usaba IDs de seguridad persistentes (PSIDs) almacenados en un campo sin uso en los inodos de ext2. Esta representación numérica (i.e., no legible por humanos) eran analizadas por SELinux a una etiqueta de contexto de seguridad. Desafortunadamente, esto requería la modificación de cada sistema de archivos para soportar PSID, convirtiéndose así en una solución no escalable o soportada en el desarrollo principal del kernel de Linux.

La siguiente evolución de SELinux fue como un módulo cargable del kernel para los kernel de Linux de la serie 2.4.<x>. Este módulo guardaba los PSID en un archivo normal haciendo que SELinux fuera capaz de soportar más sistemas de archivos. Esta solución no era la más adecuada en relación con rendimiento y era inconsistente a lo largo de diferentes plataformas. Finalmente, el código de SELinux fue integrado al desarrollo principal del kernel 2.6.x, el cual tiene completo soporte para LSM y tiene atributos extendidos (xattrs ) en el sistema de archivos ext3. SELinux fue movido para utilizar xattrs para almacenar la información de los contextos de seguridad. Los espacios de nombres de xattr proporcionaron una separación útil para múltiples módulos de seguridad existentes en el mismo sistema.

Gran parte del esfuerzo requerido para tener el kernel listo para el desarrollo principal, así como desarrollos subsecuentes de SELinux, ha sido llevado a cabo por NSA, Red Hat y la comunidad de desarrolladores de SELinux.

Para obtener mayor información sobre la historia de SELinux, el sitio web se encuentra en http://www.nsa.gov/selinux/.

44.4. Multi-Category Security (MCS)

44.4.1. Introducción

Multi-Category Security (MCS) es una mejora de SELinux y permite a los usuarios etiquetar archivos con categorías. EStas categorías se utilizan para restringir aún más el Control de Acceso Discrecional (DAC) y la lógica de Tipo de Refuerzo (TE). También se pueden utilizar cuando se presentan o se imprimen archivos. Un ejemplo de una categoría es "Confidencial". Sólamente los usuarios con acceso a esta categoría pueden acceder los rachivos etiquetados con la categoría asumiendo que las reglas DAC yu TE ya existentes también lo permiten.

El término categorias se refiere a las mismas categorías no-jerárquicas utilizadas por Multi-Level Security, seguridad a multi-nilvel, (MLS). Bajo MLS, los objetos y los sujetos son etiquetados con Niveles de Seguridad. Estos Niveles de Seguridad consisten de un valor sensible a jerarquias (tal como "Top Secret" y cero o más categorías no-jerárquicas (tal como "Crypto"). Las categorías proprocionan compartimientos dentro de niveles de sensibilidad y refuerzan la necesidad de cponocer los principios de seguridad. Refiérase a Sección 44.6, “Seguridad Multi-Nivel (MLS)” para obtener más información sobre Seguridad a Multi-Nivel.

44.4.1.1. ¿Qué es la Seguridad Multi-Categoría?

MCS es una adaptación de MLS. Desde un punto de vista técnico, MCS es un cambio de política combinado con unas pocas modificaciones para esconder algo de la tecnología MLS innecesaria. También se hicieron algunos cambios al kernel pero sólo con relación a hacerlo más fácil de actualizar a MCS (o MLS) sin invocar un re-etiquetamiento de todo el sistema de archivos.

La esperanza es mejorar la calidad del sistema completo, reducir costos, tomar ventaja del proceso de código abierto, incrementar la transparencia y hacer que la base de la tecnología sea más útil que sólo para un pequeño grupo de usuarios en casos especiales.

44.4.2. Aplicaciones para Seguridad Multi-Categoría

Más allá del control de acceso MCS también se puede utilizar para presentar las categorias MCS en la parte superior e inferior de las páginas impresas. Esto también puede incluir una carat de presentación para indicar los procedimientos de manejo de documentos. También debe ser posible MCS con desarrollos futuros en SELinux tal como Mejora de Seguridad X. La integración con un servidor del directorio también hará que el soporte para el correo electrónico sea más fácil. Esto podría involucrar los uaurios etiquetando de manera manual los correos electrónicos salientes o adjuntando archivos etiquetados apropiadamente. Después el cliente del correo electrónico puede determinar si los recipientes pueden acceder las categorías asociadas con los correos electrónicos.

44.4.3. Contextos de Seguridad de SELinux

SELinux almacena contextos de seguridad como un atributo extendido de un archivo. El nombre de espacio "security." se utiliza para módulos de seguridad y el nombre security.selinux se utiliza para almacenar persitentemente las etiquetas de seguridad de SELinux en archivos. El contenido de este atributo varía dependiendo del archivo o directorio que inspeccione y la política que la máquina esté reforzando.

Nota

SE espera que esto cambie en el kernel 2.6.15 (y ya lo hizo en los últimos kernels -mm) para que getxattr(2) siempre devuelva la versión canonizada de la etiqueta del kernel.

Puede utilizar el comando ls -Z para ver la etiqueta de la categoría de un archivo:

[root@myServer ~]# ls -Z gravityControl.txt
-rw-r--r--  user     user     user_u:object_r:tmp_t:Moonbase_Plans gravityControl.txt

Puede utilizar el comando gefattr(1) para ver el valor de la categoría interna (c10):

[root@myServer ~]# getfattr -n security.selinux gravityControl.txt
# file: gravityControl.txt
security.selinux="user_u:object_r:tmp_t:s0:c10\000"

Consulte Sección 44.5, “Getting Started with Multi-Category Security (MCS)” para obtener más detalles sobre como crear categorías y asignarlas a archivos.

44.5. Getting Started with Multi-Category Security (MCS)

This section provides an introduction to using MCS labels to extend the Mandatory Access Control (MAC) capabilities of SELinux. It discusses MCS categories, SELinux user identities, and how they apply to Linux user accounts and files. It builds on the conceptual information provided in Sección 44.4, “Multi-Category Security (MCS)”, and introduces some basic examples of usage.

44.5.1. Introduction

MCS labeling from a user and system administrator standpoint is straightforward. It consists of configuring a set of categories, which are simply text labels, such as "Company_Confidential" or "Medical_Records", and then assigning users to those categories. The system administrator first configures the categories, then assigns users to them as required. The users can then use the labels as they see fit.

The names of the categories and their meanings are set by the system administrator, and can be set to whatever is required for the specific deployment. A system in a home environment may have only one category of "Private", and be configured so that only trusted local users are assigned to this category.

In a corporate environment, categories could be used to identify documents confidential to specific departments. Categories could be established for "Finance", "Payroll", "Marketing", and "Personnel". Only users assigned to those categories can access resources labeled with the same category.

After users have been assigned to categories, they can label any of their own files with any of the categories to which they have been assigned. For example, a home user in the system described above could label all of their personal files as "Private", and no service such as Apache or vsftp would ever be able to access those files, because they don't have access to the "Private" category.

MCS works on a simple principle: to access a file, a user needs to be assigned to all of the categories with which the file is labeled. The MCS check is applied after normal Linux Discretionary Access Control (DAC) and Type Enforcement (TE) rules, so it can only further restrict security.

44.5.2. Comparing SELinux and Standard Linux User Identities

SELinux maintains its own user identity for processes, separately from Linux user identities. In the targeted policy (the default for Red Hat Enterprise Linux), only a minimal number of SELinux user identities exist:

  • system_u — System processes

  • root — System administrator

  • user_u — All login users

Use the semanage user -l command to list SELinux users:

[root@dhcp-133 ~]# semanage user -l
                             Labeling    MLS/                 MLS/
SELinux User        Prefix        MCS Level        MCS Range        SELinux Roles
root                      user           s0                      s0-s0:c0.c1023    system_r sysadm_r user_r
system_u              user           s0                      s0-s0:c0.c1023    system_r
user_u                  user           s0                      s0-s0:c0.c1023    system_r sysadm_r user_r

Refer to Sección 44.8.3, “Usuarios y Roles en la Política Objetivo” for more information about SELinux users and roles.

SELinux Logins

One of the properties of targeted policy is that login users all run in the same security context. From a TE point of view, in targeted policy, they are security-equivalent. To effectivly use MCS, however, we need to be able to assign different sets of categories to different Linux users, even though they are all the same SELinux user (user_u). This is solved by introducing the concept of an SELinux login. This is used during the login process to assign MCS categories to Linux users when their shell is launched.

Use the semanage login -a command to assign Linux users to SELinux user identities:

# semanage login -a james
# semanage login -a daniel
# semanage login -a olga

Now when you list the SELinux users, you can see the Linux users assigned to a specific SELinux user identity:

# semanage login -l
Login Name                SELinux User              MLS/MCS Range
__default__               user_u                         s0
james                         user_u                         s0                       
daniel                         user_u                         s0                       
root                           root                             SystemLow-SystemHigh
olga                            user_u                         s0

Notice that at this stage only the root account is assigned to any categories. By default, the root account is configured with access to all categories.

Red Hat Enterprise Linux and SELinux are preconfigured with several default categories, but to make effective use of MCS, the system administrator typically modifies these or creates further categories to suit local requirements.

44.5.3. Configuring Categories

SELinux maintains a mapping between internal sensitivity and category levels and their human-readable representations in the setrans.conf file. The system administrator edits this file to manage and maintain the required categories.

Use the chcat -L command to list the current categories:

[root@dhcp-133 tmp]# chcat -L
s0:c0                          CompanyConfidential
s0:c3                          TopSecret
s0
s0-s0:c0.c255             SystemLow-SystemHigh
s0:c0.c255                  SystemHigh

To modify the categories or to start creating your own, modify the /etc/selinux/<selinuxtype>/setrans.conf file. For the example introduced above, add the Marketing, Finance, Payroll, and Personnel categories as follows (this example uses the targeted policy, and irrelevant sections of the file have been omitted):

[root@dhcp-133 tmp]# vi /etc/selinux/targeted/setrans.conf
s0:c0=Marketing
s0:c1=Finance
s0:c2=Payroll
s0:c3=Personnel

Use the chcat -L command to check the newly-added categories:

[root@dhcp-133 tmp]# chcat -L
s0:c0                          Marketing
s0:c1                          Finance
s0:c2                          Payroll
s0:c3                          Personnel
s0
s0-s0:c0.c255            SystemLow-SystemHigh
s0:c0.c255                 SystemHigh

Note

After you make any changes to the setrans.conf file, you need to restart the MCS translation service before those changes take effect. Use the following command to restart the service:

[root@dhcp-133 ~]# service mcstrans restart

44.5.4. Assigning Categories to Users

Now that the required categories have been added to the system, you can start assigning them to SELinux users and files. To further develop the example above, assume that James is in the Marketing department, Daniel is in the Finance and Payroll departments, and Olga is in the Personnel department. Each of these users has already been assigned an SELinux login.

Use the chcat command to assign MCS categories to SELinux logins:

[root@dhcp-133 ~]# chcat -l -- +Marketing james
[root@dhcp-133 ~]# chcat -l -- +Finance,+Payroll daniel
[root@dhcp-133 ~]# chcat -l -- +Personnel olga

You can also use the chcat command with additional command-line arguments to list the categories that are assigned to users:

[root@dhcp-133 ~]# chcat -L -l daniel james olga
daniel: Finance,Payroll
james: Marketing
olga: Personnel

You can add further Linux users, assign them to SELinux user identities and then assign categories to them as required. For example, if the company director also requires a user account with access to all categories, follow the same procedure as above:

# Create a user account for the company director (Karl)
[root@dhcp-133 ~]# useradd karl
[root@dhcp-133 ~]# passwd karl
Changing password for user karl.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

# Assign the user account to an SELinux login
[root@dhcp-133 ~]# semanage login -a karl

# Assign all the MCS categories to the new login
[root@dhcp-133 ~]# chcat -l -- +Marketing,+Finance,+Payroll,+Personnel karl

Use the chcat command to verify the addition of the new user:

[root@dhcp-133 ~]# chcat -L -l daniel james olga karl
daniel: Finance,Payroll
james: Marketing
olga: Personnel
karl: Marketing,Finance,Payroll,Personnel

Note

MCS category access is assigned during login. Consequently, a user does not have access to newly-assigned categories until they log in again. Similarly, if access to a category is revoked, this is only apparent to the user after the next login.

44.5.5. Assigning Categories to Files

At this point we have a system that has several user accounts, each of which is mapped to an SELinux user identity. We have also established a number of categories that are suitable for the particular deployment, and assigned those categories to different users.

All of the files on the system, however, still fall under the same category, and are therefore accessible by everyone (but still according to the standard Linux DAC and TE constraints). We now need to assign categories to the various files on the system so that only the appropriate users can access them.

For this example, we create a file in Daniel's home directory:

[daniel@dhcp-133 ~]$ echo "Financial Records 2006" > financeRecords.txt

Use the ls -Z command to check the initial security context of the file:

[daniel@dhcp-133 ~]$ ls -Z financeRecords.txt
-rw-r--r--  daniel daniel user_u:object_r:user_home_t      financeRecords.txt

Notice that at this stage the file has the default context for a file created in the user's home directory (user_home_t) and has no categories assigned to it. We can add the required category using the chcat command. Now when you check the security context of the file, you can see the category has been applied.

[daniel@dhcp-133 ~]$ chcat -- +Finance financeRecords.txt
[daniel@dhcp-133 ~]$ ls -Z financeRecords.txt
-rw-r--r--  daniel daniel root:object_r:user_home_t:Finance financeRecords.txt

In many cases, you need to assign more than one category to a file. For example, some files may need to be accessible to users from both the Finance and Payroll departments.

[daniel@dhcp-133 ~]$ chcat -- +Payroll financeRecords.txt
[daniel@dhcp-133 ~]$ ls -Z financeRecords.txt
-rw-r--r--  daniel daniel root:object_r:user_home_t:Finance,Payroll financeRecords.txt

Each of the categories that have been assigned to the file are displayed in the security context. You can add and delete categories to files as required. Only users assigned to those categories can access that file, assuming that Linux DAC and TE permissions would already allow the access.

If a user who is assigned to a different category tries to access the file, they receive an error message:

[olga@dhcp-133 ~]$ cat financeRecords.txt
cat: financeRecords.txt: Permission Denied

Note

Refer to the man pages for semanage and chcat for more information on the available options for these commands.

44.6. Seguridad Multi-Nivel (MLS)

Un aspecto vital para muchas empresas es la protección de datos confidenciales y delicados. En el evento de que tal información senhaga pública, las empresas pueden llegar a enfrentar consecuencias legales o financieras. Por lo menos sufrirán la pérdida de la confianza de los clientes. En la mayoría de los casos, se puede recuperar de las pérdidas a nivel financiero y d eotras con una inversión o una compensación apropiada.

No se puede decir lo mismo de las comunidades de defensa y las relacionadas, las cuales incluyen los servicios militares, organizaciones de inteligencia y algunas áreas del servicio policial. EStas organizaciones no se pueden recuperar si se presenta una fuga de información importante y puede que no se lleguen a recuperar del todo. Estas comunidades requiereen niveles de seguridad más latos que aquellos empleados por las compañias y otras organizaciones.

El tener información de diferentes niveles de seguridad en el mismo sistema implica una amenaza real. No es fácil aislar diferentes niveles de seguridad de información aunque los diferentes usuarios inician sesión urtilizando diferentes cuentas con permisos diferentes y controles de acceso diferentes.

Algunas organizaciones incluso llegan a comprar sistemas especiales para cada nivel de seguridad; sin embargo, con frecuencia esto es excesivamente costoso. Se requiere un mecanismo para habilitar a los usuarios en diferentes niveles de seguridad para acceder sistemas de manera simultánea sin el temor de sufrir contaminación de la información.

44.6.1. ¿Por qué Multi-Nivel?

El término multi-nivel surge de las clasificaciones de seguridad de la comunidad: Confidencial, Reservado y Secreto.

Se les debe otorgar a los individuos las autorizaciones apropiadas antes de que puedan ver información clasificada. Aquellos con autorización confidencial sólamente tienen autorización para ver documentos confidenciales y no se les permite ver información secreta o reservada. Las reglas que aplican al flujo de datos operan desde los niveles más bajos a los más latos y nunca de manera inversa. Esto se encuentra ilustrado a continuación:

Niveles de Seguridad de la Información

Jerarquía de los Niveles de Seguridad de la Información. Las flechas indican la dirección en que las reglas permites el flujo de datos.

Figura 44.2. Niveles de Seguridad de la Información

44.6.1.1. El Modelo Bell-La Padula (BLP)

SELinux como la mayoría de los otros sistemas que protegen datos a multi-nivel, utiliza el modelo BLP. Este modelo especifica el como debe fluir la información dentro del sistema con base en las etiquetas de cada sujeto u objeto. Refiérase al siguiente diagrama:

Flujos de datos disponibles utilizando un sistema MLS

Los procesos pueden leer niveles de seguridad iguales o más bajos, pero sólo pueden escribir en los niveles de seguridad propios o más altos.

Figura 44.3. Flujos de datos disponibles utilizando un sistema MLS

Bajo tal sistema, los usuarios, computadores y redes utilizan etiquetas que indican los niveles de seguridad. Los datos pueden fluir entre niveles similares como por ejemplo entre "Secreto" y "Secreto" o desde un nivel más bajo a uno más alto. Esto significa que los usuarios en el nivel "Secreto" pueden compartir los unos con los otros y también pueden recuperar información de usuarios en el nivel confidencial (por ejemplo, un nivel más bajo). Sin embargo, los datos no pueden fluir desde un nivel más alto a un nivel más bajo. Esto evita que los procesos en el nivel "Secreto" vena la información clasificada como "Reservada". También evita que los procesos en un nivel más alto escriban accidentalmente información en nivele más bajos. Esto se conoce como el modelo "lectura-no-ascendente, escritura-no-descendente"

44.6.1.2. MLS y Privilegios del Sistema

Las reglas de acceso MLS siempre se combinan con permisos de acceso convencionales (permisos de archivos). Por ejemplo, si un usuario con un nivel de seguridad "Secreto" utiliza el Control de Acceso Discrecional (DAC) para bloquear el acceso de otros usuarios a un archivo, esto también bloquea el acceso de usuarios con un nivle de seguridad "Reservado". UNa autorización de seguridad no da permisos automáticamente para mirar un sistema de archivos de maner arbitraria.

Los usuarios con autorizaciones de nivel superior no adquieren automáticamente derechos administrativos en sistemas multi-nivel. Aunque pueden acceder a toda la información en el computador, esto es diferente a tener derechos administrativos.

44.6.2. Niveles de Seguridad, Objetos y Sujetos

Como se discutió anteriormente, los sujetos y los objetos tienen etiquetas con Niveles de Seguridad (NS), los cuales se componen de dos tipos de entidades:

  1. Sensitivity: — Un atributo jerárquico así como "Secreto" o "Reservado".

  2. Categories: — Un grupo de atributos no jerárquicos así como "US Only" o "UFO".

Un NS debe tener una sensibilidad y debe tener cero o más categorias.

Ejemplos de NS son: { Secret / UFO, Crypto }, { Top Secret / UFO, Crypto, Stargate } Y { Unclassified }

Observe la sensibilidad jerárquica seguido por cero o más categorías. La razón para tener categorias así como sensibilidades es para que las sensibilidades puedan ser encasilladas aún más con base en lo que necesita saber. Por ejemplo, mientras que un proceso puede ser autorizado a un nivel de seguridad "Secreto", puede que no necesite ningún tipo de acceso al proyecto "Warp Drive" (el cual puede ser el nombre de una categoría).

Nota

  1. Los niveles de Seguridad en objetos son llamados Clasificaciones.

  2. Los niveles de Seguridad en sujetos son llamados Autorizaciones.

Por lo cual los objetos son etiquetados con una Clasificación, mientras que los objetos operan con una Autorización específica. Los niveles de seguridad también pueden tener Rangos, pero estos van más alla de lo que discute esta introducción.

44.6.3. Política MLS

SELinux utiliza el modelo Bell-La PadulaBLP con Refuerzo de Tipo (TE) para mantener la integridad. En términos simples, la política MLS asegura que un Sujeto tenga una autorización apropiada para acceder un Objeto de una clasificación en particular.

Por ejemplo, bajo MLS, el sistema necesita saber como procesar una petición como: ¿Un proceso ejecutando con una autorización { Top Secret / UFO, Rail gun } puede escribir en un archivo clasificado como { Top Secret / UFO } ?

El modelo MLS y la política implementada para esta determinará la respuesta (por ejemplo, considere una fuga de información de la categoría Rail gun al archivo).

MLS cumple con un grupo de requerimientos de seguridad muy limitado (aunque crítico) con base en la manera en que se administra la información y el personal en entornos controlados de manera rígida así como el ejército. Típicamente es dificil trabajar con MLS y no se relaciona bien con casos generales.

El Tipo de Refuerzo (TE) bajo SELinux es un esquema de seguridad más flexible y expresivo , el cual en muchos casos es más apropiado que MLS.

Sin embargo, hay varios escenarios en donde aún se necesita el tradicional MLS. Por ejemplo, un servidor de archivos en donde los datos almacenados tengan clasificaciones diferentes y en donde los clientes se conectan con diferentes autorizaciones. Esto crea un gran número de Niveles de Seguridad y la necesidad de implementar un aislamiento fuerte en un sistema individual.

El tipo de escenario es la razón por la cual SELinux incluye MLS como un modelo de seguridad adjunto a TE.

44.6.4. Certificación LSPP

Se están realizando grandes esfuerzos para certificar Linux como un sistema operativo MLS. La certificación es equivalente a la antigua clasificación B1ç, la cual ha sido modificada a Perfil de Protección de Seguridad Etiquetada bajo el esquema Criterios Comúnes

44.7. Sinopsis de las Políticas de SELinux

Este capítulo es una sinopsis de la política de SELinux, algunas de sus características internas y como trabaja. Discute la política en términos generales mientras que Sección 44.8, “Sinopsis de la Política de Objetivos” se enfoca en los detalles de la política objetivo tal como viene en Red Hat Enterprise Linux. Este capítulo inicia con una breve sinopsis de lo que se define como una política y en donde se encuentra.

A continuación se discutirá el papel de SELinux durante el proceso de arranque seguido por discusiones sobre contextos de seguridad de archivos, clases de objetos y permisos, atributos, tipos, vectores de acceso, macros, usuarios y roles, restricciones y un pequeño resumen sobre las interfaces especiales del kernel.

44.7.1. ¿Qué es la Política SELinux?

La Política SELinux es un grupo de reglas que guian la máquina de seguridad SELinux Define tipos para objetos de archivos y dominios para procesos. Utiliza roles para limitar los dominios a donde se puede entrar y tiene identidades de usuario para especificar los roles que se pueden obtener. Básicamente los tipos y dominios son equivalentes, la diferencia radica en que los tipos aplican a los objetos mientras que los dominios aplican a los procesos.

44.7.1.1. Tipos de SELinux

Un tipo es una manera de agrpas ítems con base en sus similaridades desde la perspectiva de seguridad. Esto no se relaciona necesariamente al propósito único de una aplicación o el contenido de un documento. Por ejemplo, un archivo puede tener cualquier tipo de contenido y tener cualquier propósito pero si pertenece a un usuario y existe en el directorio de inicio del usuario se considera como un tipo de seguraidad especifico, user_home_t.

Estos tipos de objetos se consideran similares ya que son accesibles de la misma manera por el mismo grupo de sujetos. De manera similar los procesos tienden a ser del mismo tipo si tienen los mismos permisos que los otros sujetos. En la política objetivo los progarmas que ejecutan en el dominio unconfined_t tiene un archivo ejecutable con un tipo como sbin_t. Desde una perspectiva SELinux, estos significa que todos son equivalentes en términos de lo que pueden hacer y lo que no en el sistema.

Por ejemplo, el objeto del archivo ejecutable binario en /usr/bin/postgres tiene el tipo postgresql_exec_t. Todos los demonios objetivos tienen su propio tipo *_exec_t para sus aplicaciones ejecutables. De hecho, el grupo entero de ejecutables PostgreSQL tales como createlang, pg_dump y pg_restore cuentan con el mismo tipo, postgresql_exec_t y regresan al mismo dominio, postgresql_t, bajo ejecución.

44.7.1.1.1. Utilización de Reglas de Politicas para Definir Tipo de Acceso

La política SELinux define varias reglas las cuales determinan la manera en que cada dominio pueda acceder cada tipo. Sólo lo que permiten las reglas es admitido. Por defecto, cada operación es rechazada y auditada lo cual significa que inicia sesión en el archivo $AUDIT_LOG. En Red Hat Enterprise Linux se encuentra configurado a /var/log/messages. La política es compilada en un formato binario para cargar en el servidor de seguridad del kernel y cada vez que el servidor de seguridad tome una decisión se realiza un caché en el AVC para optimizar el rendimiento.

La política puede ser definida modificando los archivos existentes o añadiendo archivos de Tipo de Reforzamiento (TE por sus siglas en inglés) local y Contexto de Archivos(FC por sus siglas en inglés) al árbol de políticas. Estas nuevas políticas se pueden cargar en el kernel en tiempo real. De otra manera, init carga la política durante el proceso de arranque, como se explicó en Sección 44.7.3, “El Papel de la Política durante el Proceso de Arranque”. Al final cada operación del sistema es determinada por la política y el tipo de etiquetas de los archivos.

Importante

Después de cargar la nueva política se recomienda que reinicie cualquier servicio que tenga una etiqueta nueva o cambiada. En general, esto es sólamente los demonios objetivos como se enumera en Sección 44.8.1, “¿Qué es la Política Objetivo?”.

44.7.1.2. Control de Acceso Obligatorio y SELinux

SELinux es una implementación de Control de Acceso Obligatorio(MAC). Dependiendo del tipo de política de seguridad SELinux implementa ya sea Tipo de Reforzamiento (TE), Control de Acceso en Base a Roles (RBAC) o Seguridad Multinivel Modelo Bell-La Padula (MLS).

La política especifica las reglas en el entorno implementado. Está escrito en un lenguaje creado específicamente para escribir políticas de seguridad. Escritores de políticas utilizan el macros m4 para capturar grupos comunes de reglas de bajo nivel. Un número de macros m4 se definen en la política existente, la cual facilita la escritura de la nueva política. Estas reglas son preprocesadas en muchas reglas adicionales como parte de la construcción del archivo policy.conf, el cual es compilado en la política binaria.

Los derechos de acceso se encuentran divididos de manera diferente entre dominios y no se necesita que ningún dominio actúe como dominio maestro para los otros dominios. La política controla el movimiento entre dominios por medio de programas de nombre de usuario, espacio de ususario como newrole o exigiendo una nueva ejecución del proceso en el nuevo dominio. Este movimeinto entre dominios se conoce como transición .

44.7.2. ¿Dónde se encuentra la Política?

La política tiene dos componentes: el árbol binario y el árbol fuente. El paquete política-selinux<nombre-de-la-política> proporciona el árbol binario y suministra el archivo de políticas binarias.

Opcionalmente, la política binaria se puede contruir desde la fuente cuando se instala el paquete selinux-policy-devel.

Nota

La información sobre como editar, escribir y compilar políticas se encuentra fuera del alcance de este documento.

44.7.2.1. Archivos de Arboles Binarios

  • /etc/selinux/targeted/ — este es el directorio root para la política objetivo y contiene el árbol binario.

  • /etc/selinux/targeted/policy/ — esta es la ubicación del archivo de políticas binarias policy.<xx>. En este manual, se utiliza la variable SELINUX_POLICY para este directorio.

  • /etc/selinux/targeted/contexts/ — esta es la ubicación de los archivos de configuración e información sobre el contexto de seguridad, los cuales son utilizados por varias aplicaciones durante el tiempo de ejecución.

  • /etc/selinux/targeted/contexts/files/ — contiene los contextos predeterminados para tod el sistema de archivos. Esto es referecniado por restorecon cuando se realizan operaciones de re-etiquetamiento.

  • /etc/selinux/targeted/contexts/users/ — en al política objetivo, sólamente el archivo root está en este directorio. Estos archivos se utilizan para determinar el contexto cuando un usuario inicia una sesión. Por ejemplo, para el usuario root el contexto es user_u:system_r:unconfined_t.

  • /etc/selinux/targeted/modules/active/booleans* — aquí es donde se configuran los valores boleanos en tiempo de ejecución.

    Nota

    Nunca se deben cambiar estos archivos manualmente. Debe utilizar las herramientas getsebool, setsebool y semanage para manipular los valores boleanos en tiempo de ejecución.

44.7.2.2. Archivos de Arboles Fuente

Para desarrolar módulos de políticas, el paquete selinux-policy-devel incluye todos los archivos de la interfaz utilizados para construir la política. Se recomienda que la gente que construye políticas utilicen estos archivos para construir los módulos de políticas.

Este apquete instala los archivos de interfaz de políticas bajo /usr/share/selinux/devel/include y tiene instalados archivos make en /usr/share/selinux/devel/Makefile.

Para ayudar a aplicaciones que necesitan varias rutas SELinux, libselinux proporciona un número de funciones que devuelven las rutas a los diferentes archivos de configuración y directorios. Esto invalida la necesidad de que las aplicaciones codifiquen a fuego las rutas especialmente debido a que la ubicación de la política activa depende de la configuración SELINUXTYPE en /etc/selinux/config.

Por ejemplo, si SELINUXTYPE es configurado como strict la ubicación de la política activa se encuentra bajo /etc/selinux/strict.

Para dver la lista de las funciones disponibles utilice el siguiente comando:

man 3 selinux_binary_policy_path

Nota

Esta página del manuel se encuentra disponible sólamente si tiene el RPM libselinux-devel instalado.

El uso de libselinux y las funciones relacionadas se encuentra fuera del alcance de este documento.

44.7.3. El Papel de la Política durante el Proceso de Arranque

SELinux tiene un papel importante durante las primeras etapas del arranque del sistema. Debido a que los procesos deben ser etiquetados con su dominio correcto, init realiza algunas operaciones esenciales de manera temprana durante el proceso de arranque para mantener la sincronización entre el etiquetado y el refuerzo de políticas.

  1. Después de que se ha cargado el kernel durante el proceso de arranque, se le asigna al proceso inicial la Identificación inicial SELinux (SID por sus iniciales en inglés) del kernel predefinido. Se utilizan estos SIDs para bootstrap antes de que se cargue la política.

  2. /sbin/init monta /proc/ y después busca el tipo de sistema de archivo selinuxfs. Si está presente eso quiere decir que SELinux se encuentra activado en el kernel.

  3. Si init no encuentra SELinux en el kernel o si se encuentra desactivado por medio del parámetro boot selinux=0 o si /etc/selinux/config especifica que SELINUX=disabled entonces el proceso de arranque procede con un sistema no-SELinux.

    Al mismo tiempo, init establece el estatus de refuerzo si es diferente del que se encuentra en /etc/selinux/config. Esto sucede cuando un parámetro se pasa durante el proceso de arranque. El modo predeterminado es permisivo hasta que se carga la política y luego el refuerzo es establecido por el archivo de configuración o por los parámetros enforcing=0 o enforcing=1.

  4. Si SELinux se encuentra presente, se monta /selinux/.

  5. El kernel chequea /selinux/policyvers para ver la versión de políticas soportada. init inspecciona /etc/selinux/config para determinar que política se encuentra activa así como la política objetivo y carga el archivo asociado en $SELINUX_POLICY/policy.<version>.

    Si la política binaria no es la versión soportada por el kernel entonces init intenta cargar el archivo de políticas si es una versión anterior. Esto proporcina una compatibilidad retroactiva con versiones de políticas previas.

    Si la configuración local en /etc/selinux/targeted/booleans es diferente de la compilada en la política entonces init modifica la política en la memoria con base en la configuración local antes de cargar la política en el kernel.

  6. En este punto del proceso, la política se encuentra completamente cargada en el kernel. Luego los SIDs iniciales son mapeados a los contextos de seguridad en la política. En el caso de la política objetivo el nuevo dominio es user_u:system_r:unconfined_t. Ahora el kernel puede empezar a recuperar contextos de seguridad dinámicamente desde el servidor de seguridad que se encuentra en el kernel.

  7. Después init se re-ejecuta a sí mismo para que pueda regresar a un dominio diferente si al política lo define. Para la política objetivo no hay una transición definida y init permanece en el dominio unconfined_t.

  8. En este punto, init continua con su proceso normal de arranque.

La razón por la cual init se re-ejecuta a sí mismo para tener espacio para controles de políticas SELinux más estrictas. El objetivo de la re-ejecución es el de regresar a un nuevo dominio con sus propias reglas detalladas. La única forma de que un proceso pueda entrar en un dominio es durante la ejecución, lo cual significa que dichos procesos sólamente son puntos de entrada a los dominios.

Por ejemplo, si la política ha especificado un dominio para init, tal como init_t se neceista un método para cambiar el SID inicial así como kernel al dominio de tiempo de ejecución correcto para init. Debido a que puede necesitarse que ocurra esta transición, init es codificado para re-ejecutarse a si mismo después de cargar la política.

Esta transición init ocurre si la regla domain_auto_trans(kernel_t, init_exec_t, <target_domain_t>) está presente en la política. Esta regla establece que una transición automática ocuure en cualquier cosa que se encuentre ejecutando en el dominio kernel_t que ejecute un archivo de tipo init_exec_t. Cuando tiene lugar esta ejecución, se le asigna el dominio <target_domain_t> al nuevo proceso utilizando un dominio objetivo real tal como init_t.

44.7.4. Clases de Objetos y Permisos

SELinux define un número de calses para objetos haciendo más fácil agrupar ciertos permisos de acuerdo con clases especificas. Por ejemplo:

  • Clases relacionadas con archivos incluyen filesystem para sistemas de archivos, file para archivos y dir para directorios. Cada clase tiene su propio grupo de permisos asociados.

    La clase filesystem puede montar, desmontar, obtener atributos, establecer cuotas, re-etiquetar, etc. La clase file tiene permisos de archivos comúnes lectura, escritura, obtener y configurar atributos, bloquear, re-etiquetar, enlazar, renombrar, añadir, etc.

  • Las clases realcionadas con la red incluyen tcp_socket para sockets TCP, netif para interfaces de red y node para nodos de red.

    Por ejemplo, la clase netif puede enviar y recibir en TCP, UDP y sockets raw (tcp_recv, tcp_send, udp_send, udp_recv, rawip_recv y rawip_send).

Las clases de objetos tiene declaraciones que coinciden en el kernel lo cual significa que no es nada trivial el añadir o cambiar detalles a las clases de objetos. Lo mismo aplica para permisos. El trabajo de desarrollo es continuo y hace posible registrar y sacar del registro dinámicamente clases y permisos.

Los permisos son acciones que un sujeto puede realizar en un objeto si la política lo permite. Estos permisos son las peticiones de acceso que SELinux permite o rechaza activamente.

44.8. Sinopsis de la Política de Objetivos

Este capítulo es una sinopsis y examen de la política de objetivos de SELinux, la política actual soportada para Red Hat Enterprise Linux.

Mucho del contenido de este capítulo se aplica a todos los tipos de políticas de SELinux en términos de ubicación de archivos y el tipo de contenido en esos archivos. La diferencia radica en los archivos que existen en lugares clave y su contenido.

44.8.1. ¿Qué es la Política Objetivo?

La política SELinux es latemente configurable. Para Red Hat Enterprise Linux 5, Red Hat soporta una sola política, la política objetivo . Bajo la política objetivo, cada sujeto y objeto ejecutan en el dominio unconfined_t a excepción de los demonios objetivo especificados. LOs objetos que se encuentran en el dominio unconfined_t no tienen restricciones y retroceden a utilizar seguridad Linux estándar, es decir, DAC. Los demonios que son parte de la política objetivo ejecutan en sus propios dominios y están restringidos en toda operación que realizan en el sistema. De esta manera los demonios que son explotados o comprometidos de cualquier manera son contenidos y puede causar daño limitado.

Por ejemplo, los demonios http y ntp están protegidos en la política objetivo predeterminada y ejecutan en los dominios httpd_t y ntpd_t, respectivamente. Sin embargo, el demonio ssh no está protegido en esta política y por consecuencia ejecuta en el dominio unconfined_t.

Refiérase a la siguiente salida de ejemplo, la cual ilustra los diversos dominios para los demonios mencionados anteriormente:

user_u:system_r:httpd_t         25129 ?        00:00:00 httpd
user_u:system_r:ntpd_t          25176 ?        00:00:00 ntpd
system_u:system_r:unconfined_t         25245 ? 00:00:00 sshd
La Política Estricta

Lo opuesto a la política objetivo es la política estricta . En esta política todo sijeto y objeto existen en un dominio de seguridad específico y todas las interacciones y transiciones son consideradas de manera individual dentro de las reglas políticas.

La política estricta es un entorno mucho más complejo y no se envía junto con Red Hat Enterprise Linux. Este manual se encfoca en la política objetivo que se entrega junto con Red Hat Enterprise Linux y los componentes de SELinux utilizados por los demonios objetivo.

Los demonios objetivos son los siguientes:dhcpd; httpd; mysqld; named; nscd; ntpd; portmap; postgres; snmpd; squid; syslogd y winbind.

Nota

Dependiendo de su instalación sólamente algunos de estos demonios pueden llegar a estar presentes.

44.8.2. Archivos y Directorios de la Política Objetivo

Consulte Sección 44.7.2, “¿Dónde se encuentra la Política?” para obtener una lista de archivos y directorios comunes utilizados por SELinux.

44.8.3. Usuarios y Roles en la Política Objetivo

Esta sección cubre los rroles específicos activados para la política objetivo.

Efectivamente, solo hay dos roles en la política de objetivos: system_r y object_r. El rol inicial es system_r y todo lo demás hereda ese rol. Los roles que quedan se definen para propósitos de compatibilidad entra la política de objetivos y la política estricta.[16]

Tres de los cuatro roles están definidos por la política. El cuarto rol object_r, es un rol supuesto y no se encuentra en la fuente de políticas. Debido a que los roles son creado y completados por tipos utilizando una o más declaraciones en la política, no hay un solo archivo que declare todos los roles (recuerde que la política misma es generada de un número de archivos separados).

system_r

El rol es para todos los procesos del sistema a excepción de los procesos del usuario:

system_r (28 types)
    dhcpd_t
    httpd_helper_t
    httpd_php_t
    httpd_suexec_t
    httpd_sys_script_t
    httpd_t
    httpd_unconfined_script_t
    initrc_t
    ldconfig_t
    mailman_cgi_t
    mailman_mail_t
    mailman_queue_t
    mysqld_t
    named_t
    ndc_t
    nscd_t
    ntpd_t
    pegasus_t
    portmap_t
    postgresql_t
    snmpd_t
    squid_t
    syslogd_t
    system_mail_t
    unconfined_t
    winbind_helper_t
    winbind_t
    ypbind_t
user_r

Este es el rol de usuario predeterminado para usuarios de Linux habilutales. En una política estricta, los usuarios individuales pueden llegar a utilizarse, permitiendo a los usuarios tener roles especiales para realizar operaciones privilegiadas. En la política de objetivos todos los usuarios ejecutan en el dominio unconfined_t.

object_r

En SELinux, los roles no se utilizan para objetos cuando RBAC se está utilizando. LOs roles son estrictamente para sujetos. Esto se debe a que los roles son orientados a tareas y agrupan entidades las cuales relaizan acciones (por ejemplo, procesos). Todas estas entidades son referidas colectivamente como sujetos. Por esta razón todos los objetos tienen el rol object_r y el rol solo se utiliza como un parámetro de sustitución en la etiqueta.

sysadm_r

Este es el rol del administrador del sistema en una política estricta. Si inicia la sesión directamente como usuario root el rol predeterminado puede ser de hecho staff_r. Si es verdadero utilice el comando newrole -r sysadm_r para cambiar al rol del administrador del sistema de SELinux para realizar tareas de administración del sistema. En la política de objetivos los siguinetes retienen sysadm_r pr compatibilidad:

sysadm_r (6 types)
    httpd_helper_t
    httpd_sys_script_t
    initrc_t
    ldconfig_t
    ndc_t
    unconfined_t

Efectivamente solo hay una identidad de usuario en la política de objetivos. La identidad user_u fue seleccionada ya que libselinux regresa a user_u como la identidad de usuario de SELinux predeterminado. Esto ocurre cuando no hay un usuario de SELinux que coincida con el usuario de Linux que está inicando la sesión. El utilizar user_u como el usuario único en la política de objetivos hace más fácil el cambiar la política estricta. Los usuarios que quedan existen para compatibilidad con la política estricta.[17]

La única excepción en el usuario root de SELinux. Podrá notar que root es la identidad de usuario en el contexto de un proceso. Esto ocurre cuando el usuario root de SELinux inicia demonios desde la línea de comandos o reinicia un demonio que init inició originalmente.



[14] La NSA es la agencia de criptología del gobierno federal de los Estados Unidos de Norteamérica. Está encargada del aseguramiento de la información e inteligencia de señales. Se puede obtener mayor información sobre la NSA desde su sitio web: http://www.nsa.gov/about/.

[15] Flask se desarrollo desde un proyecto que integraba el Distributed Trusted Operating System (DTOS ) dentro del sistema operativo de investigación Fluke. Flask fue el nombre de la arquitectura y la implementación en el sistema operativo Fluke.

[16] Se puede escoger cualquier rol para la política de objetivos pero system_r ya tenía autorización previa para los dominios de demonio, lo cual simplifica el proceso. Esto se hizo ya que en el momento no existe un mecanismo para crear alias para los roles.

[17] Un mecanismo de alias de un usuario también funcionaría aquí para dar un alias de todas las identidades de la política estricta a una identidad de usuario única en la política de objetivos.

Capítulo 45. Trabajar con SELinux

SELinux presenta un nuevo paradigma de seguridad y nuevo grupo de prácticas y herramientas para los administradores y algunos de los usuarios finales. Las herramientas y técnicas que se discuten en este capítulo se enfocan en operaciones estándar que usuarios finales, administradores y analistan realizan.

45.1. Control de Usuario Final de SELinux

En general, los usuarios finales tienen poca interacción con SELinux cuando Red Hat Enterprise Linux esta ejecutando la política objetivo. Esto se debe a que los usuarios están ejecutando en el dominio de unconfined_t junto con el resto del sistema a excepción de los demonios objetivo.

En la mayoria de los casos , los controles DAC estándares le evitan el tener que realizar tareas para las cuales usted no tiene el acceso o los permisos requeridos antes de que se le consulte a SELinux. Por lo tanto es muy probable que usted nunca genere un mensaje avc: denied.

Las siguientes secciones cubren las tareas y práticas generales que los usuarios finales pueden llegar a necesita realizar en un sistema Red Hat Enterprise Linux. Estas tareas aplican a los usurios de tod nivel de privilegios y no sólamente a usuarios finales.

45.1.1. Mover y Copiar Archivos

En operaciones del sistema de archivos, el contexto de seguridad debe ser considerado en términos de la etiqueta del archivo, el proceso que lo evalúa y los directorios en donde está ocurriendo la operación. Debido a esto, el mover y copiar archivos con mv y cp puede llegar a tener resultados inesperados.

Copiar Archivos: Opciones para cp de SELinux

A menos de que especifique lo contrario, cp sigue el comportamiento predeterminado de crear un archivo nuevo con base en el dominio del proceso de creación y el tipo de directorio objetivo. A menos de que haya una reglas espcifica para configuara la etiqueta, el archivo hereda el tipo del directorio objetivo.

Utilice la opción -Z user:role:type para especificar la etiqueta requerida para el nuevo archivo.

La opción -p (or --preserva=modo, propiedad, sellos de fecha) preserva los atributos especificados y si es posible preserva los atribuots adicionales como enlaces.

touch bar foo
ls -Z bar foo
-rw-rw-r--  auser   auser   user_u:object_r:user_home_t   bar
-rw-rw-r--  auser   auser   user_u:object_r:user_home_t   foo

Si utiliza el comando cp sin ningún argumento de línea de comando adicional se creará una copia del archivo en la nueva ubicación utilizando el tipo predeterminado del proceso de cración y el directorio objetivo. En este caso, debido a que no aplica ninguna regla especifica a cp y /tmp, el nuevo archivo tiene el tipo del directorio padre:

cp bar /tmp
ls -Z /tmp/bar
-rw-rw-r--  auser   auser   user_u:object_r:tmp_t   /tmp/bar

El tipo tmp_t es el tipo predeterminado para archivos temporales.

Utilice la opción -Z para especificar la etiqueta para el nuevo archivo:

cp -Z user_u:object_r:user_home_t foo /tmp
ls -Z /tmp/foo
-rw-rw-r--  auser   auser   user_u:object_r:user_home_t   /tmp/foo
Mover Archivos: SELinux Opciones para mv

El mover archivos con mv retiene el tipo original asociado con el archivo. Se debe tener cuidado al utilizar este comando ya que puede llegar a causar problemas. Por ejemplo, si mueve los archivos con el tipo user_home_t a ~/public_html, entonces el demonio httpd no puede servir esos archivos hasta que los re-etiquete. Consulte Sección 45.1.3, “Nuevas Etiquetas para un Archivo o Directorio” para obtener mayor información sobre etiquetado de archivos.

Comando Comportamiento
mv Este archivo retiene su etiqueta original. Esto puede llegar a causar problemas, confusión o inseguridad menor. Por ejemplo, el programa tmpwatch ejecutando en el dominio sbin_t puede que no se le permita borrar un archivo viejo en el directorio /tmp debido al tipo del archivo.
cp Hace una copia del archivo utilizando el comportamiento predeterminado con base en el dominio del proceso de creación (cp) y el tipo del directorio objetivo.
cp -p Hace una copia del archivo preservando los atributos especificados y los contextos de seguridad si es posible. Los atributos predeterminados son mode, ownership y timestamps. Los atributos adicionales son links y all.
cp -Z <user:role:type> Hace una copia del archivo con las etiquetas especificadas. La opción -Z es sinónimo de --context.
Tabla 45.1. Comportamiento de los Comandos mv y cp

45.1.2. Verificar el Contexto de Seguridad de un Proceso, Usuario u Objeto de Archivo

Verificar un ID de Proceso

En Red Hat Enterprise Linux, la opción -Z es equivalente a --context y se puede utilizar con los comandos ps, id, ls y cp. El comportamiento del comando cp con respecto a SELinux se explica en Tabla 45.1, “Comportamiento de los Comandos mv y cp”.

El siguiente ejemplo es una pequeña muestra de la salida del comando ps. La mayoría de los procesos están ejecutando en el dominio unconfined_t, con pocas excepciones.

[user@localhost ~]$ ps auxZ
LABEL                           USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
system_u:system_r:init_t        root         1  0.0  0.1   2032   620 ?        Ss   15:09   0:00 init [5]
system_u:system_r:kernel_t      root         2  0.0  0.0      0     0 ?        S    15:09   0:00 [migration/0]
system_u:system_r:kernel_t      root         3  0.0  0.0      0     0 ?        SN   15:09   0:00 [ksoftirqd/0]

user_u:system_r:unconfined_t    user     3122  0.0  0.6   6908  3232 ?        S    16:47   0:01 /usr/libexec/gconfd-2 5
user_u:system_r:unconfined_t    user     3125  0.0  0.1   2540   588 ?        S    16:47   0:00 /usr/bin/gnome-keyring-daemon
user_u:system_r:unconfined_t    user     3127  0.0  1.4  33612  6988 ?        Sl   16:47   0:00 /usr/libexec/gnome-settings-daemon
user_u:system_r:unconfined_t    user     3144  0.1  1.4  16528  7360 ?        Ss   16:47   0:01 metacity --sm-client-id=default1
user_u:system_r:unconfined_t    user     3148  0.2  2.9  79544 14808 ?        Ss   16:47   0:03 gnome-panel --sm-client-id default2
Verificar un ID de Usuario

Puede utilizar la opción -Z con el comando id para determinar un contexto de seguridad de un usuario. Observe que con este comando no puede combinar -Z con otras opciones.

[root@localhost ~]# id -Z
user_u:system_r:unconfined_t

Observe que no puede utilizar la opción -Z con el comando id para inspeccionar el contexto de seguridad de un usario diferente. Es decir que usted sólamente puede visualizar el contexto de seguridad del usuario conectado actualmente:

[user@localhost ~]$ id
uid=501(user) gid=501(user) groups=501(user) context=user_u:system_r:unconfined_t
[user@localhost ~]$ id root
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
[user@localhost ~]$ id -Z root
id: cannot display context when selinux not enabled or when displaying the id
of a different user
Verifica el ID de un Archivo

Puede utilizar la opción -Z con el comando ls para agrupar información con formato común largo. Puede visualizar información sobre el modo, usuario, grupo, contexto de seguridad y nombre del archivo.

cd /etc
ls -Z h* -d
drwxr-xr-x  root root  system_u:object_r:etc_t        hal
-rw-r--r--  root root  system_u:object_r:etc_t        host.conf
-rw-r--r--  root root  user_u:object_r:etc_t          hosts
-rw-r--r--  root root  system_u:object_r:etc_t        hosts.allow
-rw-r--r--  root root  system_u:object_r:etc_t        hosts.canna
-rw-r--r--  root root  system_u:object_r:etc_t        hosts.deny
drwxr-xr-x  root root  system_u:object_r:hotplug_etc_t  hotplug
drwxr-xr-x  root root  system_u:object_r:etc_t        hotplug.d
drwxr-xr-x  root root  system_u:object_r:httpd_sys_content_t htdig
drwxr-xr-x  root root  system_u:object_r:httpd_config_t httpd

45.1.3. Nuevas Etiquetas para un Archivo o Directorio

Puede que necesite volver a etiquetar un archivo cunaod lo está moviendo o copiando a directorios especiales relacionados con los demonios objetivo así como los directorios ~/public_html o cuando se escriben scripts que funcionan en directorios fuera de /home.

Hay dos tipos generales de operaciones para volver a etiquetar:

  • Cambiando deliberadamente el tipo de archivo

  • Restablecer archivos a su estado predeterminado de acuerdo con la política

También hay operaciones que el administrador realiza para dar una etiqueta nueva y se cubren en Sección 45.2.2, “Creación de Etiquetas Nuevas para Sistemas de Archivos”.

Sugerencia

Gran parte del control de permisos de SELinux en la política objetivo es el Tipo de Refuerzo (TE). Por lo tanto, generalmente puede ignorar la información de la etiqueta de seguridad sobre el usuario y el rol y enfocarse en sólo cambiar el tipo. Normalmente no necesita considerar la configuración del rol y del usuario en los archivos.

Nota

Si el dar una etiqueta nueva afecta la etiqueta en el ejecutable del demonio, debe reiniciar el demonio para asegurarse de que se encuentra ejecutando en el dominio correcto. Por ejemplo, si /usr/sbin/mysqld tiene la etiqueta de seguridad equivocada y usted trata de solucionar esto utilizando una operación para otorgar una etiqueta nueva tal como restorecon debe reiniciar mysqld después de la operación de reetiquetamiento. El configurar el archivo ejecutable para que tenga el tipo correcto (mysqld_exec_t) es una manera de asegurarse de que se realice una transición al dominio apropiado cuando se da inicio.

Utilice el comando chcon para cambiar un archivo al tipo correcto. Necesita saber el tipo correcto que quiere aplicar para utilizar este comando. Los directorios y archivos en el siguiente ejemplo se encuentran etiquetados con el tipo predeterminado definido por los objetos del sistema de archivos creados en /home:

cd ~
ls -Zd public_html/
drwxrwxr-x  auser  auser  user_u:object_r:user_home_t public_html/

ls -Z web_files/
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   1.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   2.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   3.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   4.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   5.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   index.html

Si mueve estos archivos al directorio public_html retienen el tipo original:

mv web_files/* public_html/
ls -Z public_html/
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   1.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   2.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   3.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   4.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   5.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t   index.html

Para que estos archivos sean visibles desde una carpeta especial HTML de usuarios públicos, ellos necesitan tener un tipo httpd que tenga permiso de leer, aumiendo que el Servidor HTTP Apache se encuentra configurado para UserDir y que el valor boleano httpd_enable_homedirs esté activado.

chcon -R -t httpd_user_content_t public_html/
ls -Z public_html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   1.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   2.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   3.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   4.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   5.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t   index.html

ls -Z public_html/ -d
drwxrwxr-x  auser  auser  user_u:object_r:httpd_user_content_t  public_html/

Sugerencia

Si el archivo no tiene etiqueta así como un archivo creado mientras que SELinux estaba deshabilitado en el kernel, necesita darle una etiqueta completa con chcon system_u:object_r:shlib_t foo.so. De otra manera, recibirá un error sobre aplicación de un contexto parcial a un archivo sin etiqueta.

Utilice el comando restorecon para restablecer archivos a los valores predeterminados de acuerdo con la política. Hay otros dos métodos que funcionan para realizar esta operación en el sistema de archivos entero: fixfiles o una operación de reetiquetamiento de políticas. Cada uno de esos métodos requiere privilegios de superusuario. Las advertencias para ambos métodos se pueden consultar en Sección 45.2.2, “Creación de Etiquetas Nuevas para Sistemas de Archivos”.

El siguiente ejemplo demuestra el restablecimiento del contexto del directorio principal predeterminado del usuario a un grupo de archivos que tienen diferentes tipos. Los primeros dos grupos de archivos tienen diferentes tipos y los están moviendo a un directorio para archivarlos. Sus contextos son diferentes entre ellos y son incorrectos para el directorio principal estándar del usuario:

ls -Z /tmp/
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            /tmp/file1
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            /tmp/file2
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            /tmp/file3

mv /tmp/{1,2,3} archives/
mv public_html/* archives/
ls -Z archives/
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            file1
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t    file1.html
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            file2
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t    file2.html
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t            file3
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t    file3.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t    file4.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t    file5.html
-rw-rw-r--  auser  auser  user_u:object_r:httpd_user_content_t  index.html

El directorio archives/ ya tiene el tipo predeterminado porque fue creado en el directorio principal del usuario:

ls -Zd archives/
drwxrwxr-x  auser  auser  user_u:object_r:user_home_t  archives/

Utilizando el comando restorecon para darle una nueva etiqueta a los archivos utiliza los contextos de los archivos predeterminados establecidos por la política así que estos archivos se les da la etiqueta predeterminada para el directorio actual.

/sbin/restorecon -R archives/
ls -Z archives/
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file1
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file1.html
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file2
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file2.html
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file3
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file3.html
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file4.html
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    file5.html
-rw-rw-r--  auser  auser  system_u:object_r:user_home_t    index.html

45.1.4. Creación de Archivos que Retienen Contextos de Seguridad

Puede utilizar las utilidades tar o star para crear ficheros que retengan contextos de seguridad SELinux. El siguiente ejemplo utiliza star para demostrar como crear tal fichero. Necesita utilizar las opciones apropiadas -xattr y -H=exustar para asegurarse de que los atributos extras son capturados y de que el encabezamiento para el archivo *.star sea de un tipo que soporta por completo xattrs. Consulte la página del manual patra obtener mayor información sobre estas y otras opciones.

El siguiente ejemplo ilustra la creación y extracción de un grupo de archivos y directorios html. Observe que los dos directorios tienen etiquetas diferentes. Se han omitido partes poco importantes del contexto del archivo debido a razones de impresión (indicado por comillas simples '...'):

ls -Z public_html/ web_files/

public_html/:
-rw-rw-r--  auser  auser  ...httpd_user_content_t 1.html
-rw-rw-r--  auser  auser  ...httpd_user_content_t 2.html
-rw-rw-r--  auser  auser  ...httpd_user_content_t 3.html
-rw-rw-r--  auser  auser  ...httpd_user_content_t 4.html
-rw-rw-r--  auser  auser  ...httpd_user_content_t 5.html
-rw-rw-r--  auser  auser  ...httpd_user_content_t index.html
web_files/:
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  1.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  2.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  3.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  4.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  5.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  index.html

El siguiente comando crea el fichero reteniendo todos los contextos de seguridad de SELinux:

star -xattr -H=exustar -c -f all_web.star public_html/ web_files/
star: 11 blocks + 0 bytes (total of 112640 bytes = 110.00k).

Utilice el comando ls con la opción -Z para validar el contexto de seguridad:

ls -Z all_web.star
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t \  all_web.star

Ahora puede copiar el fichero a un directorio diferente. En este ejemplo, el fichero es copiado a /tmp. Si no hay una política especifica para tomar un tipo temporal derivativo, el comportamiento predeterminado es adquirir el tipo tmp_t.

cp all_web.star /tmp/ cd /tmp/

ls -Z all_web.star
-rw-rw-r--  auser  auser  user_u:object_r:tmp_t  all_web.star

Ahora puede expandir los ficheros utilizando star y restablece los atributos extendidos:

star -xattr -x -f all_web.star
star: 11 blocks + 0 bytes (total of 112640 bytes = 110.00k).

ls -Z /tmp/public_html/ /tmp/web_files/
/tmp/public_html/:
-rw-rw-r--  auser  auser  ...httpd_sys_content_t 1.html
-rw-rw-r--  auser  auser  ...httpd_sys_content_t 2.html
-rw-rw-r--  auser  auser  ...httpd_sys_content_t 3.html
-rw-rw-r--  auser  auser  ...httpd_sys_content_t 4.html
-rw-rw-r--  auser  auser  ...httpd_sys_content_t 5.html
-rw-rw-r--  auser  auser  ...httpd_sys_content_t index.html
/tmp/web_files/:
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  1.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  2.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  3.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  4.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  5.html
-rw-rw-r--  auser  auser  user_u:object_r:user_home_t  \ index.html

Atención

Si utiliza una ruta absoluta cuando crea un fichero utilizando star, el fichero se expande en esa misma ruta. Por ejemplo, un fichero hecho son este comando restablece los archivos a /var/log/httpd/:

star -xattr -H=exustar -c -f httpd_logs.star /var/log/httpd/

Si trata de expandir este fichero, star emite una advertencia si los archivos en la ruta son más nuevos que los que se encuentran el fichero.

45.2. Controles administrativos de SELinux

Además de las tareas que con frecuencia realizan los usuarios en Sección 45.1, “Control de Usuario Final de SELinux”, los administradores de SELinux pueden llegar a necesitar realizar un número de tareas adinionales. Típicamente estas tareas requieren acceso root al sistema. Dichas tareas son mucho más fáciles bajo la política objetivo. Por ejemplo, no hay necesidad de considerar añadir, editar o borrar usuarios Linux de los usuarios de SELinux y tampoco necesita considerar los roles.

Esta sección cubre los tipos de tareas que se necesitan de un administrador que mantiene Red Hat Enterprise Linux ejecutando SELinux.

45.2.1. Ver el Estado de SELinux

El comando sestatus proporciona una vista configurable al estado de SELinux. La forma más simple de este comando muestra la siguiente información:

[root@localhost ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted

La opción -v incluye información sobre los contextos de seguridad de una serie de archivos que se encuentran especificados en /etc/sestatus.conf:

[root@localhost ~]# sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted

Process contexts:
Current context:                user_u:system_r:unconfined_t
Init context:                   system_u:system_r:init_t
/sbin/mingetty                  system_u:system_r:getty_t
/usr/sbin/sshd                  system_u:system_r:unconfined_t:s0-s0:c0.c1023

File contexts:
Controlling term:               user_u:object_r:devpts_t
/etc/passwd                     system_u:object_r:etc_t
/etc/shadow                     system_u:object_r:shadow_t
/bin/bash                       system_u:object_r:shell_exec_t
/bin/login                      system_u:object_r:login_exec_t
/bin/sh                         system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
/sbin/agetty                    system_u:object_r:getty_exec_t
/sbin/init                      system_u:object_r:init_exec_t
/sbin/mingetty                  system_u:object_r:getty_exec_t
/usr/sbin/sshd                  system_u:object_r:sshd_exec_t
/lib/libc.so.6                  system_u:object_r:lib_t -> system_u:object_r:lib_t
/lib/ld-linux.so.2              system_u:object_r:lib_t -> system_u:object_r:ld_so_t

La -b presenta el estado actual de los valores boleanos. Puede utilizar esto en combinación con grep u otras herramientas para determinar el estado de valores boleanos en particular:

[root@host2a ~]# sestatus -b | grep httpd | grep on$
httpd_builtin_scripting           on
httpd_disable_trans               on
httpd_enable_cgi                  on
httpd_enable_homedirs             on
httpd_unified                     on

45.2.2. Creación de Etiquetas Nuevas para Sistemas de Archivos

Puede que nunca necesite crear etiquetas nuevas para un sistemas de archivos completo. Usualmente esto sólamente ocurre cuando crea una etiqueta nueva para un sistema de archivos por primera vez para SELinux o cuando está cambiando entre diferentes tipos de políticas así como el cambio de la política objetivo a la estricta.

Creación de Etiquetas Nuevas para un Sistema de Archivos Utilizando init

El método recomendado para crear una etiqueta nueva para un sistemas de archivos es reinciando la máquina. Esto permite que el proceso init realice la creación de una nueva etiqueta asegurándose de que las aplicaciones tienen las etiquetas correctas cuando se inician y de que se inician en el orden correcto. Si crea una nueva etiqueta para un sistema de archivos si reiniciarlo, puede que algunos de los procesos continuen ejecutándose con un contexto incorrecto. Puede llegar a ser dificil asegurarse manualmente de que todos los demonios son reiniciados y ejecutados en el contexto correcto.

Utilice el siguiente procedimiento para cambiar la etiqueta de un sistema de archivos utilizando este método.

touch /.autorelabel
reboot

En tiempo de arranque init.rc verifica la existencia de /.autorelabel. Si este archivo existe, SELinux crea etiquetas nuevas para el sistema de archivos completo (utilizando el comando /sbin/fixfiles -f -F relabel) y luego borra /.autorelabel.

Creacón de Etiquetas Nuevas para un Sistema de Archivos utilizando fixfiles

Es posible crear una etiqueta nueva para un sistema de archivos utilizando el comando fixfiles o con base en la base de datos RPM:

Utilice el siguiente comando para crear una etiqueta nueva para un sistemas de archivos utilizando sólamente el comando fixfiles:

creación de etiquetas nuevas para fixfiles

Utilice el siguiente comando para crear etiquetas nuevas para un sistema de archivos con base en la base de datos RPM:

fixfiles -R <packagename> restablecer

Utilizando fixfiles para restablecer contextos de los paquetes es más seguro y rápido.

Atención

El ejecutar fixfiles en el sistema de archivos completo sin reiniciar puede hacer inestable el sistema.

Si la operación de creación de una nueva etiqueta aplica una nueva política que es diferente de la política que se encontraba cuando el sistema se reinició, los procesos existentes pueden estar ejecutándose en dominios incorrectos e inseguros. Por ejemplo, un proceso puede estar en un dominio que no es una transición permitida para ese proceso en la nueva política, dados los permisos inesperados en sólo ese proceso.

Además una de las opciones para fixfiles relabel pide aprobación para vaciar /tmp/ ya que no es posible crear una etiqueta nueva de manera confiable para /tmp/. Debido a que fixfiles se ejecuta como root, se borran los archivos temporales de los cuales dependen las aplicaciones. Esto puede hacer el sistema inestable o que se comporte de una manera inesperada.

45.2.3. Administración de Directorios Principales NFS

En Red Hat Enterprise Linux 5, la mayoría de los demonios objetivo no interactúan con los datos de usuarios y no son afectados por los directorios principales montados con NFS. El Servidor Apache HTTP es una excepción. Por ejemplo los scripts CGI que se encuentran montados en el sistema de archivos tienen el tipo nfs_t, el cual es un tipo que no se le permite ejecutar a httpd_t.

Si tiene problemas con el tipo predeterminado de nfs_t trate de montar los directorios principales con un contexto diferente:

mount -t nfs -o context=user_u:object_r:user_home_dir_t \
        fileserver.example.com:/shared/homes/ /home

Atención

Sección 45.2.9, “Especificación del Contexto de Seguridad del Sistema de Archivos Entero” explica como montar un directorio para que httpd pueda ejecutar scripts. Si hace esto para directorios principales de usuarios le da al Servidor HTTP Apache un mayor acceso a esos directorios. Recuerde que aplica un punto de montaje aplica a todo el sistema de archivos montados.

Las versiones futuras de la política de SELinux abordan la funcionalidad de NFS.

45.2.4. Otorgar Acceso a un Directorio o a un Arbol

De manera similay a los permisos estándares de Linux DAC, un demonio objetivo tiene que tener permisos SELinux para poder descender en el árbol de directorios. Esto no significa que un directorio y su cotenido necesitan tener el mismo tipo. Hay muchos tipos así como root_t, tmp_t y usr_t que otorgan acceso de lectura para un directorio. Estos tipos son apopiados para directorios que no contienen ninguna información confidencial y que usted quiere que sean ampliamente leíbles. También se pueden utilizar para un directorio padre de directorios más seguros con contextos diferentes.

Si está trabajando con un mensaje avc: denied hay algunos problemas comunes que surgen con la traversal del directorio. Por ejemplo, muchos programas ejecutan un comando euqivalente a ls -l / que no es necesario para su operación pero que genera un mensaje de rechazo en los registros. Para estos necesita crear una regla dontaudit en su archivo local.te.

Al tratar de interpretar mensajes de rechazo de AVC no se confunda por el componente path=/. La ruta no está relacionada con la etiqueta para el sistema de archivos root, /. De hecho es relativo al root del sistema de archivos en el nodo del dipositivo. Por ejemplo, si su directorio /var/ se encuentra ubicado en un dispositivo LVM (Administración de Volúmenes Lógicos[18]), /dev/dm-0, el nodo dispositivo es identificado en el mensaje como dev=dm-0.Cuando vea path=/ en este ejemplo, ese es el nivel superior del dispositivo LVM dm-0, no necesariamente el mismo que la designación del sistema de archivos root /.

45.2.5. Copias de Seguridad y Restauración del Sistema

Consulte la explicación en Sección 45.1.4, “Creación de Archivos que Retienen Contextos de Seguridad”.

45.2.6. Activación o Desactivación del Refuerzo

Puede activar o desactivar el refuerzo de SELinux en tiempo de ejecución o configurarlo para que inicie en el modo correcto en tiempo de arranque utilizando la línea de comandos o GUI. SELinux puede operar en uno de los tres modos: desactivado lo que significa que no está activado en el kernel; permisivo lo que quiere decir que SELinux está ejecutando y registrando pero no controlando permisos o reforzar que significa que SELinux está ejecutando y reforzando políticas.

Utilice el comando setenforce para cambiar entre los modos permisivo y reforzar durante el tiempo de ejecución. Utilice setenforce 0 para entrar en modo permisivo y utilice setenforce 1 para entrar en modo de reforzamiento.

El comando sestatus presenta el modo actual y el modo del archivo de configuración referenciado durante el arranque:

sestatus | grep -i mode
Current mode:           permissive
Mode from config file:  permissive

Observe que el cambio del refuerzo durante tiempo de ejecución no afecta la configuración de tiempo de arranque:

setenforce 1
sestatus | grep -i mode
Current mode:           enforcing
Mode from config file:  permissive

También puede desactivar el modo de refuerzo para un sólo demonio. Por ejemplo, si está tratando de resolver problemas del demonio named y SELinux entonces puede apagar el refuerzo para sólo ese demonio.

Utilice el comando getsebool para obtener el estado actual del valor booleano:

[root@host2a ~]# getsebool named_disable_trans
named_disable_trans --> off

Utilice el siguiente comando para desactivar el modo de refuerzo para este demonio:

[root@host2a ~]# setsebool named_disable_trans 1

[root@host2a ~]# getsebool named_disable_trans
named_disable_trans --> on

Nota

Esto configura el valor del tiempo de ejecución sólamente. Utilice la opción -P para hacer persistentes lo cambios a través de los reinicios.

Cualquier* valor booleano _disable_trans que esté configurado como "encendido" invoca el condicional que evita que el proceso realice una trancisión al dominio en ejecución.

Utilice el siguiente comando para ver cuales de estos valores booleanos están configurados:

getsebool -a | grep disable.*on

httpd_disable_trans=1
mysqld_disable_trans=1
ntpd_disable_trans=1

Puede configurar cualquier número de valores booleanos utilizando el comando setsebool:

setsebool -P httpd_disable_trans=1 mysqld_disable_trans=1 ntpd_disable_trans=1

También puede utilizar togglesebool <boolean_name> para cambiar el valor a un valor booleano específico:

[root@host2a ~]# getsebool httpd_disable_trans
httpd_disable_trans --> off

[root@host2a ~]# togglesebool httpd_disable_trans
httpd_disable_trans: active

Puede configurar todas estas características utilizando system-config-selinux. Se utilizan los mismos archivos de configuración así que los cambios aparecen bidireccionalmente.

Cambio de un Valor Booleano en Tiempo de Ejecución

Utilice el siguiente procedimiento para cambiar un valor boolenao en tiempo de ejecución utilizando el GUI.

Nota

Se requieren privilegios de administrador para realizar este procedimiento.

  1. En el menú Sistema vaya a Administración y luego haga click en Nivel de Seguridad y Cortafuegos para visualizar el diálogo de Configuración del Nivel de Seguridad.

  2. Luego haga click en la pestaña SELinux y después en Configuración SELinux.

  3. En la lista de selección haga click en la entrada Nombre del Servicio y seleccione la opción Desactivar la protección SELinux para un demonio nombrado.

  4. Haga click sobre OK para aplicar el cambio. Observe que el recargar la política puede tomar un poco de tiempo.

Utilización del diálogo de Configuración del Nivel de Seguridad para cambiar el valor booleano de tiempo de ejecución

Utilización del diálogo de Configuración del Nivel de Seguridad para cambiar el valor booleano de tiempo de ejecución

Figura 45.1. Utilización del diálogo de Configuración del Nivel de Seguridad para cambiar el valor booleano de tiempo de ejecución

Si quiere controlar estas características con scripts puede usar los comandos setenforce(1), getenforce(1) y selinuxenabled(1).

45.2.7. Activar o Desactivar SELinux

Importante

Los cambios que realice a los archivos mientras que SELinux se encuentra desactivado puede llegar a darles una etiqueta de seguridad inesperada y los arcivos nuevos no tendrán una etiqueta. Puede que necesite darle una etiqueta nueva a una parte o para todo el sistema de archivos despúes de re-activar SELinux.

Desde la línea de comandos puede editar el archivo /etc/sysconfig/selinux. Este archivo es un symlink a /etc/selinux/config. El archivo de configuracióne se explíca por si mismo. El cambiar el valor de SELINUX o SELINUXTYPE cambia el estado de SELinux y el nombre de la política que se utiliza la proxima vez que el sistema arranca.

[root@host2a ~]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
Cambio del Modo de SELinux Utilizando GUI

Utilice el siguiente procedimiento para cambiar el modo de SELinux utilizando GUI.

Nota

Necesita privilegios de administrador para realizar este procedimiento.

  1. En el menú Sistema vaya a Administración y luego haga click en Nivel de Seguridad y Cortafuegos para visualizar el diálogo de Configuración del Nivel de Seguridad.

  2. Haga click en la pestaña SELinux

  3. En Configuración SELinux puede selecionar Deshabilitado, Reforzar o Permisivo y luego haga click en OK.

  4. Si lo cambió de Habilitado a Deshabilitado o viceversa neceita reiniciar las máquina para que tenga efecto el cambio.

Los cambios realizados utilizando este diálogo se reflejan de inmediato en /etc/sysconfig/selinux.

45.2.8. Cambio de la Política

Esta sección proporciona una breve introducción para utilizar políticas personalizadas en su sistema. Una discución completa sobre este tema se encuentra más alla del alcance de este documento.

Para cargar una política diferente en su sistema cambie la siguiente línea en /etc/sysconfig/selinux:

SELINUXTYPE=<policyname>

en donde <nombre de la política> es el directorio del nombre de la política bajo /etc/selinux/. Esto asume que tiene instalada la política personalizada. Después de cambiar el parámetro SELINUXTYPE ejecute los siguientes comandos:

touch /.autorelabel
reboot

Utilice el siguiente procedimiento para cargar una política diferente utilizando la utilidad system-config-selinux:

Nota

Necesita privilegios de administrador para realizar este procedimiento.

  1. Asegúrese de que la estructura del directorio para la política requerida se encuentra completa bajo /etc/selinux .

  2. En el menú Sistema vaya a Administración y luego haga click en Nivel de Seguridad y Cortafuegos para visualizar el diálogo de Configuración del Nivel de Seguridad.

  3. Haga click en la pestaña SELinux

  4. En la lista Tipo de Política seleccione la política que desea cargar y luego haga click en OK. Esta lista sólamente es visible si se instala más de una política.

  5. Reinicie la máquina para que los cambios tengan efecto:

Utilización del diálogo de Configuración del Nivel de Seguridad para cargar una política personalizada.

Utilización del diálogo de Configuración del Nivel de Seguridad para cargar una política personalizada

Figura 45.2. Utilización del diálogo de Configuración del Nivel de Seguridad para cargar una política personalizada.

45.2.9. Especificación del Contexto de Seguridad del Sistema de Archivos Entero

Puede utilizar el comando mount -o context= para configurar un contexto individual para un sistema de archivos completo. Este puede ser un sistema de archivos que ya se encuentra montado y que soporta xattrs o un sistema de archivos de red que obtiene una etiqueta genfs tal como cifs_t o nfs_t.

Por ejemplo, si necesita que el Servidor HTTP Apache lea desde un directorio montado o que se produzca un loopback del sistema de archivos necesitará configurar el tipo como httpd_sys_content_t:

mount -t nfs -o context=system_u:object_r:httpd_sys_content_t \
        server1.example.com:/shared/scripts /var/www/cgi

Sugerencia

Cuando soluciona problemas relacionados con httpd y SELinux reduce la complejidad de su situación. Por ejemplo, si tiene el sistema de archivos montado en /mnt y enlazado simbólicamente a /var/www/html/foo tiene dos contextos de seguridad de los que se debe preocupar. Debido a que un contexto de seguridad es de la clase de objeto file y el otro de tipo lnk_file, son creados de manera diferente por l polític y puede llegar a tener lugar un comportamiento inesperado.

45.2.10. Cambio de la Categoria de Seguridad de un Archivo o Usuario

45.2.11. Ejecución de un Comando en un Contexto de Seguridad Especifico

Puede utilizar el comando runcon para ejecutar un comando en un cotexto específico. Esto esútil para scripts o para probar políticas pero se debe asegurar de que es implementado de manera correcta.

Por ejemplo, puede utilizar el siguiente comando para ejecutar un script para probar una posible mala etiquetación del contenido. Los argumentos que aparecen después del comando son considerados como parte del comando (en este ejemplo, ~/bin/contexttest es un script definido por el usuario).

runcon -t httpd_t ~/bin/contexttest -ARG1 -ARG2

También puede especificar el contexto completo así:

runcon user_u:system_r:httpd_t ~/bin/contexttest

45.2.12. Comandos Utiles para Scripts

La siguiente es una lista de los comandos útiles introducidos con SELinux y los cuales le pueden ser útiles al escribir scripts para ayudar a administrar su sistema:

getenforce

Este comando devuelve el estado de refuerzo de SELinux.

setenforce [ Enforcing | Permissive | 1 | 0 ]

Este comando controla el modo de refuerzo de SELinux. La opción 1 o Refuerzo le dice a SELinux que entre el modo de refuerzo. La opción 0 o Permisivo le dice a SELinux que entre en modo pasivo. Todavía se registran las violaciones de acceso pero no se previenen.

selinuxenabled

El comando sale con un estado 0 si se habilita SELinux y 1 si SELinux es deshabilitado.

selinuxenabled echo $? 0
getsebool [-a] [boolean_name]

Este comando muestra el estado de todos los valores booleanos (-a) o un valor booleano específico (<boolean_name>).

setsebool [-P] <boolean_name> value | bool1=val1 bool2=val2 ...

Este comando configura uno o más valores boolenaos. La opción -P hace que los cambios sean persistentes en los reinicios.

togglesebool boolean ...

Este comando alterna la configuración de uno o más valores booleanos. Esto afecta la configuración de los valores booleanos en la memoria sólamente y los cambios no son persistentes en los reinicios.

45.2.13. Cambio a un Rol Diferente

Utilice el comando newrole para ejecutar una shell nueva con el tipo y/o rol especificado. El cambio de roles típicamente sólo tiene sentido en la política estricta; la política objetivo generalmente está restringida a un sólo rol. Cambiar los tipos puede ser útil para propositos de prueba, validación y desarrollo.

newrole -r <role_r> -t <type_t> [-- [ARGS]...]

Los ARGS son pasados directamente al shell especificado en la entrada del usuario en el archivo /etc/passwd.

Nota

El comando newrole es parte del paquete policycoreutils-newrole, el cual se necesita si instala la política MLS o la estricta. No es instalada por defecto en Red Hat Enterprise Linux.

45.2.14. Cuando Reiniciar

La razón principal para reiniciar el sistema desde la perspectiva de SELinux es para dar etiquetas nuevas al sistema de archivos. en ciertas ocasiones puede que necesite reinicar el sistema para habilitar o deshabilitar SELinux.

45.3. Control Analista de SELinux

Esta sección describe algunas de las tareas comunes que un analista de seguridad puede llegar a necesitar realizar en un sistema SELinux.

45.3.1. Activación de la Auditoría de Kernel

Como parte de un análisis de SELinux o de la solución de problemas pude que usted elija habilitar una completa auditoría a nivel de kernel. Esto puede llegar a ser bastante verboso debido a que genera uno o más mensajes de aditoría adicionales por cada mensaje de auditoría AVC. Para habilitar este nivel de auditoría agregue el parámetro audit=1 a su línea de arranque de kernel ya sea en el archivo /etc/grub.conf o en el menú GRUB en tiempo de arranque.

Este es un ejemplo de una entrada de registro de auditoría completa cuando se le niega acceso a httpd a ~/public_html porque el directorio no tiene un etiqueta de contenido de web. Note que los sellos de fecha y el número serial el el cmpo de la auditoría son idénticos en ambos casos. Esto hace más fácil el seguirle la pista a un evento específico en los registros de auditoría:

Jan 15 08:03:56 hostname kernel: audit(1105805036.075:2392892): \
        avc:  denied  { getattr } for  pid=2239 exe=/usr/sbin/httpd \
        path=/home/auser/public_html dev=hdb2 ino=921135 \
        scontext=user_u:system_r:httpd_t \
        tcontext=system_u:object_r:user_home_t tclass=dir

El siguiente mensaje de auditoría dice más sobre la fuente incluyendo la clase de llamada de sistema involucrada mostrando que el http trató de iniciar el directorio:

Jan 15 08:03:56 hostname kernel: audit(1105805036.075:2392892): \
        syscall=195 exit=4294967283 a0=9ef88e0 a1=bfecc0d4 a2=a97ff4 \
        a3=bfecc0d4 items=1 pid=2239 loginuid=-1 uid=48 gid=48 euid=48 \
        suid=48 fsuid=48 egid=48 sgid=48 fsgid=48

El siguiente mensaje proporciona más información sobre el objetivo:

Jan 15 08:03:56 hostname kernel: audit(1105805036.075:2392892): \
        item=0 name=/home/auser/public_html inode=921135 dev=00:00

El sello de número serial siempre es idéntico para un evento revisado en particular. El sello de fecha pude que sea o no idéntico.

Nota

Si está utilizando un demonio de auditoría para solución de problemas, el demonio puede capturar los mensajes de auditoría en un sitio diferente de /var/log/messages tal como /var/log/audit/audit.log. Red Hat Enterprise Linux 5 actualmente no se entrega con un demonio de auditoría.

45.3.2. Volcado y Vista de Registros

La implementación de Red Hat Enterprise Linux 5 enruta los mensajes de auditoría AVC a /var/log/messages. Puede utilizar cualquiera de las utilidades de búsqueda estándar (por ejemplo, grep) para buscar líneas que contengan avc o audit.



[18] LVM es el agrupamiento físico en los pools virtuales que se particionan en volúmenes lógicos.

Capítulo 46. Customizing SELinux Policy

46.1. Introduction

In earlier releases of Red Hat Enterprise Linux it was necessary to install the selinux-policy-targeted-sources packages and then to create a local.te file in the /etc/selinux/targeted/src/policy/domains/misc directory. You could use the audit2allow utility to translate the AVC messages into allow rules, and then rebuild and reload the policy.

The problem with this was that every time a new policy package was released it would have to execute the Makefile in order to try to keep the local policy.

In Red Hat Enterprise Linux 5, this process has been completely revised. The "sources" rpm packages have been completely removed, and policy packages are treated more like the kernel. To look at the sources used to build the policy, you need to install the source rpm, selinux-policy-XYZ.src.rpm. A further package, selinux-policy-devel, has also been added, which provides further customization functionality.

46.1.1. Modular Policy

Red Hat Enterprise Linux introduces the concept of modular policy. This allows vendors to ship SELinux policy separately from the operating system policy. It also allows administrators to make local changes to policy without worrying about the next policy install. The most important command that was added was semodule.

semodule is the tool used to manage SELinux policy modules, including installing, upgrading, listing and removing modules. You can also use semodule to force a rebuild of policy from the module store and/or to force a reload of policy without performing any other transaction. semodule acts on module packages created by semodule_package. Conventionally, these files have a .pp suffix (policy package), although this is not mandated in any way.

46.1.1.1. Listing Policy Modules

To list the policy modules on a system, use the semodule -l command:

[root@host2a ~]# semodule -l
amavis  1.1.0
ccs     1.0.0
clamav  1.1.0
dcc     1.1.0
evolution       1.1.0
iscsid  1.0.0
mozilla 1.1.0
mplayer 1.1.0
nagios  1.1.0
oddjob  1.0.1
pcscd   1.0.0
pyzor   1.1.0
razor   1.1.0
ricci   1.0.0
smartmon        1.1.0

Note

This command does not list the base policy module, which is also installed.

The /usr/share/selinux/targeted/ directory contains a number of policy package (*.pp) files. These files are included in the selinux-policy rpm and are used to build the policy file.

46.2. Building a Local Policy Module

The following section uses an actual example to demonstrate building a local policy module to address an issue with the current policy. This issue involves the ypbind init script, which executes the setsebool command, which in turn tries to use the terminal. This is generating the following denial:

type=AVC msg=audit(1164222416.269:22): avc:  denied  { use } for  pid=1940 comm="setsebool" name="0" dev=devpts ino=2 \
        scontext=system_u:system_r:semanage_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=fd

Even though everything still works correctly (that is, it is not preventing any applications form running as intended), it does interrupt the normal work flow of the user. Creating a local policy module addresses this issue.

46.2.1. Using audit2allow to Build a Local Policy Module

The audit2allow utility now has the ability to build policy modules. Use the following command to build a policy module based on specific contents of the audit.log file:

ausearch -m AVC --comm setsebool | audit2allow -M mysemanage

The audit2allow utility has built a type enforcement file (mysemanage.te). It then executed the checkmodule command to compile a module file (mysemanage.mod). Lastly, it uses the semodule_package command to create a policy package (mysemanage.pp). The semodule_package command combines different policy files (usually just the module and potentially a file context file) into a policy package.

46.2.2. Analyzing the Type Enforcement (TE) File

Use the cat command to inspect the contents of the TE file:

[root@host2a ~]# cat mysemanag.te
module mysemanage 1.0;

require {
        class fd use;
        type init_t;
        type semanage_t;
        role system_r;
};

allow semanage_t init_t:fd use;

The TE file is comprised of three sections. The first section is the module command, which identifies the module name and version. The module name must be unique. If you create an semanage module using the name of a pre-existing module, the system would try to replace the existing module package with the newly-created version. The last part of the module line is the version. semodule can update module packages and checks the update version against the currently installed version.

The next block of the TE file is the require block. This informs the policy loader which types, classes and roles are required in the system policy before this module can be installed. If any of these fields are undefined, the semodule command will fail.

Lastly are the allow rules. In this example, you could modify this line to dontaudit, because semodule does not need to access the file descriptor.

46.2.3. Loading the Policy Package

The last step in the process of creating a local policy module is to load the policy package into the kernel.

Use the semodule command to load the policy package:

[root@host2a ~]# semodule -i mysemanage.pp

This command recompiles the policy file and regenerates the file context file. The changes are permanent and will survive a reboot. You can also copy the policy package file (mysemanage.pp) to other machines and install it using semodule.

The audit2allow command outputs the commands it executed to create the policy package so that you can edit the TE file. This means you can add new rules as required or change the allow rule to dontaudit. You could then recompile and repackage the policy package to be installed again.

There is no limit to the number of policy packages, so you could create one for each local modification you want to make. Alternatively, you could continue to edit a single package, but you need to ensure that the "require" statements match all of the allow rules.

Capítulo 47. Referencias

Las siguientes referencias apuntan a información adicional que es relevante a SELinux y Red Hat Enterprise Linux pero que va más allá del propósito de este manual. Tenga en cuenta que debido al rápido desarrollo de SELinux, este material podría ser aplicable únicamente a un lanzamiento específico de Red Hat Enterprise Linux.

Libros
SELinux by Example

Mayer, MacMillan, and Caplan

Prentice Hall, 2007

Tutoriales y ayuda
Understanding and Customizing the Apache HTTP SELinux Policy

http://fedora.redhat.com/docs/selinux-apache-fc3/

Tutorials and talks from Russell Coker

http://www.coker.com.au/selinux/talks/ibmtu-2004/

Generic Writing SELinux policy HOWTO

https://sourceforge.net/docman/display_doc.php?docid=21959[amp ]group_id=21266

Red Hat Knowledgebase

http://kbase.redhat.com/

Información general
Sitio web principal de NSA SELinux

http://www.nsa.gov/selinux/

NSA SELinux, Preguntas frecuentes

http://www.nsa.gov/selinux/info/faq.cfm

Fedora SELinux, Preguntas frecuentes

http://fedora.redhat.com/docs/selinux-faq-fc3/

SELinux NSA's Open Source Security Enhanced Linux

http://www.oreilly.com/catalog/selinux/

Tecnologías
An Overview of Object Classes and Permissions

http://www.tresys.com/selinux/obj_perms_help.html

Integrating Flexible Support for Security Policies into the Linux Operating System (una historia de la implementación de Flask en Linux, artículo en inglés)

http://www.nsa.gov/selinux/papers/slinux-abs.cfm

Implementing SELinux as a Linux Security Module

http://www.nsa.gov/selinux/papers/module-abs.cfm

A Security Policy Configuration for the Security-Enhanced Linux

http://www.nsa.gov/selinux/papers/policy-abs.cfm

Comunidad
Página de la comunidad SELinux

http://selinux.sourceforge.net

IRC

irc.freenode.net, #rhel-selinux