Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 1
Source Linux
Tabla de contenidos
Linux for SysAdmins
Objetivos
Conceptos básicos
Definición de Linux y distribuciones, usuarios y permisos, el sistema de archivos, gestión de software. Ventajas, desventajas y
escenarios comunes de uso.
Entorno gráfico
Elementos principales de un entorno gráfico GNOME. Aplicaciones comunes de escritorio. Tareas esenciales de manejo de una
sesión gráfica y servidor X.
Laboratorio N° 1
Ejercicios prácticos de acceso a un sistema Linux de manera local y remota, labores rutinarias de escritorio, ofimática y acceso a
Internet.
Objetivos
La Shell BASH
Manejo de comodines de expansión, meta caracteres y variables. Salida estándar, salida de error y entrada estándar.
Redirecciones y tuberías. Secuencialidad de comandos y operadores. Manejo de historial de comandos.
Manejo de archivos
Desplazamiento a través del sistema de archivos. Listar, copiar, renombrar, mover, crear, eliminar, buscar archivos y directorios.
Enlaces simbólicos y enlaces duros. Empaquetamiento y compresión.
Administración de procesos
Visualización de procesos, sus atributos y estados. Envío de señales y manejo de prioridades. Control de procesos en primer y
segundo plano desde la shell.
Laboratorio N° 2
Ejercicios prácticos de manejo de flujos de texto, manipulación de archivos y/o directorios comprimidos. Monitoreo de procesos y
uso conjunto desde el VIM en primer y segundo plano.
Objetivos
Particionamiento simple
Identificación y nomenclatura de dispositivos. Conceptos de particionamiento en discos IDE y SCSI, tipos de particiones. Creación y
eliminación de particiones.
Formato de dispositivos
Gestión de dispositivos para SWAP. Creación de sistemas de archivos ext3 y vfat. Asignación de etiquetas y consulta de
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 2
Source Linux
información de dispositivos.
Montaje
Conceptos fundamentales. Montaje manual de dispositivos. Montaje automático y simplificado basado en /etc/fstab. Opciones
especiales de montaje según sistema de archivos.
Laboratorio N° 3
Ejercicios prácticos de asignación de espacio libre en disco para creación de sistemas de archivos adicionales.
Objetivos
Control de contraseñas
Bloqueo y desbloqueo de cuentas de usuarios. Asignación de contraseñas de usuario y grupo. Políticas de expiración de
contraseñas.
Laboratorio N° 4
Ejercicios prácticos de administración de usuarios y grupos con cuotas y políticas de contraseñas.
Objetivos
Permisos y propietarios
Conceptos fundamentales previos. Modificación de permisos básicos, propiedad de objetos y permisos por defecto. Permisos
especiales de SUID, SGID y Sticky Bit. Gestión avanzada de permisos con ACL (Access Control List).
Ejecución privilegiada
Convertirse a root en la shell. Ejecución de aplicaciones como root con control granular.
Laboratorio N° 5
Ejercicios prácticos de ejecución de comandos con privilegios escalados.
Objetivos
Laboratorio N° 6
Ejercicios prácticos de gestión de Logical Volumes redundantes (configuración de espejo) y redimensionamiento 'en caliente'.
Unidad 7: Instalación
Objetivos
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 3
Source Linux
Servidor gráfico X, instalación de Linux y sesiones en consolas virtuales.
Laboratorio N° 7
Instalación desde red vía HTTP. Instalación automatizada usando Kickstart.
Objetivos
Laboratorio N° 8
Ejercicios prácticos de instalación manual de Webmin y software adicional desde repositorios de Internet. Compilación e instalación
de Apache y PHP.
Objetivos
Programación de tareas
Tareas periódicas con cron, configuración global de /etc/crontab y tareas por usuario. Tareas postergadas con at, configuración de
fecha y hora de ejecución de aplicaciones.
Laboratorio N° 9
Ejercicios prácticos de instalación de un módulo de kernel desde las fuentes y automatización de tareas con cron y scripts de shell.
Objetivos
Utilitarios de red
Herramientas de configuración y consulta manual de parámetros de red, conexiones activas, trazado de rutas, escaneo de puertos
y análisis de tráfico con promiscuidad de interfaz de red. Shell y copia remota de archivos usando OpenSSH. SSH basado en
llaves.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 4
Source Linux
Ejecución de aplicaciones GUI remotas usando SSH X11 Forwarding. Configuración de servidor VNC/XDMCP. Conexión a
plataformas Windows usando escritorio remoto.
Laboratorio N° 10
Ejercicios prácticos de configuración de un escenario de red para producción y ajustes para entorno. Resolución de problemas
comunes.
Objetivos
Servicio DHCP
Conceptos básicos de DHCP. Instalación y configuración de servicio DHCP. Asignación de direcciones IP por rangos y otros
parámetros de configuración de red. Reserva de direcciones IP basados en dirección MAC de cliente. Administración del servicio
DHCP desde Webmin.
Servicio DNS
Conceptos básicos de DNS. Instalación y configuración de servicio DNS con BIND. Configuración de zonas de búsqueda directa y
reversa con rol de maestro y esclavo. Edición de archivos de zonas. Administración del servicio DNS/BIND desde Webmin.
Herramientas DNS de línea de comandos.
Servicio NTP
Conceptos básicos de NTP. Instalación y configuración del servicio NTP como cliente y servidor. Sincronización NTP manual desde
línea de comandos.
Laboratorio N° 11
Taller práctico de configuraciones diversas de asignación dinámica de direcciones IP, sincronización de tiempo y administración de
zonas DNS.
Objetivos
Laboratorio N° 12
Taller práctico de compartición de impresoras con Samba e instalación automática de drivers desde estaciones Windows. Mapeo
de usuarios de Active Directory como cuentas locales de Linux.
Objetivos
Certificados digitales
Conceptos básicos de criptografía, OpenSSL, certificados digitales y sus usos comunes. Gestión de autoridades certificadoras
certificados digitales.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 5
Source Linux
usuarios y hosts. Configuración por directorio con archivos .htaccess. Publicación de recursos bajo conexiones seguras (HTTPS)
con certificados digitales. Dominios virtuales basados en IP para sitios Web seguros. Administración de Apache desde Webmin.
Laboratorio N° 13
Taller práctico de publicación de diversos Websites y dominios virtuales con URLs protegidas bajo conexiones seguras.
Objetivos
Laboratorio N° 14
Taller práctico de implementación de reglas de Firewall.
Objetivos
Laboratorio N° 15
Taller práctico de implementación de un Proxy transparente para controlar por horarios el MSN y otros tipos de chat. Control de
sitios Web genéricos de contenido multimedia (música y/o video en línea). Integración con Active Directory.
Objetivos
Laboratorio N° 16
Implementación de OpenVPN con conexión net-to-net. Integración de OpenVPN con Active Directory para validación de
credenciales de usuarios. Configuración de reglas necesarias de Shorewall para un correcto funcionamiento del sistema VPN con
OpenVPN.
Objetivos
Laboratorio N° 17
Taller práctico de implementación de Openfire utilizando MySQL como backend e integrado con Active Directory para la validación
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 6
Source Linux
de credenciales de usuarios. Conexión desde estaciones Windows.
Objetivos
Laboratorio N° 18
Taller práctico de implementación de una libreta de direcciones con OpenLDAP y su integración desde un cliente de correo como
Microsoft Outlook o Mozilla Thunderbird.
Objetivos
Webmail y monitoreo
Instalación y configuración de Webmail Horde integrado con Cyrus IMAP y Postfix usando MySQL como backend. Módulos de
gestión de contraseñas y mensajes de vacaciones.
Instalación y configuración de MailWatch como herramienta de monitoreo y administración de rutina del correo electrónico.
Laboratorio N° 19
Taller práctico de implementación de un sistema de correo electrónico completo basado utilizando los componentes aprendidos.
Objetivos
Laboratorio N° 20
Taller práctico de instalación de Red Hat Enterprise Linux 5 / CentOS 5 como guest paravirtualizado.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 7
Source Linux
Convenciones usadas en el libro
Este libro utiliza ciertas convenciones en cuanto a tipografía y símbolos para la enseñanza de ciertos temas que requieren ser
enfatizados. Esto incluye palabras con significados especiales, comandos de consola, parámetros de comandos, contenidos de
archivos de configuración, entre otros, los cuales tienen por objetivo facilitar la lectura y el aprendizaje acorde a las explicaciones de
abajo.
• Texto Arial y cursiva hace referencia a texto que tiene cierto significado especial que lo diferencia del párrafo.
• Texto Courier New y negrita hace referencia a comandos de Shell.
• Texto Courier New y normal hace referencia a caracteres especiales y texto que arrojan los comandos de Shell.
• Texto Courier New y subrayado hace referencia al texto que debe ser ingresado por el usuario en la Shell.
• Texto Times New Roman y cursiva hace referencia a rutas de archivos y/o directorios.
Sintaxis de comandos
Adicionalmente, será muy común dar detalles sobre el uso de comandos y sus parámetros para lo cual se usarán expresiones del tipo:
Donde:
Caracteres especiales
Existen ciertos caracteres que tienen especial significado dependiendo del ámbito donde se les haga referencia. Estos son:
Ejemplos:
Referencia a documentación
A menudo cuando se dan explicaciones en este documento se suele hacer mención a la posibilidad de consultar fuentes adicionales de
documentación sobre el tema tratado, y muchas de esas están disponibles en las páginas man (documentación del sistema) las cuales
están organizadas por secciones numéricas y cada una lleva un nombre particular.
Es así que la documentación completa del comando mkdir está disponible en su página man, la cual desde una shell de comandos se
consulta así:
$ man 1 mkdir
o simplemente
$ man mkdir
Pero por brevedad se ha de mencionar esto como mkdir(1). Por ejemplo se puede expresar lo siguiente: "para más información
consulte mkdir(1)" que quiere decir que debe revisarse la página man de mkdir en la sección 1, tal como se mostró en el ejemplo de
arriba.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 8
Source Linux
Unidad 1: Introducción al Mundo Linux
1.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Entender qué es Linux como sistema operativo, sus orígenes, su estado actual y los usos más comunes en el mercado.
✔ Comprender las características básicas del sistema operativo que lo diferencian con sistemas Microsoft Windows.
✔ Conocer las dos interfaces comunes de un sistema Linux y los entornos de escritorio disponibles
✔ Desempeñar tareas esenciales de uso del sistema en una sesión gráfica
✔ Desenvolverse por primera vez ante un sistema Linux a través de las consolas virtuales usando comandos básicos
¿Qué es GNU?
Richard Stallman, fundador del proyecto GNU y la FSF (Free Software Foundation) buscaba la creación de un sistema UNIX que fuese
libre, que encajase en la definición de software libre y es así como nace el proyecto GNU, "GNU is not UNIX". Los integrantes de este
proyecto empezaron así entonces a crear herramientas para ese futuro sistema operativo como editores de texto, compiladores,
debuggers entre otros.
Crearon muchas herramientas pero no la parte más importante que es el kernel, el núcleo...
¿Qué es Linux?
En el año 1991, un estudiante finlandés llamado Linus Torvalds, empezó a querer crear una versión de Minix, otro sistema UNIX, para
computadoras personales, lográndolo y llamándolo Linux. Linux era entonces solamente un kernel, un núcleo de sistema operativo el
cual requería obviamente otras herramientas para su funcionamiento.
Distribuciones
Una distribución es una variante del sistema GNU/Linux que se enfoca a satisfacer las necesidades de un grupo especifico de
usuarios. De este modo hay distribuciones para hogares, empresas y servidores. Algunas distribuciones son completamente libres,
pero muchas no lo son.
Las distribuciones son ensambladas por individuos, empresas u otros organismos. Cada distribución puede incluir cualquier número de
software adicional, incluyendo software que facilite la instalación del sistema. La base del software incluido con cada distribución
incluye el núcleo Linux y las herramientas GNU, al que suelen añadirse también varios paquetes de software.
Las herramientas que suelen incluirse en la distribución de este sistema operativo se obtienen de diversas fuentes, y en especial de
proyectos de software libre, como: GNU , BSD, GNOME y KDE. También se incluyen utilidades de otros proyectos como Mozilla, Perl,
Ruby, Python, PostgreSQL, MySQL, Xorg, casi todas con licencia GPL o compatibles con ésta (LGPL, MPL).
Usualmente se utiliza la plataforma X.Org Server, basada en la antigua XFree86, para sostener la interfaz gráfica.
Con la adopción por numerosas empresas fabricantes, un buen número de computadoras se venden con distribuciones pre-instaladas,
y GNU/Linux ha comenzado a tomar su lugar en el vasto mercado de las computadoras de escritorio.
Entre las distribuciones Linux más populares se encuentran Debian, Ubuntu, Red Hat, Fedora, CentOS, Mandriva, SuSE, Gentoo, etc.
Usos y mercado
En entornos de escritorio, GNU/Linux ofrece una interfaz gráfica alternativa a la tradicional interfaz de línea de comandos de Unix.
Existen en la actualidad numerosas aplicaciones gráficas que ofrecen la funcionalidad que está permitiendo que GNU/Linux se adapte
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 9
Source Linux
como herramienta de escritorio.
Muchas distribuciones permiten el arranque del sistema directamente desde un CD/DVD (llamados CD/DVD autónomos o "vivos") sin
modificar en absoluto el disco duro del ordenador en el que se ejecuta GNU/Linux. Para este tipo de distribuciones, en general, los
archivos de imagen (archivos ISO) están disponibles en Internet para su descarga.
Otras posibilidades incluyen iniciar el arranque desde una red (ideal para sistemas con requerimientos mínimos), desde un disco
flexible o disquete o desde unidades de almacenamiento USB.
Documentación adicional
Historia de Linux
http://es.wikipedia.org/wiki/Historia_de_Linux
El sistema de archivos
En un sistema UNIX, la base de la estructura de directorios es la raíz "/" así como en sistemas Windows lo son C:\, D:\, E:\. A
diferencia de Windows, en un sistema UNIX no se usan letras ni diferentes símbolos para representar las distintas
particiones.
Todo el sistema de archivos cuelga bajo la raíz / y así sus ficheros y directorios. Así, los siguientes son ejemplos de
representación de rutas de archivos y/o directorios:
/dev (Directorio)
/etc/login.defs (Archivo)
A diferencia de Windows en donde puede usarse indistintamente los símbolos \ ó / para representar las rutas, en un sistema
UNIX solamente se permite el símbolo /
La partición en la cual se instala la base del sistema de archivos se conoce como la partición root, la que conocíamos como
raíz / también
Una partición swap es un espacio reservado para intercambio que será usado como memoria virtual cuando se acabe la
memoria RAM del sistema. Se recomienda que su tamaño sea aproximadamente el doble de la cantidad de memoria RAM
del computador.
Los dispositivos así como todo lo que existe en un sistema UNIX se maneja como archivos. La carpeta donde se ubican los
ficheros para acceder a los dispositivos es /dev, así el dispositivo que reconoce la lectora de CD-ROM es /dev/cdrom, el
dispositivo que reconoce la primera unidad de floppy es /dev/fd0
La sensibilidad a mayúsculas sí es válida en cualquier sistema UNIX, tanto en los nombres de archivos como en las órdenes
de línea de comandos (que a fin de cuentas no son más que archivos también). Por ejemplo hacen referencia a distintos
archivos /tmp/makefile y /tmp/Makefile
Los archivos ocultos en un sistema UNIX se les identifica cuando llevan un punto '.' por delante. Por ejemplo .xinitrc en
nuestro directorio personal es un archivo oculto.
Usuarios y permisos
Linux al igual que otros sistemas UNIX se caracterizan por ser multiusuarios, esto quiere decir que el sistema operativo tiene
la capacidad de atender de manera concurrente las tareas de múltiples usuarios a él conectados.
También existen grupos que no son más que un conjunto de usuarios reunidos bajo una única instancia con nombre y
atributos propios.
Existe un único usuario denominado root el cual es el administrador del sistema. Este usuario tiene permiso sobre todo, se le
permite ejecutar cualquier acción o cambio en el sistema operativo. La cuenta de este usuario debe ser usada con recelo
solamente en operaciones administrativas.
El hecho que existan diversos usuarios obliga la existencia de mecanismos de control que preserven el orden y consistencia
del sistema entero. Este mecanismo son los permisos que permiten asignar niveles granulares de control sobre archivos,
procesos, dispositivos y otros objetos para cada usuario de modo tal que uno de ellos no interfiera con las tareas u objetos
de otros.
Para Linux como también para otros sistemas UNIX siempre hay software disponible en formato binario, es decir software
que está listo para ser instalado y usado. Este tipo de software binario viene empaquetado en formatos específicos
generalmente propios de cada sistema operativo; así por ejemplo Red Hat y SuSE manejan sus paquetes binarios en
formato RPM que son archivos de extensión .rpm, mientras que Debian maneja el formato DEB que son archivos de
extensión .deb.
Pero también es muy común que se distribuya el software en código fuente a través de tarballs (archivos empaquetados y/o
comprimidos que por lo general contienen código fuente de algún software). Estos tarballs están disponibles comúnmente en
el sitio Web oficial del proyecto de software desde el cual podemos descargarlo para luego desempauetarlo/descomprimirlo,
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 10
Source Linux
compilarlo e instalar en el sistema los binarios producidos producto del proceso de la compilación.
• X Window System (sistema de ventanas X): Protocolo diseñado para proveer de una interfaz gráfica a sistemas de
computadora en red. Este protocolo brinda las primitivas básicas (dibujar y mover ventanas, y la interacción con el ratón y
teclado) para construir entornos de escritorio completos mas no tiene como función la realización de tareas específicas o
personalizadas sobre las ventanas (estilo y/o color de ventanas, combinación de teclas para rotar/minimizar ventanas,
protector y/o fondo de pantalla).
Generalmente se hace referencia a este protocolo en su versión 11 como X11.
• Xfree86 y X.Org: Ambos son implementaciones Open Source de X Window System diseñadas para sistemas operativos
UNIX y clónicos (incluye Linux). X.Org nace como una derivación del proyecto XFree86 debido a un cambio de
licenciamiento y es el más utilizado por los sistemas Linux (Debian, Red Hat, Slackware, Mandriva, openSUSE, etc) en la
actualidad.
• Window Manager (administrador de ventanas): Aplicación que corre bajo un sistema de ventanas encargada de controlar
la ubicación y apariencia de ventanas como funciones básicas del sistema operativo. Ejemplo de algunas de las tareas de las
cuales es responsable son: abrir, cerrar, minimizar, maximizar, rotar (Alt+Tab). También un Window Manager puede incluir
elementos adicionales tales como una barra de tareas, bandeja de sistema, reloj, iconos, fondo de escritorio, entre otros.
Algunos de los Window Manager más comunes son: Enlightenment, Fluxbox, Kwin (forma parte de KDE), Metacity (forma
parte de GNOME), WindowMaker, IceWM.
• Display Manager (administrador de pantalla): Aplicación que corre sobre un servidor gráfico y es un complemento común
de todo sistema de ventanas. Tiene como función el controlar el inicio de sesión en una computadora local o remota a través
de una pantalla gráfica en la cual se pide un nombre de usuario y su respectiva contraseña del sistema.
Algunos de los Display Manager más comunes son: XDM (forma parte de un X Window System), GDM (forma parte de
GNOME), KDM (forma parte de KDM).
• Desktop Environment (entorno de escritorio): Conjunto de aplicaciones que corren sobre un sistema de ventanas que
tiene como función el brindar una sesión gráfica interactiva, amigable y cómoda a los usuarios finales de computadoras.
Agrupa de forma global funcionalidades que van desde el manejo de ventanas (abrir, cerrar, minimizar, etc, a través de su
propio window manager), inclusión de elementos variados de escritorio (barras de tarea, menú de aplicaciones, applets como
reloj, monitor de batería, etc) y preferencias avanzadas (fondo y protector de pantalla, temas/skins de escritorio, arrastrar y
soltar elementos, etc).
Algunos de los Desktop Environment más comunes son: GNOME, KDE, XFCE, LXDE, CDE (común en sistemas Solaris).
Combinaciones de tecla
importante tener en cuenta las siguientes combinaciones de teclas de uso común en un entorno gráfico Linux:
• Ctrl + Alt + Supr : Comúnmente en KDE y GNOME permite cerrar la sesión, reiniciar y/o apagar el sistema.
• Ctrl + Alt + L : Comúnmente en KDE y GNOME permite bloquear la sesión.
• Alt + F2 : Comúnmente en KDE y GNOME abre el díalogo 'Ejecutar' para correr un comando.
• Ctrl + Alt + D : Comúnmente en KDE y GNOME muestra el escritorio (minimiza todas las ventanas).
• Ctrl + Alt + Escape : Reiniciar la sesión X. Es un cierre brusco que mata todas las aplicaciones gráficas de inmediato.
El entorno gráfico también ofrece facilidades para el manejo de ventanas y portapapeles a través del uso conjunto del teclado y ratón:
• Alt + Clic izquierdo + Movimiento : Manteniendo presionados el botón izquierdo del ratón y la tecla Alt, se puede
desplazar la ventana según el movimiento del ratón.
• Alt + Clic derecho + Movimiento : Manteniendo presionados el botón derecho del ratón y la tecla Alt, se puede
redimensionar la ventana según el movimiento del ratón (Sólo en KDE).
• Alt + Clic central + Movimiento : Manteniendo presionados el botón central del ratón (cuando existen 3 botones) y la
tecla Alt, se puede redimensionar la ventana según el movimiento del ratón (Sólo en GNOME).
• Selección de texto con clic izquierdo : Copia al portapapeles el texto seleccionado con el botón izquierdo del ratón.
• Clic central : Pega el texto guardado en el portapapeles
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 11
Source Linux
Es importante tener en cuenta que en equipos con ratones de 2 botones es posible emular el funcionamiento de un 3er. botón
presionando a la vez los dos botones (izquierdo y derecho).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 12
Source Linux
1.4. Entorno de línea de comandos
Introducción
Los sistemas operativos Linux así como cualquier otro UNIX se caracterizan por disponer de dos interfaces de usuario: la interfaz
gráfica y la interfaz de línea de comandos (conocido también comúnmente también sólo como modo texto, shell o consola).
Si bien es cierto que la interfaz gráfica de las versiones más modernas de distribuciones Linux son cada vez más amigables e intuitivas
es necesario reconocer que el máximo potencial administrativo de este sistema operativo no es a través de herramientas GUI sino por
el contrario a través del manejo directo de la línea de comandos.
Es por ello que prácticamente la totalidad de este curso se centra en la enseñanza de labores de administración a través de la línea de
comandos para lo cual podremos trabajar en una de las consolas virtuales o en una terminal de comandos desde una sesión gráfica en
GNOME o KDE.
Consolas virtuales
Linux implementa por defecto seis consolas virtuales. Éstas funcionan como emulaciones de terminal conectados al sistema que
permiten interactuar con éste a través del teclado y ratón.
Sin embargo son muy pocas las aplicaciones ejecutadas en consolas virtuales (o terminal de comandos) que permiten aprovechar la
funcionalidad del ratón.
Inicio de sesión
Dependiendo de los paquetes que hayan sido seleccionados en el momento de la instalación de Linux es posible que éste arranque
por defecto en modo texto o modo gráfico. Sin importar cuál sea el modo de arranque por defecto es cierto que al situarnos en una de
las consolas virtuales tendremos una pantalla similar a una de las siguientes:
Los ejemplos arriba mostrado representan la pantalla de inicio de sesión en una consola virtual de un sistema Linux, el de la izquierda
correspondiente a un sistema con Debian y el de la derecha al de un sistema CentOS.
No importa cómo muestren la información de inicio de sesión hay que rescatar que siempre:
• Se muestra el nombre del sistema operativo en la parte superior (Debian o CentOS) y otros datos adicionales (1)
• A la izquierda de la palabra login se muestra el nombre del sistema (hostname)
Esta pantalla nos dice que el sistema está listo para que nosotros iniciemos sesión para lo cual debemos escribir nuestro nombre de
usuario (a la derecha de la palabra login) y luego de presionar [Enter] escribiremos la contraseña respectiva.
Cabe resaltar que mientras escribimos la contraseña ésta no se hará notar en la pantalla como caracteres asterisco (*****), sino que
quedará oculto a nuestra vista, por lo que no debemos asombrarnos si no vemos nada mientras escribimos la contraseña.
Prompt de Shell
Luego de iniciar sesión en una consola virtual podremos observar lo siguiente:
Last login: Thu Oct 8 21:17:13 PET 2009 on tty1 < Último login
Linux angel 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright. < Message of the day
Donde:
• La primera línea corresponde a la fecha y hora del último inicio de sesión en la consola virtual número 1 (tty1)
• Desde la segunda hasta la penúltima línea hasta corresponde al mensaje de bienvenida del sistema o message of the day (2)
que puede estar existir o no por defecto en algunas distribuciones Linux.
• La última línea es el prompt de Shell, que muestra información tal como el usuario logueado, nombre del sistema, ubicación
actual en el sistema de archivos, indicador de usuario $ o # (consultar pag. 8) u otra información personalizable (consultar La
Shell Bash en la Unidad 2 de este manual)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 13
Source Linux
(1) El texto mostrado en este indicador de entrada puede ser personalizado en el archivo /etc/issue. Consultar también issue(5) y
getty(8) o mingetty(8)
(2) El texto mostrado como bienvenida o message of the day (motd) es puede ser personalizado en el archivo /etc/motd.
Consultar también motd(5)
Combinaciones de tecla
Es importante tener en cuenta las siguientes combinaciones de teclas de uso común en un entorno de línea de comandos Linux:
• Alt + FN : Cambia desde una consola a hacia la consola virtual número N (cualquier número entre 1 y 6).
• Ctrl + Alt + F7 : Cambia desde cualquiera de las consolas virtuales hacia la sesión gráfica.
• Ctrl + Alt + FN : Cambia de la sesión gráfica a la consola virtual número N (cualquier número entre 1 y 6).
* El comando chvt N (ejecutado como root) también permite cambiar a la consola virtual número N
Cierre de sesión
Una sesión de línea de comandos puede ser cerrada de una de las siguientes formas:
-r : Reinicia el sistema
-h : Apaga el sistema
-c : Cancela un apagado en curso ya programado
-k : No reinicia ni apaga, sólo envía un mensaje a todos los usuarios del sistema
tiempo puede especificarse usando el formato hh:mm (hora y minuto) o +N (N minutos a esperar). La palabra now es sinónimo de +0
De manera alterna se puede utilizar el comando reboot para reiniciar y poweroff o halt para apagar el sistema.
(3) Se puede desactivar esta combinación de teclas a través de la configuración del archivo /etc/inittab (Comentar la línea que
empieza con ca:12345:ctrlaltdel)
Ejemplos:
# shutdown -h +10
# shutdown -r now
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 14
Source Linux
explicación muchas veces bien detallada de una serie de aspectos importantes del sistema los cuales están clasificados por secciones
como se muestra a continuación:
Sección Descripción
1 Programas ejecutables y guiones del intérprete de órdenes
2 Llamadas del sistema (funciones servidas por el núcleo)
3 Llamadas de la biblioteca (funciones contenidas en las bibliotecas del sistema)
4 Ficheros especiales (se encuentran generalmente en /dev)
5 Formato de ficheros y convenios p.ej. I/etc/passwd
6 Juegos
7 Paquetes de macros y convenios p.ej. man(7), groff(7).
8 Órdenes de admistración del sistema (generalmente solo son para root)
9 Rutinas del núcleo [No es estándar]
Forma de uso:
-P paginador : Utiliza el comando paginador para mostrar el contenido de la página. Por defecto se usa less como paginador.
-w : Sólo muestra la ruta del archivo que contiene la página man
-a : Muestra todas las páginas man que coincidan con el tema buscado
sección : Sección en la que se buscará la página man acorde a la tabla arriba mostrada. Si se omite este parámetro se
buscará automáticamente la primera página man que coincida con el criterio buscado.
tema : Patrón de texto que define el tema de interés a buscar en la documentación
Ejemplos:
# man 1 crontab
2. Consultar todas las páginas man que coincidan con crontab y mostrarlo usando el comando cat:
Comandos comunes
• $ clear
Limpia la pantalla
• $ reset
Resetea la pantalla cuando ésta se avería con caracteres ilegibles (Por ejm. al correr $ cat /bin/ls).
• $ free -m
Muestra la información de memoria disponible del sistema.
• $ uname -a
Muestra información del sistema como kernel, arquitectura, nombre de host, entre otros.
• $ lspci
Muestra información de los buses PCI y dispositivos conectados a ellos. El parámetro -k informa su driver asociado.
• $ cat /proc/cpuinfo
Consulta información del procesador del sistema.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 15
Source Linux
• $ dmesg
Muestra los últimos eventos reportados por el kernel.
• $ whoami
Indica qué usuario es con el cual estamos actualmente logueados
• $ who
Muestra los usuarios actualmente logueados al sistema
• $ last
Muestra los últimos accesos al sistema
• $ date
Muestra la fecha y hora del sistema
Consultar la documentación (páginas man) de cada uno de los comandos listados para tener información completa sobre sus
parámetros y forma de uso, en especial del comando date
# ifconfig
# ethtool eth0
3. Probar conectividad con otro host en la red (se cancela el comando con ^C)
$ ping 192.168.1.1
$ host www.kernel.org
$ ssh admin@192.168.1.30
The authenticity of host '192.168.1.30 (192.168.1.30)' can't be established.
RSA key fingerprint is 6d:1b:bc:18:9a:81:11:1d:e4:97:52:40:1e:7c:72:8a.
Are you sure you want to continue connecting (yes/no)
En ambos casos si nos conectamos por primera vez a dicho host se nos preguntará si deseamos proceder (aún no conoce la identidad
de ese host y nos advierte) a lo cual nosotros responderemos escribiendo 'yes' (almacenando su identidad para no consultarnos en el
futuro) y luego introduciremos el password del usuario respectivo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 16
Source Linux
Last login: Mon Oct 8 19:22:32 2009
$ admin@mailserver:~$
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 17
Source Linux
1.5. Laboratorio N° 1
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Inicie una sesión gráfica a través del Display Manager con el usuario y contraseña sin privilegios especificado por el docente,
luego inicie sesión también con el mismo usuario desde una de las consolas virtuales. Analice la lista de usuarios logueados
al sistema antes y después de cerrar alguna de las sesiones abiertas.
2. Tras iniciar una sesión gráfica identifique los elementos del escritorio, agregue un acceso directo en el escrito para el
navegador Mozilla Firefox e intente navegar por algún sitio de Internet.
3. Analice el hardware del equipo (memoria, arquitectura y características del procesador, dispositivos PCI), e investigue qué
controladores o drivers están asociados a cada uno de ellos.
4. Inicie una sesión remota vía SSH con un usuario sin privilegios en otro ordenador de la red local. Analice los usuarios
logueados al sistema y el registro de los últimos inicios de sesión de ese host remoto.
5. Reinicie el sistema con una programación postergada de cinco minutos. Intente hacerlo como un usuario sin privilegios y
analice el problema ocurrido. Intente nuevamente realizar la tarea como usuario root.
6. Inicie una sesión gráfica como el usuario root y personalice el indicador de entrada (el que se muestra en la pantalla de inicio
de sesión de las consolas virtuales) de modo tal que se muestre siempre la versión del kernel, la fecha y la hora actual.
Compruebe que los cambios se hayan aplicado tras cerrar y abrir sesión en una consola virtual.
Apóyese de issue(5), getty(8) o mingetty(8).
7. En la sesión gráfica ya iniciada anteriormente modifique también el mensaje de bienvenida o motd (message of the day) para
incluir una advertencia personalizada que sea de su agrado. Compruebe que los cambios se hayan aplicado tras cerrar y
abrir sesión en una consola virtual.
Apóyese de motd(5).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 18
Source Linux
1.5.1 Solución del laboratorio N° 1
1. Inicie una sesión gráfica a través del Display Manager con el usuario y contraseña sin privilegios especificado por el docente,
luego inicie sesión también con el mismo usuario desde una de las consolas virtuales. Analice la lista de usuarios logueados
al sistema antes y después de cerrar alguna de las sesiones abiertas.
$ who
2. Tras iniciar una sesión gráfica identifique los elementos del escritorio, agregue un acceso directo en el escrito para el
navegador Mozilla Firefox e intente navegar por algún sitio de Internet.
+ En GNOME: Ir al menú "Aplicaciones -> Internet -> Firefox Web Browser", dar clic derecho y elegir la opción "Añadir este
lanzador al escritorio"
3. Analice el hardware del equipo (memoria, arquitectura y características del procesador, dispositivos PCI), e investigue qué
controladores o drivers están asociados a cada uno de ellos.
$ free -m
$ uname -a
$ cat /proc/cpuinfo
+ Dispositivos PCI y sus drivers asociados a cada uno de ellos (no disponible en sistemas Red Hat):
$ lspci -k
4. Inicie una sesión remota vía SSH con un usuario sin privilegios en otro ordenador de la red local. Analice los usuarios
logueados al sistema y el registro de los últimos inicios de sesión de ese host remoto.
$ who
$ last
5. Reinicie el sistema con una programación postergada de cinco minutos. Intente hacerlo como un usuario sin privilegios y
analice el problema ocurrido. Intente nuevamente realizar la tarea como usuario root y cancele el reinicio.
$ shutdown -r +5
-bash: shutdown: command not found
$ /sbin/shutdown -r +5
shutdown: you must be root to do that!!
# shutdown -r +5
Broadcast message from root (pts/1) (Tue Oct 10 10:20:32 2009)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 19
Source Linux
^C
6. Inicie una sesión gráfica como el usuario root y personalice el indicador de entrada (el que se muestra en la pantalla de inicio
de sesión de las consolas virtuales) de modo tal que se muestre siempre la versión del kernel, la fecha y la hora actual.
Compruebe que los cambios se hayan aplicado tras cerrar y abrir sesión en una consola virtual.
Apóyese de issue(5), getty(8) o mingetty(8).
+ En GNOME: Ir al menú "Aplicaciones -> Accesorios -> Editor de textos", y dar clic. Abrir el archivo /etc/issue y editarlo como
sigue:
7. En la sesión gráfica ya iniciada anteriormente modifique también el mensaje de bienvenida o motd (message of the day) para
incluir una advertencia personalizada que sea de su agrado. Compruebe que los cambios se hayan aplicado tras cerrar y
abrir sesión en una consola virtual.
Apóyese de motd(5).
+ En GNOME: Ir al menú "Aplicaciones -> Accesorios -> Editor de textos", y dar clic. Abrir el archivo /etc/motd y editarlo como
sigue:
Por favor realice sólo actividades relacionadas a su trabajo. Toda accion estara siendo
registrada en el sistema.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 20
Source Linux
Unidad 2: Comandos GNU y Unix
2.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
La shell es quizás la interface de comunicación más antigua que existen en los sistemas informáticos, disponibles en la actualidad para
sistemas operativos Unix, Windows, Solaris, equipos embebidos como routers, switches, etc.
BASH
Bash es quizás la Shell más popular entre sistemas operativos Linux, incluida como shell por defecto en distribuciones como Red Hat,
openSUSE, Debian, entre otros.
Se caracteriza por ser muy flexible, dotado de características avanzadas y muchas de ellas no disponibles en otras shell tal como
autocompletado de nombres de archivos/programas con TAB, acceso a parámetros pasados por shell, operaciones matemáticas con
enteros, redirecciones de entrada/salida, comparación de texto en expresiones regulares, entre otros.
Es por ello que este manual asumirá en su totalidad que la shell a estudiar y usar es BASH.
Variables
Bash maneja variables de manera similar a como cualquier lenguaje de programación, con la limitación del nombre de ellas a valores a
caracteres alfanuméricos.
Las variables no tienen un tipo asociado a ellas (entero, punto flotante, cadena, etc) ni tampoco se les requiere definir antes de usarlas.
Simplemente se les asigna un valor en cualquier momento dado para empezar a trabajar con ella.
La forma de uso de las variables se muestra a continuación:
Variables globales
Por defecto cualquier variable que nosotros definamos tiene un ámbito local a no ser que especifiquemos lo contrario. Las variables
locales son aquellas que existen sólo desde la visión del actual proceso en ejecución pero inaccesible totalmente por otros procesos.
Por ejemplo las variables NOMBRE, A y B definidas arriba pueden ser visualizadas en nuestra sesión de shell actual pero no pueden ser
vistas por un script que nosotros invoquemos desde esta shell en uso.
En cambio las variables globales tienen la particularidad que son accesibles no sólo desde el proceso actual que las inicializó, sino
también desde todos sus procesos hijo. Esto quiere decir que los procesos que se invoquen desde dicho proceso (la shell actual por
ejemplo) también podrán hacer uso de dichas variables.
Algunos de los comandos que están relacionados al uso de las variables son los siguientes:
• $ echo
Muestra texto en pantalla, incluyendo el resultado de lectura de variables.
• $ export
Permite inicializar y/o convertir en global las variables
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 21
Source Linux
• $ set
Imprime un listado de las variables definidas en nuestra sesión de shell actual. Incluye las variables locales y globales.
• $ env
Imprime un listado de las variables definidas en nuestra sesión de shell actual. Incluye sólo las variables globales.
• $ unset
Elimina el valor de una variable
Ejemplo 1:
Consultar el valor de la variable EDITOR, asignarle como valor el nombre de un programa de edición (nano, vim, kate, gedit, u
otros) y analizar el comportamiento del comando crontab (proceso invocado desde la shell) cuando la variable tiene un ámbito local y
global.
$ echo $EDITOR
$ set
b) Ejecutemos el comando crontab e identifiquemos qué editor de texto se nos presenta en pantalla:
$ crontab -e
c) La aplicación crontab por defecto ejecutará el editor definido en la variable EDITOR, sólo si ésta está exportada (es global). Así que
probaremos darle un valor sin exportarla y luego ejecutar crontab nuevamente:
$ EDITOR=vim
$ crontab -e
d) Resulta que el mismo editor que la vez anterior es el que se nos mostró. Ahora exportemos la variable:
$ export EDITOR=vim
$ crontab -e
e) ¿Se ha notado qué editor se ejecutó ahora? ¿Qué editor se muestra ahora en el próximo ejemplo?
$ export EDITOR=gedit
$ crontab -e
$ set
$ env
$ unset EDITOR
$ crontab -e
Variables importantes
El siguiente es un listado de algunas de las variables más importantes en la shell Bash.
Variable Significado
HOME Directorio personal del usuario
SHELL Ruta de la shell o intérprete de órdenes en ejecución
USER Usuario actual logueado en la shell.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 22
Source Linux
PATH Lista de directorios separados por dos puntos ":" donde la shell buscará las aplicaciones a ejecutar cuando éstas se
invocan sin incluir la ruta absoluta.
PWD Nuestra ubicación en el sistema de archivos
HOSTNAME Nombre del sistema
PPID El PID del proceso padre
PS1 Define la forma que tiene el prompt de la línea de comandos cuando la Shell está lista para aceptar órdenes
PS2 Define el caracter que se muestra como prompt secundario al partir una sentencia en múltiples líneas con \
Define el programa de edición que por defecto se utilizará para herramientas tales como crontab, edquota u
EDITOR
otros que en su ejecución necesitan utilizar algún editor de textos.
Cabe resaltar que la variable PS1 puede incluir en su definición ciertos caracteres especiales con significados particulares como se
describe abajo:
Existen otros caracteres especiales que están documentados en bash(1) sección PROMPTING.
Esto permite que los procesos tomen datos por el descriptor 0 (entrada estándar), arrojen los resultados por el descriptor 1 (salida
estándar) y muestren los errores por el descriptor 2 (salida de error).
En la práctica esto significa que la entrada estándar se toma desde el teclado mientras que la salida estándar y salida de error son
mostrados a través de la pantalla.
Visualmente no es fácil distinguir una salida estándar de una salida de error, pues ambos se ven como texto en la pantalla. Sin
embargo es importante comprender que la salida de error es usado por las aplicaciones para mostrar mensajes de error, advertencia o
diagnóstico, generalmente para informar que algo no está funcionando como se esperaba.
Redirecciones
Una redirección es un mecanismo que consiste en enviar la salida (estándar o de error) u obtener la entrada de una aplicación
hacia/desde un archivo.
Las redirecciones de entrada anula la intervención del usuario (desde teclado) para ingresar datos a una aplicación dando lugar a que
dicha entrada sea obtenida desde un archivo.
Las redirecciones de salida (estándar o de error) anulan la muestra de datos en pantalla dando lugar a que dicha salida sea enviada a
un archivo.
El uso de las redirecciones es importante en casos que requerimos cierto nivel de automatización de tareas, por ejemplo cuando
usamos comandos cuya salida es abundante, tal como dmesg, es importante poder capturar esa información en un archivo para
poderla leer con calma.
Símbolos de
Tipo de redirección Modo de uso Descripción
redirección
< ó 0< Redirección de entrada $ comando < archivo Toma la entrada de datos desde un archivo
estándar
> ó 1> Redirección simple de $ comando > archivo Envía la salida estándar hacia un archivo
salida estándar sobreescribiendo su contenido
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 23
Source Linux
Envía la salida estándar hacia un archivo
>> ó 1>> Redirección doble de salida $ comando >> archivo
agregándolo al final del mismo (no
estándar
sobreescribe)
2> Redirección simple de $ comando 2> archivo Envía la salida de error hacia un archivo
salida de error sobreescribiendo su contenido
Envía la salida de error hacia un archivo
2>> Redirección doble de salida $ comando 2>> archivo
agregándolo al final del mismo (no
de error
sobreescribe)
&> Redirección simple de $ comando &> archivo Envía la salida estándar y de error hacia un
salida estándar y de error archivo sobreescribiendo su contenido
Las siguientes son las transformaciones de redirecciones de salida estándar y salida de error:
Símbolos de
Modo de uso Descripción
transformación
2>&1 $ comando 2>&1 Transforma la salida de error en salida estándar
1>&2 $ comando 1>&2 Transforma la salida estándar en salida de error
Ejemplo 2:
a) Captura la salida del comando dmesg en archivo1.txt, y los comandos df -h y free -m en archivo2.txt. Visualizar luego los archivos
creados.
c) Ahora enviar otro correo tomando el contenido del archivo /etc/fstab como entrada (cuerpo del mensaje):
d) El comando ssh sin ningún parámetro nos muestra una salida estándar la que debemos redireccionar hacia archivo2.txt al final de
éste (no sobreescribir):
e) La misma salida del comando anterior convertirla en salida estándar y redireccionarla hacia archivo1.txt:
f) La salida del comando fdisk -l ejecutado como usuario sin privilegios (salida de error) y ejecutado como root (salida estándar)
redireccionarlo hacia el archivo /tmp/test. Visualizar luego el contenido del archivo creado.
Tuberías
Las tuberías también conocidas como pipes, es aquella acción en la cual dos o más aplicaciones se conectan de forma tal que la salida
del primero se convierte en la entrada del siguiente. Esto es posible gracias a la conexión directa de la entrada estándar de un proceso
con la salida estándar de otro que le antecede. La salida de error no pasa a través de una tubería a menos que se transforme a salida
estándar.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 24
Source Linux
Las tuberías son extremadamente útiles en todo sistema UNIX para maximizar los beneficios de la Shell a través del trabajo conjunto
de múltiples aplicaciones para resolver tareas complejas a través del intercambio de información de cada uno de los procesos
participantes en la cadena.
El símbolo de tubería es el "|" (código ASCII 124) y la forma de crear una tubería es como sigue:
Ejemplo 3:
$ dmesg | wc -l
b) Enumerar cada una de las líneas de la salida del comando dmesg y filtrar aquellas que contengan la palabra kernel:
Comodines
La shell Bash tiene reservados ciertos caracteres llamados comodines los cuales se usan para sustitución de patrones de texto como:
Caracter Descripción
* Coincidencia con cualquier caracter 0, 1 o más veces
? Coincidencia con cualquier caracter 1 sola vez
[ ] Coincidencia con cualquier caracter encerrado en los corchetes [ ]
[! ] Coincidencia con cualquier caracter excepto los encerrado en los corchetes [ ] luego del !
{ } Coincidencia con grupos encerrados dentro de las llaves { } cada uno separado por coma
Ejemplo 4:
$ ls /usr/bin/b*
b) Listar todos los programas que contienen una 'b' como segundo caracter:
$ ls /usr/bin/?b*
c) Listar todos los programas que comiencen con una 'a' y el segundo caracter sea 'c', 'd', 'e' o 'f' (dos alternativas equivalentes):
$ ls /usr/bin/a[cdef]*
$ ls /usr/bin/a[c-f]*
d) Listar todos los programas que comiencen con una 'a' y el segundo caracter no sea cualquiera entre la 'g' y la 'z':
$ ls /usr/bin/a[!g-z]*
e) Listar todos los archivos de extensión .conf o cualquier otra extensión de 3 caracteres dentro del directorio /etc:
$ ls /etc/*.{conf,???}
Variables especiales
La siguiente tabla resume las variables especiales más importantes:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 25
Source Linux
Variable Significado
$$ PID de la shell en ejecución
$! PID del último proceso ejecutado en segundo plano (background)
$? El código de estado retornado por la última aplicación ejecutada
$0 Nombre del script de shell en ejecución
$# Número de parámetros pasados a un script
$1, $2, $3, Parámetro N° 1, N° 2, N°3, y así sucesivamente
...
$@ Todos los parámetros pasados al script
Operadores
La siguiente tabla resume algunos de los operadores más importantes:
Operador Significado
$( ) Captura el resultado (salida estándar) de una aplicación o conjunto de ellas en tubería
$(( )) Operación aritmética simple
&& AND lógico. Permite ejecutar aplicaciones de manera secuencial si la anterior terminó correctamente.
|| OR lógico. Permite ejecutar aplicaciones de manera secuencial si la anterior no terminó correctamente.
; Separador de sentencias. Permite ejecutar aplicaciones de manera secuencial sin importar cómo terminó la
aplicación anterior.
& Ejecutar un proceso en segundo plano (background)
Ejemplo 5:
$ PRODUCTO=$((34*29))
$ echo $PRODUCTO
$ PRODUCTO=$(($PRODUCTO/10))
b) Consultar la hora y fecha actual del sistema, el resultado almacenarlo en la variable DATE y mostrarlo en pantalla convertido en
mayúsculas; todo realizado desde una única línea de comandos secuencial:
c) Ejecutar el comando date, luego free -m, luego mkdir y luego df -h uno tras otro con la condición de ejecutar el próximo si el
anterior terminó correctamente. ¿Qué comando no se llegó a ejecutar?
d) Realizar el mismo procedimiento anterior excepto que df -h se debe ejecutar sólo si mkdir no terminó correctamente. ¿Faltó
ejecutar algún comando?
Caracter Significado
` ` Captura el resultado (salida estándar) de una aplicación o conjunto de ellas en tubería. Igual que el operador $( )
" " Anula el significado de todos los caracteres excepto $, ` y \
' ' Anula el significado de todos los caracteres excepto \
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 26
Source Linux
\ Caracter de escape que precede a otros especiales como $, |, \, *, >, <, etc. También se usa como una forma de
romper una línea larga de comandos en varias de menor tamaño continuadas una debajo de otra.
Ejemplo 6:
a) Mostrar la salida del comando date junto al valor de la variable HOME, todo encerrado entre doble comillas. Analice los resultados:
b) Intentar hacer el procedimiento anterior pero encerrado en comillas simples. Analice los resultados y diferencias encontradas:
$ dm\
> es\
> g
Historial de comandos
Bash al igual que otras Shell, cuenta con una característica que permite almacenar un historial de todos las órdenes o comandos
ingresados. Este historial puede ser consultado, limpiado y desactivado desde la línea de comandos así como también cuenta con
parámetros personalizables los cuales se detallan a continuación:
• La variable HISTFILE contiene la ruta del archivo de historial de comandos del usuario.
• El historial de comandos se desactiva ejecutando set +o history y se vuelve a activar ejecutando set -o history
$ !!
Ejecuta el último comando usado.
$ !texto1
Ejecuta el último comando que empieza con texto1
$ !?texto2
Ejecuta el último comando (entre el comando y todos sus parámetros) que contiene texto2
Alias de comandos
Bash permite personalizar y 'crear' nuestros propios comandos a través del uso de alias. Éstos permiten definir uno o más comandos
en serie a ser ejecutados tras la invocación de un nombre que nosotros elijamos.
El uso de los alias se explica a continuación:
• Usamos el comando alias de manera similar a la asignación de una variable cuyo contenido es el(los) comandos a ejecutar.
Ejemplo:
• Una vez definidos simplemente nos queda invocarlos como lh o dm. Cualquier parámetro que le pasemos a los alias se
transmitirán como tales al último comando que forma parte del alias.
$ lh /boot
drwxr-xr-x 2 root root 1.0K oct 12 18:57 grub
-rw-r--r-- 1 root root 84K ago 19 19:42 config-2.6.26-2-amd64
-rw-r--r-- 1 root root 1.2M ago 19 19:42 System.map-2.6.26-2-amd64
-rw-r--r-- 1 root root 1.7M ago 19 19:41 vmlinuz-2.6.26-2-amd64
-rw-r--r-- 1 root root 8.5M sep 22 09:02 initrd.img-2.6.26-2-amd64
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 27
Source Linux
$ dm | tail -3
741 [ 1005.143725] device eth0 entered promiscuous mode
742 [ 5511.291881] device eth0 left promiscuous mode
743 [ 6783.599910] device eth0 entered promiscuous mode
• La forma de consultar los alias existentes es usando el comando alias sin ningún parámetro:
$ alias
alias dm='dmesg | cat -n'
alias lh='ls -lhSr'
alias ls='ls –color=auto'
$ unalias dm lh
Combinaciones de tecla
Las siguientes son combinaciones de gran utilidad en el uso diario cuando se ponen en práctica:
Autocompletado
Bash provee una funcionalidad muy práctica que consiste en el completado automático de nombres de archivos, directorios o
comandos mientras vamos escribiéndolos en el intérprete de órdenes haciendo uso de la tecla [Tab] (tabulador).Esto tiene por
objetivo abreviar la cantidad de texto que escribimos dejando que Bash adivine el resto de caracteres faltantes.
Para eso debemos escribir parte de un texto y presionar una vez la tecla [Tab] donde por defecto sucederá una de dos posibilidades:
(a) Se realiza el autocompletado total con el nombre del comando o ruta del archivo/directorio.
(b) Se realiza el autocompletado parcial del nombre del comando o ruta del archivo/directorio.
(c) No aparece nada en pantalla, nada sucede.
Si ocurre (a) entonces no hay más nada que hacer. Si ocurre (b) quizás el autocompletado parcial ya satisface nuestra expectativa del
comando o archivo que buscábamos, sino podremos seguir intentando autocompletar según (c).
Si ocurre (b) no es porque el autocompletado no funcionó, sino porque Bash encontró más de una coincidencia con parte del texto que
escribimos, así que nos queda una de dos posibilidades:
(1) Escribir algo más de texto de modo tal que las coincidencias se reduzcan e incluso quede sólo una
(2) Presionar por segunda vez la tecla [Tab] y dejar que Bash nos muestre todas las alternativas que existen actualmente
Si optamos por (1) entonces ese proceso puede seguir repitiéndose sucesivamente entre los casos (a), (b) y (c) de la mano con
escritura adicional de texto por nuestra parte hasta lograr que la coincidencia sea única y se de finalmente el autocompletado.
Si optamos por (2) entonces Bash muestra en pantalla todas las coincidencias con el texto que hemos logrado escribir con el propósito
que nos demos cuenta cuál es el comando o archivo que nos interesa y escribamos tanto como sea necesario para eliminar
coincidencias adicionales de la mano con la tecla [Tab].
Ejemplo 7:
a) En la línea de comandos, escribir "cl" y tipear la tecla [Tab] tantas veces como se crea conveniente y apreciar qué sucede en
cada presión de dicha tecla:
$ cl[Tab]
$ clea
$ clea[Tab][Tab]
cleanlinks clear clear_console
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 28
Source Linux
b) Hagamos algo similar con listando un archivo, escribiendo primero "/et" y [Tab], luego "X" y [Tab], luego "x" y [Tab][Tab]:
$ ls /et[Tab]
$ ls /etc/
$ ls /etc/X[Tab]
$ ls /etc/X11/
$ ls /etc/X11/x[Tab][Tab]
xkb/ xorg.conf xorg.conf.backup xserver/
2.3. Manejo de archivos
Estructura de directorios
La siguiente tabla muestra los directorios comunes en todo sistema Linux y una descripción del propósito de cada uno de ellos:
Directorio Descripción
/ Jerarquía primaria y raíz del sistema de archivos entero
/bin Comandos binarios esenciales que por lo general no requieren privilegios de administrador para ser ejecutados
/boot Archivos requeridos para el arranque del sistema operativo. Aquí se encuentra el kernel
/dev Dispositivos esenciales
/etc Archivos de configuración del sistema
/home Directorio de los usuarios (contiene sus datos personales). Ubicada normalmente en una partición separada
/lib Archivos de biblioteca esenciales requeridos por los binarios de /bin y /sbin
/media Contiene los puntos de montaje para dispositivos removibles (CDROM, memorias USB, discos externos, etc)
/mnt Punto de montaje temporal de otros sistemas de archivos
/opt Directorio de instalación de software opcional
/proc Sistema de archivos virtual que contiene información de procesos y el kernel
/root Directorio del usuario root (contiene sus datos personales)
/sbin Comandos binarios esenciales que por lo general requieren privilegios de administrador para ser ejecutados
/srv Directorio de datos servidos por el sistema
/tmp Temporales del sistema
/usr Jerarquía secundaria del sistema que contiene aplicaciones de uso para todos los usuarios
/var Archivos variables y abundantes tal como logs, buzones de correo, temporales, etc.
El caracter ~
Este caracter tiene un significado especial cuando trabajamos en un sistema de archivos, y es que hace referencia al directorio
personal de un usuario. Tiene dos formas de usarlo:
• ~ : Hace referencia al directorio personal del usuario con el cual estamos actualmente trabajando
• ~USER : Hace referencia al directorio personal del usuario USER
Ejemplo 8:
a) Asumiendo que actualmente trabajamos como el usuario root los siguientes comandos ejecutados son equivalentes:
# mkdir ~/prueba1
# mkdir /root/prueba1
# mkdir ~root/prueba1
b) De manera similar asumiendo que actualmente trabajamos como el usuario consultorianet, los siguientes comandos son
equivalentes:
$ cd ~/Desktop
$ cd /home/consultorianet/Desktop
$ cd ~consultorianet/Desktop
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 29
Source Linux
Rutas relativas y rutas absolutas
Dado que en gran parte de este curso se enseñan herramientas de línea de comandos que trabajan con archivos y directorios, es
importante conocer la diferencia entre dos formas de hacer referencia a las rutas tal como se detalla a continuación:
• Ruta absoluta : Es una ruta que apunta siempre a una misma ubicación sin importar cuál sea nuestra ubicación actual.
Usualmente es escrita en referencia a la raíz (/). También son absolutas aquellas que empiezan con la invocación a un
directorio de usuario con el caracter ~
• Ruta relativa : Es una ruta relativa al directorio actual de trabajo y por lo tanto no inician desde la raíz (/).
En esta sección es importante resaltar un par de comandos útiles como son basename y dirname:
Ejemplo 9:
• /etc
• /usr/local/share
• ~root/Desktop/tarball.zip
b) Asumiendo que nuestro directorio de trabajo actual es /usr las siguientes son rutas relativas válidas:
• share/icons/gnome/
• lib/openssh/
• include/linux/fcntl.h
c) Observar el resultado y comprender el uso de los comandos basename y dirname en los ejemplos mostrados:
$ basename /usr/local/share
share
$ basename /etc/X11/xorg.conf
xorg.conf
$ basename /usr/include/linux/sysctl.h .h
sysctl
$ dirname /usr/local/share
/usr/local
$ dirname /usr/include/linux/sysctl.h
/usr/include/linux
Control de archivos
A continuación estudiaremos algunos de los comandos más importantes y comunes en el uso diario para el buen desenvolvimiento en
un sistema de archivos Linux. Primero presentamos una tabla resumida para luego ir por el detalle de cada uno de ellos:
Comando Descripción
pwd Informa de nuestra ubicación (o directorio de trabajo) actual en el sistema de archivos
cd Nos cambia hacia otro directorio
file Informa tipos de archivo
touch Crea archivos y/o altera sus fechas de modificación
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 30
Source Linux
rmdir Elimina directorios
ls Imprime un listado de archivos y/o directorios
cp Copia archivos y/o directorios
mv Mueve o renombra archivos y/o directorios
mkdir Crea directorios
rm Elimina archivos y/o directorios
du Calcula el espacio utilizado por archivos y/o directorios
find Busca archivos y/o directorios
which Busca la ubicación de comandos
whereis Busca la ubicación de comandos, fuentes y documentación
ln Crea enlaces duros y/o simbólicos
El detalle de los comandos que aceptan una o más opciones se muestra a continuación:
cd [directorio]
Cambia de directorio
Si directorio se omite entonces por defecto se cambia hacia el directorio personal del usuario
Opciones:
Opciones:
Opciones:
Si el destino no existe entonces el origen debe ser único y crea una copia de éste con el nombre y ruta del destino
Si el destino ya existe y es un directorio entonces copia el(los) origen(es) a la ruta del destino
Si el destino ya existe y es un archivo entonces el origen debe ser único y éste sobreescribe al destino
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 31
Source Linux
mv [opciones] <origen1> [origen 2] ... <destino>
Mueve y renombra archivos y/o directorios
Opciones:
Si el destino no existe entonces el origen debe ser único y mueve el origen renombrándolo con el nombre y ruta del destino
Si el destino ya existe y es un directorio entonces mueve el(los) origen(es) a la ruta del destino
Si el destino ya existe y es un archivo entonces el origen debe ser único y éste sobreescribe al destino
Opciones:
-m modo : Establece los permisos del directorio creado segun el valor de modo
-p : Crea los directorios de nivel superior que aún no existiesen
Opciones:
-f : No pide confirmación, no escribe mensajes de diagnóstico, ni avisa de errores por archivos que no existiesen
-i : Pide confirmación
-r : Borrado recursivo. Parámetro obligatorio para borrar directorios.
Opciones:
-c : Muestra un total para todos los argumentos (después de ser procesador) pasados al comando
-h : Muestra los tamaños con sufijos de fácil identificación (K para KB, M para MB, G para GB)
-s : Muestra solamente un total para cada argumento
Opciones:
-name patron : Busca archivos que coincidan con patrón (Ejm: "*.conf", "*mk*")
-iname patron : Igual que -name pero insensible a mayúsculas
-user usuario : Busca archivos cuyo propietario sea usuario
-size tamaño : Busca archivos según tamaño (Ejm: +400k, -10M, 2G)
-type tipo : Busca según el tipo de archivo (f: archivo, d: directorio, l: enlace simbólico, etc)
Este comando dispone de múltiples parámetros de interés los cuales deben ser revisados a detalle en find(1)
A) Los enlaces simbólicos son accesos directos hacia archivos o directorios. Estos enlaces no son archivos reales, por lo tanto
cualquier acción de modificación que se pretenda hacer sobre ellos se realiza realmente sobre el archivo o directorio al que
apuntan, pero sin embargo cuando los eliminamos no se borra la referencia al que apunta sino se elimina el mismo enlace.
Una peculiaridad es que el tamaño de un enlace simbólico siempre es igual a la cantidad de caracteres que contiene la ruta a
la que apunta.
B) Los enlaces duros son referencias o punteros a otros archivos existentes en el sistema. Se visualizan como archivos reales,
idénticos al archivo original al que referencian en todos sus atributos, sin embargo no son archivos nuevos sino tan sólo una
especie de clones abstractos que se caracterizan por tener el mismo número de inodo (identificador numérico siempre único
para todo archivo y directorio en un sistema de archivos).
Esto trae conlleva a peculiaridades como el hecho que todos los enlaces duros creados no ocupan más espacio en disco, o
el hecho que cualquier modificación hecha sobre un enlace duro se aplica igual e inmediatamente a todos los demás enlaces
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 32
Source Linux
y el original.
Esto es posible si tenemos en cuenta que los nombres de archivos son sólo etiquetas hacia cierta porción del sistema de
archivos, por lo tanto cualquier manipulación que hacemos sobre los archivos se realizan en realidad sólo sobre esas
etiquetas que apuntan a los datos reales almacenados en el sistema de archivos.
Por ello tanto el archivo original como cualquiera de los enlaces duros no son más que etiquetas, todos iguales, llegando
incluso a la conclusión de razonamiento que cualquier archivo creado en el sistema no es más que el primer enlace duro a
los datos que existen sólo 1 vez (número de inodo siempre es único).
Cabe tener en cuenta que los enlaces duros a directorios no están permitidos en Linux (aunque ln(1) pueda decir lo
contrario). Tampoco es posible crear enlaces duros hacia archivos que estén en otro sistema de archivos diferente al archivo
original (otra partición, otro dispositivo).
Opciones:
Ejemplo 10:
a) Desplazarse por el sistema de archivos, consultar la ubicación actual dentro del mismo luego de cada cambio y averiguar el tipo de
algunos archivos encontrados dentro:
$ cd /usr/local
$ pwd
/usr/local
$ file bin/
bin/: directory
$ cd /etc/X11/
$ pwd
/etc/X11
$ file xorg.conf
xorg.conf: ASCII text
b) Crearemos algunos archivos (archivo1 y archivo2) y directorios (dir1 y dir2), copiaremos información (los archivos fstab y hosts de /etc/)
y finalmente los eliminaremos:
c) Crearemos archivos (archivo3 y archivo4) y directorios nuevamente (dir3 y dir4), moveremos y renombraremos algunos de ellos para
finalmente eliminarlos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 33
Source Linux
d) Crearemos enlaces duro al archivo /etc/fstab de estas dos formas equivalentes:
$ cp -l /etc/fstab fstab_2
$ ln /etc/fstab fstab_3
$ ln -s /etc/fstab fstab_4
f) Buscar enlaces simbólicos de extensión .conf dentro de /etc y suprimir la salida de error:
$ find /usr \( -name "*.jpg" -o -name "*.gif" -o -name "*.png" \) -size +300k
$ which mkdir
$ whereis mkdir
$ whereis fstab
Empaquetamiento y compresión
El empaquetamiento es el procedimiento por el cual se agrupan varios archivos y/o directorios en un único archivo sin aplicar sobre
ellos un algoritmo de compresión. El encargado de hacer esta función es el comando tar.
Los procesos de compresión en Linux se hacen a través de los comandos gzip y bzip2 de los cuales el segundo se caracteriza por
ofrecer un mejor nivel de compresión pero mucho mayor carga del CPU (consume mucho más tiempo). Ambos son capaces de
comprimir sólo 1 archivo, y no comprimen directorios. Para lograr comprimir varios archivos y directorios a la vez se requiere usar un
empaquetar y luego comprimir, todo invocar desde el comando tar con ciertos parámetros adecuados que líneas abajo mostramos.
Alternativamente se puede utilizar el comando zip que trabaja casi de igual manera que su equivalente en plataformas Microsoft
Windows, el Winzip, para poder comprimir varios archivos y directorios a la vez. Sin embargo en sistemas UNIX predomina mucho más
el uso de empaquetado y compresión con tar, gzip y bzip2.
Opciones:
-d : Descomprime
-c : El resultado de la compresión/descompresión es arrojado a stdout y deja intacto el archivo original
-# : Nivel de compresión: -1 más rápido y de menor compresión, -9 más lento mejor compresión, -6 valor por defecto
gzip por defecto comprime archivos agregándoles la extensión .gz (eliminando el original). gunzip es equivalente a gzip -d y zcat
equivalente a gzip -dc. Ambos aceptan los mismos parámetros que gzip
Opciones:
-d : Descomprime
-c : El resultado de la compresión/descompresión es arrojado a stdout y deja intacto el archivo original
-# : Nivel de compresión: -1 más rápido y de menor compresión, -9 más lento mejor compresión, -6 valor por defecto
bzip2 por defecto comprime archivos agregándoles la extensión .bz2 (eliminando el original). bunzip2 es equivalente a bzip2 -d y
bzcat equivalente a bzip2 -dc. Ambos aceptan los mismos parámetros que bzip2
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 34
Source Linux
tar [opciones] <archivo1/directorio1> [archivo2/directorio2] ...
Empaquete archivos y/o directorios
Opciones:
-c : Empaqueta
-x : Desempaqueta
-t : Lista el contenido de un archivo empaquetado
-C DIR : Desempaqueta en el directorio DIR en lugar de hacerlo en el directorio de trabajo actual
-f FILE : Empaqueta/desempaqueta en un archivo o dispositivo indicado en FILE (si se omite -f el resultado se envía a stdout)
-v : Verboso. Muestra archivos procesador
-z : Invoca a gzip para comprimir o descomprimir
-j : Invoca a bzip2 para comprimir o descomprimir
Opciones:
Opciones:
Ejemplo 11:
a) Empaquetar en un archivo de nombre paquete 1.tar el directorio /etc, /tmp y los archivos *.log del directorio /var/log. Luego comprimir
con gzip el archivo resultante y visualizar su contenido:
b) Descomprimir y desempaquetar el archivo anterior resultante en el directorio /tmp/prueba que nosotros crearemos. Luego
empaquetar y comprimirlo usando bzip2 hacia un archivo resultante de nombre paquete2.tar.bz2:
# mkdir /tmp/prueba
# tar -xzf paquete1.tar.gz -C /tmp/prueba
# tar -cjf paquete2.tar.bz2 /tmp/prueba
c) Comprimir el directorio /boot usando zip (protegiendo el archivo resultante con contraseña) y descomprimirlo luego con unzip en el
directorio /tmp/prueba que nosotros previamente creamos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 35
Source Linux
2.4. Procesamiento simple de texto
El procesamiento de texto es una tarea muy común en todo sistema UNIX, para facilitar el manejo de información emitida por
aplicaciones y su transformación a formatos particulares requeridos por nosotros.
Este procesamiento por lo general se da a través del uso de herramientas concatenadas en tuberías, donde cada una emite a la salida
estándar la información que otra herramienta ha de procesar.
Es por ello que todas las herramientas estudiadas en este apartado tienen la posibilidad de ser utilizadas como parte de una tubería en
la shell.
Expresiones regulares
Las expresiones regulares, como su nombre lo indica, son expresiones que describen un conjunto de patrones de texto a través de la
interpretación de ciertos caracteres con significado especial. Las expresiones regulares tienen por objetivo el hacer coincidencia con un
conjunto de palabras, frases o partes de ellas según la lógica de la expresión que nosotros creemos con el uso adecuado de caracteres
especiales.
Por ejemplo la expresión regular L[i1]nux{2} ha de coincidir con las palabras Linuxx, L1nuxx, Linuxxx, L1nuxxx, Linuxxxx,
L1nuxxxx, y así sucesivamente con letras 'x' adicionales, pero no coincide con Linux ni con L1nux.
Para entender mejor este ejemplo es necesario estudiar la tabla de expresiones regulares abajo mostrada:
Caracteres Descripción
. Cualquier caracter excepto el salto de línea (\n)
* Cero, una o más veces la expresión ubicada a su izquierda
^ Inicio de línea
$ Fin de línea
< Limita el inicio de una palabra
> Limita el fin de una palabra
[ ] Agrupación de caracteres coincidentes
[^ ] Agrupación de caracteres no coincidentes
\ Escape de caracteres especiales
[:alpha:] Agrupación de caracteres alfabéticos
[:alnum:] Agrupación de caracteres alfanuméricos
[:digit:] Agrupación de caracteres numéricos (dígitos)
[:lower:] Agrupación de caracteres alfabéticos en minúsculas
[:upper:] Agrupación de caracteres alfabéticos en mayúsculas
[:blank:] Agrupación de espacios en blanco y tabulaciones
Caracteres Descripción
? Cero o una vez la expresión ubicada a su izquierda
+ Una o más veces la expresión ubicada a su izquierda
{ } Cantidad de ocurrencias de la expresión ubicada a su izquierda
| OR lógico de expresiones
( ) Agrupación de expresiones
A continuación se hace la interpretación a modo de ejemplos de varios de los caracteres especiales de las expresiones regulares arriba
vistos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 36
Source Linux
c[aA][sz]a casa cAsa caza cAza Casa cazA cesa cazza
archivo[1-3] archivo1 archivo2 archivo3 archivo4 archivo0 archivoM archivo@
[^a-z].txt 1.txt A.txt B.txt ,.txt -.txt {.txt a.txt b.txt m.txt f.txt
^[[:upper:]].*[0-9]$ Hola1 Casa3 Pelota9 Materia8 hola3 CasaA Pelota9B materia8
perr[o0]? perr perro perr0 Perro perra perrito perrO
perr[o0]+ perro perr0 perroo perr00 perrooo perr000 perr Perro perrO pErr0
Casa{2,3} Casaa Casaaa casaa casa casaaa
(pe|he)[sl]ado pesado pelado helado hesado Pelado helado celado Helado
([pm]a){2} papa mama mapa pama Mama paPa maapa pana
Una buena forma de probar estas expresiones regulares es a través del uso del comando grep -o y grep --color como sigue:
Más información sobre el uso del comando grep se muestra líneas debajo.
Comando Descripción
cat Imprime en pantalla el contenido de textos
grep Imprime las líneas que coincidan con un patrón de textos
more Visualiza texto en pantalla dividido en páginas (permite sólo bajar la lectura)
less Visualiza texto en pantalla dividido en páginas (permite bajar y subir la lectura)
head Imprime las primeras líneas de textos
tail Imprime las últimas líneas de textos
wc Contabiliza la cantidad de bytes, palabras y líneas de textos
cut Imprime campos de un texto (cada uno separada por un caracter común)
sort Ordena las líneas de textos
uniq Reporta líneas repetidas de textos ordenados
tr Reemplaza y elimina caracteres de textos de entrada estándar
split Divide un archivo en partes
sed Editor de flujos de texto avanzado que permite filtrado y transformación
Opciones:
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 37
Source Linux
-e patrón : Usa patrón como patrón de coincidencia
-i : Ignora la sensibilidad a mayúsculas en la coincidencia de patrones
-w : Coincide con patrones sólo como palabras completas
-c : Sólo imprime el número de líneas coincidentes
--color : Resalta en color el patrón coincidente en las líneas
-n : Antecede cada línea coincidente con el número de línea del texto en el que se da la coincidencia
-o : Sólo imprime el patrón coincidente con la expresión regular
-R : Lee todos los archivos dentro de un directorio de manera recursiva
-v : Invierte el sentido de la coincidencia: imprime sólo las líneas no coincidentes
La documentación de las opciones de esta herramienta pueden ser encontradas en more(1). Al utilizar more se pueden usar algunos
comandos de control sobre el texto mostrado, las mismas que a continuación se detallan:
Comandos:
Opciones:
La documentación de otras opciones de esta herramienta pueden ser encontradas en less(1). Al utilizar less se pueden usar algunos
comandos de control sobre el texto mostrado, las mismas que a continuación se detallan:
Comandos:
Opciones:
-n [-]N : Imprime las N primeras líneas en vez de las 10 primeras. Si se especifica "-" imprime todo excepto las 10 últimas líneas
-# : Imprime las # primeras líneas en vez de las 10 primeras.
Opciones:
-n [+]N : Imprime las N últimas líneas en vez de las 10 últimas. Si se especifica "+" imprime desde la línea número N hasta el final
-# : Imprime las # últimas líneas en vez de las 10 primeras.
-f : Imprime las últimas líneas de forma dinámica mientras el texto va creciendo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 38
Source Linux
Si no se especifica al menos un archivo entonces se analizará el texto ingresado en la entrada estándar
Opciones:
Si no se especifica al menos un archivo entonces se analizará el texto ingresado en la entrada estándar. En la ausencia de opciones
se imprime por defecto la cantidad de líneas, palabras y bytes.
Opciones:
LISTA es uno o más rangos (cada uno separado por comas) a usarse con los parámetros -c ó -f y que se pueden expresar como
sigue:
N Caracter/campo número N
N- Desde el caracter/campo número N en adelante
-N Desde el inicio hasta el caracter/campo número N
N-M Desde el caracter/campo número N hasta el caracter/campo número M
DELIM debe ser un único caracter que se identifique como delimitador entre los campos. Si no se especifica al menos un archivo
entonces se analizará el texto ingresado en la entrada estándar.
Opciones:
DELIM debe ser un único caracter que se identifique como delimitador entre las columnas. Si no se especifica al menos un archivo
entonces se analizará el texto ingresado en la entrada estándar.
Opciones:
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 39
Source Linux
-d : Elimina caracteres presentes en GRUPO1, no reemplaza
Esta herramienta siempre analiza el texto ingresado en la entrada estándar. En la ausencia del parámetro -d se encarga de
reemplazar del flujo de texto de la entrada estándar cada caracter del GRUPO1 con su correspondiente de la misma posición en
GRUPO2 uno a uno.
Cuando se usa de la mano con el parámetro -d el GRUPO2 se ignora, sólo se elimina del flujo de texto de la entrada estándar los
caracteres encontrados en GRUPO1
Opciones:
Esta herramienta produce como salida múltiples archivos producto de la división de archivo en varias partes, usando cada uno 'x'
como prefijo con una longitud de 2 caracteres como sufijo variable.
El valor SIZE que especifica el tamaño de cada parte resultante puede llevar sufijos como k (1024), m (1024*1024) o g
(1024*1024*1024).
Opciones:
SCRIPT representa un comando de sed a ejecutarse conformado por un rango, acciones y opcionalmente parámetros de éstas. La
forma que tiene un SCRIPT es como sigue:
[rango]<acción>[parámetros]
rango permite limitar las líneas del texto a analizar -a través de una expresión- y por cada una de ellas se ejecuta una acción
complementada opcionalmente con uno o más parámetros.
El rango puede ser expresado como direcciones de las cuales cada una puede tener la forma siguiente:
El rango puede ser delimitado como intervalos marcando un inicio y fin a través de dos direcciones delimitadas por coma. Por ejemplo
el siguiente rango expresado por las direcciones /regexp/ y M permite imprimir las líneas que coinciden desde la expresión regular
regexp hasta la línea número M:
/regexp/,M
Al usar intervalos como rangos se puede especificar la segunda dirección como una expresión numérica de adición usando +M, que
indica que debe imprimirse M líneas después de la coincidencia del primer intervalo.
Ejemplo 12:
a) Mostrar la salida enumerada del archivo /etc/inittab y mostrar sólo los comentarios (aquellas que empiecen con #):
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 40
Source Linux
$ cat -n /etc/inittab | grep --color '^#'
b) Mostrar la lista de los últimos 5 usuarios del sistema creados y sus directorios personales:
c) Crear una copia del kernel (archivo de nombre vmlinuz* en /boot) y partirlo en pedazos de 100 KB cada uno, usando como sufijo la
palabra 'kernel-' y prefijos numéricos:
$ cp /boot/vmlinuz* .
$ split -d -b 100k vmlinuz* kernel-
d) A todos los usuarios del sistema que tengan /bin/bash como Shell, agregarles el caracter # al inicio de su línea correspondiente en el
archivo /etc/passwd:
e) Ordenar de forma descendente la lista de usuarios del sistema en base a su UID (3ra columna del archivo /etc/passwd) y mostrar
luego sólo el nombre de usuario convertido a mayúsculas con su respectivo UID:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 41
Source Linux
2.5. Administración de procesos
Introducción
La definición de proceso la podemos resumir simplemente en una instancia de una aplicación en ejecución. Cada uno de los procesos
se ejecuta de manera independiente de otros en el sistema.
Como ya se sabe, Linux, es un sistema operativo multitarea, permitiendo que cada proceso pueda correr sin interrupción de otro de
manera simultánea.
Normalmente en el ámbito de los procesos encontraremos cierta terminología como estado, proceso hijo, proceso padre, PID, y otros
más que corresponden a los atributos de un proceso que estudiaremos a continuación:
Atributos
Este es un listado de los atributos más importantes de los procesos en UNIX:
Atributo Descripción
PID Número ID del proceso
Nice Valor nice (prioridad)
Tiempo Tiempo de ejecución acumulado
Usuario Usuario propietario del proceso
Estado Estado en el que se encuentra el proceso
Es importante tener en cuenta que los procesos pueden generar otros procesos, estos últimos llamados procesos hijos y los que lo
generaron son llamados procesos padres.
Todos los procesos tienen siempre un padre a excepción del proceso init, cuyo PID siempre es 1
Algunos de los estados más comunes de los procesos se muestra debajo:
Las herramientas disponibles para listar y monitorear los procesos del sistema se detallan a continuación:
ps [opciones]
Imprime un listado actual y estático de procesos
Opciones:
pstree [opciones]
Muestra un árbol de procesos
Opciones:
top
Muestra interactivamente un listado de procesos en tiempo real
Esta herramienta de manera similar a los comandos less o more, aceptan comandos de control que modifican la forma de
funcionamiento o modo en el que se muestra la información.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 42
Source Linux
Algunos de estos comandos son:
Señales
Las señales son mensajes enviados hacia los procesos a modo de órdenes con el propósito que realicen alguna operación. Estas
señales son enviadas usando el comando kill
Algunas de las señales más comunes son:
Las herramientas disponibles para enviar señales a los procesos son las siguientes:
Donde señal es un valor numérico tal como 1, 2, 9, 15 (según la tabla antes mencionada).
Opciones:
Donde señal es un valor numérico tal como 1, 2, 9, 15 (según la tabla antes mencionada).
Prioridades
Los procesos tienen la particularidad de poseer niveles de prioridad, los mismos que son útiles cuando múltiples procesos están
demandando más recursos de los que el CPU puede ofrecer. Es así que un proceso con mayor prioridad obtiene mayor tiempo de
atención del procesador.
La prioridad de un proceso se manifiesta a través de un atributo llamado nice, el mismo que se puede variar dependiendo de los
requerimientos de un usuario o administrador.
Un valor nice de -20 representa la máxima prioridad, mientras que 19 la más baja prioridad. El valor nice por defecto de todo proceso
recién creado es 0. El usuario administrador (root) es el único capaz de asignar valores nice negativos (más alta prioridad), así como
también de cambiar el valor nice de un proceso en ejecución a uno menor.
Las herramientas disponibles para manipular los valores nice de los procesos son las siguientes:
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 43
Source Linux
-n N : Aplica N como valor nice del proceso a ejecutar
Opciones:
Un proceso en primer plano mantiene ocupada nuestra shell hasta que culmine su ejecución, pero en cambio un proceso en segundo
plano se ejecuta sin mantener nuestra shell ocupada pudiendo así realizar otras tareas mientras el proceso continúa en su ejecución.
La forma de invocar un proceso en segundo plano se logra agregando el símbolo & al final de la línea de comandos.
Un proceso invocado en primer plano desde la Shell puede ser detenido presionando ^Z, lo que automáticamente nos deja la shell libre
para seguir trabajando en ella.
Los comandos de shell fg, bg y jobs nos permiten tener control sobre los procesos en primer y segundo plano. La forma de uso se
muestra a continuación:
fg [%JobID]
Ejecuta un trabajo en primer plano
Si se ejecuta sin parámetros, es decir sin especificar el JobID, vuelve a ejecutar en primer plano el trabajo más reciente que haya sido
suspendido
bg [%JobID]
Ejecuta un trabajo en segundo plano
Si se ejecuta sin parámetros, es decir sin especificar el JobID, vuelve a ejecutar en segundo plano el trabajo más reciente que haya
sido suspendido
Opciones:
El número de cada uno de los Jobs, conocido como JobID, se muestra en la lista encerrado entre corchetes [ ]
Ejemplo 13:
$ ps -efl
b) Mostrar el listado de procesos en vista de árbol, visualizando el PID de cada uno de ellos:
$ pstree -p
$ pidof bash
d) Invocar con la más baja prioridad la búsqueda de archivos cuya fecha de modificación sea menor a 3 días en nuestro directorio
personal:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 44
Source Linux
$ nice -n 19 find ~ -mtime -3
VIM tiene la particularidad de poder trabajar bajo distintos modos, cada uno de ellos enfocado en ofrecer funcionalidades para fines
distintos.
Modos de trabajo
Como se comentó, VIM es en editor modal, esto quiere decir que puede trabajar en distintos modos cada uno de ellos enfocado en
propósitos y formas de uso diferentes.
Algunos de los modos más usados a menudo son:
• Modo normal
• Modo inserción
• Modo visual
• Modo de línea de comandos
Por defecto VIM inicia en el modo normal, y es a este modo al cual se regresa cada vez que presionamos la tecla Esc. Es así que para
salir del modo inserción o modo visual presionaremos la tecla Esc quedando finalmente en el modo normal.
Si no estamos seguros en qué modo nos encontramos actualmente, o simplemente deseamos de regresar al modo normal debemos
presionar Esc dos veces.
Modo normal
Este modo permite trabajar con múltiples comandos de combinaciones de teclas para realizar funciones variadas tales como
desplazamiento, copiado, cortado y pegado, eliminar, reemplazar y otras operaciones de formateo de texto en general.
A continuación se muestra una tabla con algunos de los comandos más comunes en este modo:
Comandos de desplazamiento
Comando Descripción
h Mover el cursor una posición a la izquierda
l Mover el cursor una posición a la derecha
k Mover el cursor una posición hacia arriba
j Mover el cursor una posición hacia abajo
0 Mover el cursor al inicio de la línea
$ Mover el cursor al fin de la línea
e Mover el cursor al fin de la siguiente palabra
w Mover el cursor al inicio de la siguiente palabra
b Mover el cursor al inicio de la palabra anterior
ge Mover el cursor al fin de la palabra anterior
E Mover el cursor al fin de la siguiente palabra ignorando puntuaciones
W Mover el cursor al inicio de la siguiente palabra ignorando puntuaciones
B Mover el cursor al inicio de la palabra anterior ignorando puntuaciones
H Mover el cursor al inicio de la pantalla, en la primera posición
M Mover el cursor a la mitad de la pantalla, en la primera posición
L Mover el cursor al final de la pantalla, en la primera posición
G Ir a línea ... (por defecto va a la última línea)
^d Mueve el cursor media página hacia abajo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 45
Source Linux
^u Mueve el cursor media página hacia arriba
Importante:
• Todos estos comandos aceptan un modificador de repetición antecediendo un número a cada una de las combinaciones de
teclas a usar. Así, si nosotros podemos ejecutar el comando 10k que significa que se repetirá 10 veces el comando k (subir
10 líneas), o 20e que repetirá 20 veces el comando e (avanzar hacia el último caracter de la palabra N° 20 que viene a
continuación). A continuación se resumen unos ejemplos importantes que merecen ser resaltados en su explicación:
Comandos de edición
Comando Descripción
i Inserta texto en la posición del cursor (Cambia el VIM al modo inserción)
I Inserta texto al inicio de la línea (Cambia el VIM al modo inserción)
a Inserta texto una posición delante del cursor (Cambia el VIM al modo inserción)
A Inserta texto al final de la línea (Cambia el VIM al modo inserción)
o Inserta texto creando una nueva línea por debajo de la actual (Cambia el VIM al modo inserción)
O Inserta texto creando una nueva línea por encima de la actual (Cambia el VIM al modo inserción)
cc Elimina una línea entera e inserta (Cambia el VIM al modo inserción)
dd Elimina una línea entera
yy Copia una línea entera
x Elimina un caracter en la posición del cursor
X Elimina un caracter hacia la izquierda del cursor
p Pega el texto -previamente cortado o copiado- una posición a la derecha del cursor
P Pega el texto -previamente cortado o copiado- una posición a la izquierda del cursor
r Reemplaza el caracter actual con el nuevo que se escriba
R Reemplaza texto desde la posición del cursor en adelante (Presionar Esc una vez terminado)
^a Incrementa el número debajo del cursor
^x Decrementa el número debajo del cursor
u Deshacer
^r Rehacer
. Repite el último comando de edición de texto ejecutado
~ Convierte el caracter actual de mayúsculas a minúsculas o viceversa
gu Convertir texto a minúsculas (requiere combinación con movimientos o entrar al modo visual)
gU Convertir texto a mayúsculas (requiere combinación con movimientos o entrar al modo visual)
n Encuentra la siguiente coincidencia de un patrón previamente buscado con / o ?
N Encuentra la coincidencia previa de un patrón previamente buscado con / o ?
ZZ Salir del editor guardando los cambios
ZQ Salir del editor sin guardar los cambios
Importante:
• Muchos de estos comandos aceptan un modificador de repetición antecediendo un número a cada una de las combinaciones
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 46
Source Linux
de teclas a usar. Así, si nosotros podemos ejecutar el comando 8oLinux que significa que se repetirá 8 veces el comando o
(insertando la palabra Linux por encima de la línea actual), o 10dd que repetirá 10 veces el comando dd (eliminará las 10
líneas que vienen debajo de la actual).
• Es posible combinar comandos de edición con comandos de movimientos para obtener operaciones de edición más
específicas, tal como se muestra en los siguientes ejemplos:
Modo inserción
Este modo es el que permite al usuario modificar el contenido del texto por cada caracter que tipee en el teclado, tal como lo hace
cualquier editor de textos común por defecto.
Para ingresar a este modo sólo es necesario usar algunos de los comandos de edición como i, I, a o A. Una vez que terminemos de
editar el texto de acuerdo a nuestras necesidades ya podemos volver al modo normal presionando la tecla Esc.
Si la opción showmode del VIM está activada (comportamiento por defecto) entonces nosotros podemos saber que estamos en el
modo inserción al notar el texto --INSERTAR-- (o --INSERT-- en inglés) en la esquina inferior izquierda de la pantalla.
Modo visual
Este es un modo intermediario cuando se usa como parte de una operación posterior de edición. Este modo permite seleccionar texto a
nuestra elección para luego aplicar sobre él una operación tal como copiar, reemplazar, cortar, convertir a mayúsculas, etc.
Para ello tenemos tres formas distintas de empezar la selección de texto:
Al iniciar una selección visual podemos modificar el área de nuestro interés usando cualquiera de los comandos de movimientos ya
conocidos (0, $, h, b, e, G, etc).
Una vez que ya terminamos de seleccionar el área que nos interesa podemos ejecutar sobre dicho texto una operación de edición tal
como x o d (cortar), y (copiar), c (eliminar e insertar), etc.
Los comandos invocados con el operador / y ? se usan para buscar patrones de texto de acuerdo a como se resume debajo:
Búsqueda de texto
Comando Descripción
/patrón Busca hacia abajo patrón en el texto
?patrón Busca hacia arriba patrón en el texto
Los comandos invocados con el operador : generalmente permiten configurar preferencias del funcionamiento del editor VIM, realizar
operaciones de edición, u otros acorde a la tabla de comandos que debajo se resume:
Comandos de edición
Comando Descripción
:r FILE Inserta debajo de la línea actual el contenido del archivo FILE
:r! COMANDO Inserta debajo de la línea actual la salida del comando de Shell COMANDO
:w Guardar los cambios en el archivo
:w FILE Guardar como ... en el archivo FILE
:q Salir del editor
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 47
Source Linux
:q! Salir del editor sin guardar los cambios
:wq Guardar los cambios y salir
Comando Descripción
:set background=cadena Cambia la combinación de colores apropiada si el fondo es oscuro (cadena = dark) o si es claro
:set bg=cadena (cadena = light). Requiere la opción syntax habilitada
:set hlsearch
Resalta todas las coincidencias de patrones de texto previamente buscados con / o ?
:set hls
:set nohlsearch
Desactiva la opción hlsearch
:set nohls
:set ignorecase
Ignora la sensibilidad a mayúsculas cuando se busca texto con / o ?
:set ic
:set noignorecase
Desactiva la opción ignorecase
:set noic
:set incsearch
Resalta el texto buscado mientras lo escribimos usando / o ?
:set is
:set noincsearch
Desactiva la opción incsearch
:set nois
:set number
:set nu Muestra los números de línea en la parte izquierda de la pantalla
:set nonumber
Desactiva la opción number
:set nonu
:set ruler
:set ru Muestra el número de línea y columna del cursor en la esquina inferior derecha de la pantalla
:set noruler
Desactiva la opción ruler
:set noru
:set showmode
:set smd Muestra el modo actual de funcionamiento del VIM en la esquina inferior izquierda de la pantalla
:set noshowmode
Desactiva la opción showmode
:set nosmd
:syntax on Activa el coloreado de texto según la sintaxis reconocida del contenido
:syntax off Desactiva la opción syntax, apaga el coloreado
set number
set ruler
set incsearch
syntax on
set background=dark
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 48
Source Linux
2.7. Laboratorio N° 2
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Usando sólo comandos de Shell estudiados hasta el momento y a través de una única línea de comandos secuenciales
otener la siguiente información del procesador:
- vendor_id
- cpu MHz
- model name
- cache size
La información debe ser guardada en el archivo /tmp/lab2 y no debe contener líneas repetidas, y sólo debe mostrar la
información requerida mas no la descripción, es decir omitir las palabras vendor_id, cpu MHz, model name y cache size.
2. Listar los procesos del usuario root únicamente y ordenarlo de forma descendente según el valor de su PID, agregando el
resultado convertido todo a mayúsculas al final del archivo /tmp/lab2.
3. Crear un enlace duro /tmp/lab2.1 al archivo /tmp/lab2. Agregar al inicio de cada línea del archivo /tmp/lab2.1 (implica modificar
el archivo original) la hora en formato HH:MM. Analizar finalmente el contenido de los archivos /tmp/lab2 y /tmp/lab2.1
4. Crear un archivo empaquetado y comprimido de nombre lab2.tar.gz que contenga los archivos /tmp/lab2 y /tmp/lab2.1
quedando estos dos intactos. El archivo lab2.tar.gz debe ser creado en el directorio personal del usuario.
5. Como un usuario sin privilegios (distinto de root) enviar la señal KILL al proceso init y guardar la salida de de dicho
comando en el archivo /tmp/lab2 (al final del mismo), luego agregar al final del mismo archivo el código de error retornado por
el comando anterior (aquel que enviaba la señal KILL).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 49
Source Linux
2.7.1 Solución del laboratorio N° 2
1. Usando sólo comandos de Shell estudiados hasta el momento y a través de una única línea de comandos secuenciales
obtener la siguiente información del procesador:
- vendor_id
- cpu MHz
- model name
- cache size
La información debe ser guardada en el archivo /tmp/lab2 y no debe contener líneas repetidas, y sólo debe mostrar la
información requerida mas no la descripción, es decir omitir las palabras vendor_id, cpu MHz, model name y cache size.
2. Listar los procesos del usuario root únicamente y ordenarlo de forma descendente según el valor de su PID, agregando el
resultado convertido todo a mayúsculas al final del archivo /tmp/lab2.
3. Crear un enlace duro /tmp/lab2.1 al archivo /tmp/lab2. Agregar al inicio de cada línea del archivo /tmp/lab2.1 (implica modificar
el archivo original) la hora en formato HH:MM. Analizar finalmente el contenido de los archivos /tmp/lab2 y /tmp/lab2.1
$ ln /tmp/lab2 /tmp/lab2.1
$ HORA=$(date +%H:%M:%S)
$ ls -i /tmp/lab2 /tmp/lab2.1
$ cat /tmp/lab2
$ cat /tmp/lab2.1
4. Crear un archivo empaquetado y comprimido de nombre lab2.tar.gz que contenga los archivos /tmp/lab2 y /tmp/lab2.1
quedando estos dos intactos. El archivo lab2.tar.gz debe ser creado en el directorio personal del usuario.
5. Como un usuario sin privilegios (distinto de root) enviar la señal KILL al proceso init y guardar la salida de de dicho
comando en el archivo /tmp/lab2 (al final del mismo), luego agregar al final del mismo archivo el código de error retornado por
el comando anterior (aquel que enviaba la señal KILL).
+ Intentamos matar el proceso (señal KILL) init pero no podremos hacerlo, agregando la salida de error hacia un archivo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 50
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 51
Source Linux
Unidad 3: Administración de sistemas de archivos
3.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
Posteriormente como una variante remodelada del ATA tradicional aparece el Serial ATA (SATA) que admite velocidades superiores de
transmisión, ancho de banda superior, mayor longitud de cable, topología punto a punto y sobre todo caracterizado por transmitir la
información a través de vínculos seriales, sin sufrir la limitación del ATA/IDE de poder utilizar sólo 1 dispositivo por canal.
De manera análoga, el estándar SCSI que en sus inicios apareció con una naturaleza de comunicación paralela, se caracterizó
siempre por tener mejores prestaciones y rendimientos que ATA/IDE. Igualmente con el paso del tiempo el estándar SCSI evolucionó a
una variante de comunicación serial (SAS, FC-AL).
En los sistemas operativos Linux, sólo se mantiene dos distinciones de dispositivos de almacenamiento: dispositivos IDE y dispositivos
de almacenamiento SCSI. Esto no quiere decir que discos SATA, SAS o Storage de Fibra no puedan ser accedidos desde un sistema
Linux, sino que sólo se les distingue a todos ellos entre una de esas dos categorías.
Es así que los discos ATA/IDE de conector paralelo son reconocidos a modo general como dispositivos IDE, mientras que los discos
SCSI, SATA, SAS y otros dispositivos que sigan el estándar SCSI son reconocidos simplemente como dispositivos SCSI en Linux.
A este último grupo hay que agregar también todos aquellos dispositivos de almacenamiento masivo USB, los cuales son emulados
como SCSI por Linux. Por lo tanto cuando hagamos referencia a una memoria o un disco duro externo USB también los
interpretaremos como un dispositivo SCSI más.
Nomenclatura de dispositivos
La forma en que Linux nombra los dispositivos de almacenamiento como unidades floppy, cdrom, discos duros IDE o SCSI difiere bajo
ciertas reglas comunes que se han de mencionar como ejemplos en la siguiente tabla:
Dispositivo Descripción
/dev/fd0 Primera unidad floppy
/dev/fd1 Segunda unidad floppy
/dev/hda Dispositivo maestro en el primer controlador IDE (primario)
/dev/hdb Dispositivo esclavo en el primer controlador IDE (primario)
/dev/hdc Dispositivo maestro en el segundo controlador IDE (secundario)
/dev/hdd Dispositivo esclavo en el segundo controlador IDE (secundario)
/dev/sda Primer dispositivo SCSI
/dev/sdb Segundo dispositivo SCSI
/dev/sdc Tercer dispositivo SCSI
/dev/hdb2 Partición N° 2 del dispositivo esclavo en el primer controlador IDE
/dev/hdc5 Partición N° 5 del dispositivo maestro en el segundo controlador IDE
/dev/sdb1 Partición N° 1 del segundo dispositivo SCSI
Observaciones:
• Los dispositivos SCSI se van nombrando de acuerdo al orden en el que se conectan al sistema. Si por ejemplo conectamos
una memoria USB que es reconocida como /dev/sdb y luego un disco duro externo reconocido como /dev/sdc, al
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 52
Source Linux
desconectarlos y conectarnos nuevamente en el orden inverso la memoria USB será /dev/sdc y el disco duro /dev/sdb.
Particiones de disco
Una partición no es más que una división de un dispositivo de almacenamiento físico; esta división posee su propio sistema de
archivos. Comúnmente se crean particiones en los discos duros para tener la posibilidad de instalar más de un sistema operativo, dado
que cada uno por lo general utiliza siempre una la cual no es compartida. Sin embargo existen algunos sistemas operativos (por
ejemplo Linux) que requieren más de una partición para su instalación (al menos 1 para la swap y 1 para la raíz).
Tipos de particiones
Existen tres tipos de particiones que pueden ser creadas en un disco:
• Partición primaria, es una partición básica o cruda, y sólo puede existir 4 de éstas en un disco o 3 primarias y 1 extendida.
Este tipo de partición depende de la existencia de una tabla de particiones alojada en el MBR y sí es capaz de crear un
sistema de archivos en este tipo de partición.
• Partición extendida, es una partición que actúa como una primaria para contener en su interior particiones lógicas. Se creó
con la finalidad de acabar con la limitación de 4 particiones (primarias) por disco. Puede existir sólo una partición extendida
por disco, sólo puede almacenar particiones lógicas y no es posible crear sistemas de archivos en las particiones extendidas.
• Partición lógica, es una partición que forma parte de una partición extendida, preparada para crear en él algún sistema de
archivos para el almacenamiento de datos.
Tabla de particiones
La tabla de particiones es una estructura de datos de 64-bytes que provee información básica al sistema operativo de cómo está
dividido el disco en particiones primarias.
Existen distintos tipos de tablas de particiones cada una orientada a ser usada en distintos sistemas y arquitecturas, tales como msdos,
irix, sun, s390, amiga, bsd, gpt, entre otras. Sin embargo para nuestro escenario común trabajaremos con tablas de tipo msdos, que es
la que entienden todos los sistemas operativos de PC.
Identificador de partición
Un identificador de partición es una pequeña etiqueta asignada a una partición que permite a un sistema operativo saber si puede
leerla o no (entender su contenido).
Existen varios identificadores tales como 7 (HPFS/NTFS), b (W95 FAT32), 82 (Linux swap), 83 (Linux), 8e (Linux LVM), los cuales son
asignados en el momento de creación de una partición.
Sin embargo estos identificadores no deben confundirse con los sistemas de archivos, pues se puede tener por ejemplo una partición
con un ID 83 (Linux) y contener un sistema de archivos tal como ext3, reiserfs, xfs u otros.
Sistema de archivos
Un sistema de archivos es el método utilizado por un sistema operativo para almacenar y organizar ficheros así como la información
que éstos contienen para lograr que sea fácil encontrarlos.
Algunas de las funciones que tiene un sistema de archivos son:
Existen diversos sistemas de archivos, algunos diseñados a trabajar directamente con dispositivos de almacenamiento (discos duros,
memorias USB, CDROM/CDRW, u otros) así como también otros para trabajar como clientes accediendo a otro sistema en red.
La siguiente tabla resume información de algunos de los sistemas de archivos más comunes:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 53
Source Linux
Sistema de archivos que se creó como evolución de ext2, que a diferencia de este último ya soporta
journaling (registro por diario). No es el sistema de archivos más eficiente y escalable comparado con otros
ext3 (ReiserFS, XFS, JFS) pero es el que exige un menor consumo de CPU, y se le considera ser el más seguro
por ser conocido y probado durante mayor tiempo.
Sistema de archivos creado como evolución de ext3, con características adicionales añadidas y de mejor
ext4
rendimiento que su predecesor.
Sistema de archivos creado por la empresa Namesys, cuyo desarrollo se ha visto interrumpido tras
problemas judiciales que enfrenta su creador Hans Reiser por cargos de asesinato.
ReiserFS
Se caracteriza por soportar journaling y ofrecer un mejor rendimiento que ext2 y ext3 para archivos menores
a 4 KB, por lo que se recomienda su uso para servicios de correo, news o caché HTTP.
Sistema de archivos creado por Sillicon Graphics para su sistema operativo IRIX. Se caracteriza por tener
XFS
soporte de journaling, un alto rendimiento para archivos y sistemas de archivos de gran tamaño.
Sistema de archivos creado por IBM para su sistema operativo AIX y liberado bajo la licencia GNU GPL. Se
JFS caracteriza por tener soporte de journaling, un alto rendimiento para archivos y sistemas de archivos de gran
tamaño.
Normal publicada en el año 1986 como un estándar ISO que define el formato para el almacenamiento de
ISO 9660 archivos en discos compactos. El objetivo es que los medios escritos bajo este formato sean entendibles por
cualquier sistema operativo tal como Windows, Linux, Mac OS, UNIX y otros.
Sistema de archivos con estándar ISO 9660 que fue desarrollado por Adaptec para utilizar las grabadoras de
CD/DVD como dispositivos de almacenamiento lógico. Esto permite que se pueda realizar operaciones de
UDF
lectura, escritura o modificación de datos en un disco compacto reescribible como si se tratase de un disco
duro.
Protocolo de nivel de aplicación que se usa como sistema de archivos distribuido en red. Creado
NFS originalmente por Sun Microsystems, este protocolo (llamado comúnmente sólo sistema de archivos en la
práctica) se usa en gran cantidad de sistemas UNIX y Linux, por lo general para compartición de datos.
Protocolo de nivel de aplicación que permite la compartición de archivos e impresoras en red. Creado
originalmente por IBM, este protocolo se convirtió en la base de las redes Microsoft.
SMB
El protocolo SMB fue modificado inicialmente por Microsoft agregándole características propias que difieren
del SMB original.
Protocolo de nivel de aplicación que surge en 1998 como producto de una serie de modificaciones mayores
CIFS por parte de Microsoft al protocolo SMB para agregarle características adicionales como enlaces simbólicos,
enlaces duros y tamaños de archivos mayores.
Observaciones:
• Cada vez que hacemos mención a un dispositivo como /dev/sda o /dev/hdb nos estamos refiriendo al disco completo, mientras
que al hacer referencia al mismo dispositivo con un número al final como /dev/sda3 o /dev/hdb2 nos estaremos refiriendo a
una de las particiones de dicho disco.
Sin embargo esta numeración al final de los dispositivos no existe para unidades de CDROM o CDRW, dado que éstos no
son capaces de almacenar particiones.
• Los dispositivos SCSI permiten crear sólo un máximo de 15 particiones (considerando 3 primarias, 1 extendida, y 11 lógicas),
mientras que los dispositivos IDE permiten un máximo de 63 particiones (considerando 3 primarias, 1 extendida, y 59
lógicas).
Creación de particiones
Desde la línea de comandos existen dos conocidas herramientas de administración de la tabla de particiones: parted y fdisk. Nos
centraremos en la segunda para crear y eliminar particiones.
La herramienta fdisk debe ser usada con un dispositivo que haga referencia a un disco entero (/dev/sda, /dev/hdb, etc) y no hacia una
partición (/dev/sda1, /dev/hdb3), para lo cual se requiere privilegios de root como se muestra a continuación:
# fdisk /dev/hdb
El número de cilindros para este disco está establecido en 60801.
No hay nada malo en ello, pero es mayor que 1024, y en algunos casos
podría causar problemas con:
1) software que funciona en el inicio (p.ej. versiones antiguas de LILO)
2) software de arranque o particionamiento de otros sistemas operativos
(p.ej. FDISK de DOS, FDISK de OS/2)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 54
Source Linux
Como se nota arriba, fdisk ya ha reconocido la geometría del disco duro y nos muestra un prompt listo para aceptar órdenes,
sugiriéndonos que el comando m nos muestra la ayuda de la herramienta, de la cual debajo mostramos los comandos más comunes:
Cada uno de los cambios que hacemos con fdisk ya sea eliminar, crear o modificar una partición no se hacen efectivos en la tabla de
particiones sino hasta que guardemos los cambios usando el comando w, por ello sólo debemos usar este comando cuando estemos
totalmente seguros de los cambios hechos.
Ejemplo 14:
a) Creación de una tabla de particiones vacía en un disco duro nuevo (en blanco) y luego crear 5 particiones como sigue:
# fdisk /dev/hdb
El dispositivo no contiene una tabla de particiones DOS válida ni una etiqueta de disco Sun o SGI
o OSF
Se está creando una nueva etiqueta de disco DOS. Los cambios sólo
permanecerán en la memoria, hasta que decida escribirlos. Tras esa
operación, el contenido anterior no se podrá recuperar.
+ Creamos la partición N° 1:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 55
Source Linux
+ Creamos la partición N° 2:
+ Creamos la partición N° 3:
+ Creamos la partición N° 5:
+ Creamos la partición N° 6:
+ Como la partición N° 1 aún tiene el identificador Linux lo cambiamos a Linux swap consultando previamente el listado de
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 56
Source Linux
identificadores disponibles:
+ Volvemos a visualizar la tabla de particiones, si todo está correcto guardamos los cambios y salimos:
b) Vamos a marcar la partición N° 2 como activa (booteable), luego eliminaremos las particiones lógicas 5 y 6 en favor de crear una que
ocupe la capacidad que ambas ocupaban inicialmente:
+ Marcamos como activa la partición N° 2 y luego visualizamos los cambios hechos (apreciar el símbolo *):
# fdisk /dev/hdb
Orden (m para obtener ayuda): a
Número de partición (1-6): 2
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 57
Source Linux
Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/hdb1 1 970 488848+ 82 Linux swap / Solaris
/dev/hdb2 * 971 1165 98280 83 Linux
/dev/hdb3 1166 8322 3607128 5 Extendida
/dev/hdb5 1166 3104 977224+ 83 Linux
/dev/hdb6 3105 8322 2629840+ 83 Linux
+ Visualizamos los cambios hechos, si todo está correcto guardamos los cambios y salimos:
# partprobe
+ Finalmente verificamos nuevamente que la tabla de particiones haya quedado como lo queríamos:
# fdisk -l /dev/hdb
Observaciones:
• Normalmente el kernel no es capaz de leer los nuevos cambios hechos a la tabla de particiones sino hasta el próximo
arranque del sistema. Esta limitación no nos permitiría dar formato a ninguna de las nuevas particiones que hayamos podido
crear.
• Sin embargo la herramienta partprobe nos permite forzar la relectura de la tabla de particiones por parte del sistema
operativo para superar la limitación antes mencionada sin necesidad de reiniciar el sistema.
• Para fdisk es indiferente si se usan mayúsculas o minúsculas en sus comandos (a, p, n, l, d, ...)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 58
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 59
Source Linux
3.3. Formato de dispositivos
Memoria SWAP
El término SWAP o espacio de intercambio es una zona del disco que usan los sistemas operativos para almacenar imágenes de
procesos que no se mantienen en memoria física.
También se le suele conocer a la SWAP como memoria virtual, dado que el criterio básico de funcionamiento consiste en hacer creer al
sistema operativo que cuenta con más memoria de la que realmente tiene físicamente (RAM).
Normalmente el sistema operativo puede manejar tantos procesos como su memoria lo permitan. Si ésta se agota no será posible
ejecutar más procesos mientras que otros mantengan usando la memoria del sistema.
Es así que como forma de solucionar estas situaciones el sistema operativo coloca la imagen (o parte de ella) de un proceso por lo
general poco activo en el área de intercambio (disco) para liberar memoria física en la cual ha de colocar otro proceso de mayor
actividad. Mientras no haga falta el proceso inactivo puede permanecer en el espacio de intercambio hasta el momento en que éste
retome actividad pasando nuevamente a memoria física.
El espacio de intercambio en sistemas operativos Linux es común que se coloque en una partición exclusiva, sin embargo esto no es
obligatorio pues también es posible crear un espacio de intercambio en un fichero dentro del sistema de archivos.
El ejemplo arriba mostrado asume que el archivo de swap será /swap.00 pero bien podría ser cualquier otro distinto que el administrador
decida (Ejm: /root/archivo-swap, /var/swap.1, /boot/swap1, etc)
También podemos notar que se está creando el archivo de swap usando bloques de 1 MB (bs=1M), creando 500 de éstos
(count=500) con lo que conseguiríamos 500 MB de memoria swap.
Una vez creado el espacio físico para la swap es necesario darle formato, es decir prepararla para que el sistema operativo la pueda
usar como área de intercambio. Esto es posible a través de la herramienta mkswap como se muestran debajo:
# mkswap /dev/hdb1
El ejemplo de arriba prepara una partición para ser usada como swap. Se usaría de forma similar para un archivo usado como swap:
# mkswap /swap.00
Ahora que ya se tiene preparado el espacio físico para la swap sólo nos queda activarlo, es decir ordenarle al sistema operativo que lo
use. Para eso usaremos las herramientas swapon y swapoff para activar y desactivar las áreas de intercambio respectivamente:
Opciones:
-a : Activa todos los dispositivos/archivos marcados como swap en /etc/fstab excepto quienes usan la opción noauto
-s : Imprime un listado del uso de memoria swap por cada dispositivo/archivo activo
-p PRI : Activa un dispositivo/archivo como swap con una prioridad PRI
La prioridad PRI es un valor numérico que puede variar entre 32767. A mayor valor numérico mayor será la prioridad.
Opciones:
-a : Desactiva todos los dispositivos/archivos marcados como swap en /etc/fstab excepto quienes usan la opción noauto
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 60
Source Linux
Ejemplo 15:
a) Crear dos archivos, uno de 300 MB y otro de 150 MB y prepararlos para funcionar como área de intercambio:
b) Imprimir un listado del uso actual de memoria swap. Activar uno a uno los archivos creados como swap para el sistema e ir
comparando el uso actual de memoria swap del sistema con las herramientas free y swapon:
# swapon -s
# free -m
# swapon -p 10 /root/swap.01
# swapon -p 30 /root/swap.02
# free -m
# swapon -s
# swapoff /root/swap.01
# swapoff /root/swap.02
Sólo los sistemas de archivos de disco (FAT32, ext3, ext4, ReiserFS, etc) son los únicos que se puedan utilizar para dar formato a
dispositivos.
En cambio los sistemas de archivos de red tal como NFS, SMB/CIFS no se usan para dar formato sino sólo para montar un recurso
remoto en la red.
Opciones:
En realidad mkfs es sólo un frontend de distintas herramientas que llevan la forma mkfs.fs donde fs es el sistema de archivos. Por
ello a continuación revisaremos opciones específica de cada uno de los sistemas de archivos.
Opciones:
Si se usa la herramienta mkfs.ext2 se invocará a mke2fs con la opción -t ext2. De manera análoga mkfs.ext3 invoca a mke2fs -t ext3 y
mkfs.ext4 invoca a mke2fs -t ext4
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 61
Source Linux
mkdosfs [opciones] <dispositivo/archivo>
Crea sistemas de archivos vfat (FAT)
Opciones:
Observaciones:
• Es importante tener en cuenta que se puede crear sistemas de archivos sólo en dispositivos que no estén montados.
Opciones:
-c MAX : Asigna MAX como número máximo de veces que el sistema de archivos debe ser montado antes de ser chequeado
-C NUM : Asigna NUM como el número de veces que el sistema de archivos ha sido montado
-i INT : Define el máximo intervalo de tiempo entre dos chequeos del sistema de archivos según el valor de INT
-l : Muestra la información completa del sistema de archivos
-L LABEL : Asigna LABEL como etiqueta del sistema de archivos
INT está conformado por un valor numérico y un sufijo como 'd' (días), 'm' (meses) o 'w' (semanas). Ejm: 30d, 4w, 2m, etc.
* El comando e2label también permite manipular la etiqueta de sistemas de archivos ext2 y ext3
Observaciones:
• Es recomendable (por no decir obligatorio) desmontar el dispositivo que contiene un sistema de archivos antes de
chequearlo.
Ejemplo 16:
a) Crear un sistema de archivos ext3 en /dev/hdb2 con una etiqueta denominada BOOT:
b) Crear un sistema de archivos FAT32 en /dev/sda5 con una etiqueta denominada DATA:
# tune2fs -l /dev/hdb2
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 62
Source Linux
fsck [opciones] <dispositivo/archivo>
Chequea la consistencia de sistemas de archivos en dispositivos
Opciones:
fd es un descriptor de archivo cuyo valor puede estar representado por 1 (stdout) o 2 (stderr).
En realidad fsck es sólo un frontend de distintas herramientas que llevan la forma fsck.fs donde fs es el sistema de archivos. Por
ello a continuación revisaremos opciones específica de cada uno de los sistemas de archivos.
Opciones:
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 63
Source Linux
3.4. Montaje
Conceptos básicos
El montaje es una operación del sistema operativo que consiste en proyectar el contenido de un dispositivo de almacenamiento en un
enlace lógico (un directorio).
Como se ha estudiado ya en este documento, los sistemas UNIX mantienen un árbol de directorios con un origen único que es la raíz
(/), y no existen las unidades de disco (C:, D:, E:) como existe en plataformas Windows asociado para cada dispositivo conectado al
sistema.
En cambio los sistemas UNIX acceden al contenido de dispositivos (que contienen un sistema de archivos dentro) a través de un
directorio cualquiera debajo del árbol que empieza por la raíz (/).
Durante el tiempo que el sistema operativo usa el sistema de archivos de un dispositivo se dice que éste está montado. Luego de
terminar las operaciones necesarias sobre ese sistema de archivos es necesario desmontar el dispositivo, momento en el cual el
directorio inicial sobre el cual estaba montado queda libre nuevamente.
Cabe resaltar que si se decide montar un dispositivo bajo un directorio que contiene datos éstos desaparecerán (quedan ocultos)
mientras hay un sistema de archivos montado encima, y esos datos se harán nuevamente visibles al sistema cuando se desmonte el
dispositivo.
El archivo /etc/fstab
Este archivo es el encargado de definir una lista de dispositivos y sistemas de archivos disponibles en el sistema. En este archivo se
define cómo montar cada uno de ellos a través de opciones específicas para cada dispositivo. Debe tenerse en cuenta que este es un
archivo que sólo el usuario root puede editarlo.
1. Dispositivo : Referencia al dispositivo que contiene el sistema de archivos a montar. Este dispositivo puede ser especificado
de una de 3 formas:
2. Punto de montaje : Ruta absoluta del directorio donde se proyecta el contenido del sistema de archivos.
3. Tipo de sistema de archivos : Especifica el tipo específico de sistema de archivos encontrado en el dispositivo. (2)
(3)
4. Opciones de montaje : Opciones de montaje específicas para cada sistema de archivos. Estas opciones están
documentadas en mount(8).
5. Volcado de backup (Dump): Especifica si la herramienta de backup (dumpe2fs para sistemas de archivos ext2, ext3, ext4)
debe o no hacer un volcado del sistema de archivos al arranque. Por lo general este campo debe tener valor 0 (no hace
volcado).
6. Orden de chequeo (Pass): Especifica si se debe chequear (valor 1 ó 2) o no (valor 0) el sistema de archivos con fsck. Si
se desea habilitar el chequeo debe colocarse el valor 1 para el sistema de archivos raíz / (significa que se chequeará
primero) y 2 para otros sistemas de archivos (significa que se chequeará después de la raíz).
(1) Los dispositivos pueden ser identificados también a través de un UUID (Universally Unique Identifier). Se utiliza la
herramienta blkid para consultar el UUID y etiqueta (LABEL) de los dispositivos del sistema:
# blkid
# blkid /dev/hdb2
(2) El tipo de sistema de archivos se expresa como una única palabra en minúsculas que lleva el nombre del sistema de
archivos tal como ext2,ext3, ext4, reiserfs, xfs, jfs, vfat, ntfs, ntfs-3g, nfs, smbfs, cifs, iso960, entre otros. Si se especifica la
palabra clave auto como tipo de sistema de archivos se instruirá al sistema para que intente detectar de forma automática
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 64
Source Linux
qué sistema de archivos existe dentro del dispositivo y luego montarlo.
(3) Algunas de las opciones de montaje más comunes se resumen en la siguiente tabla:
Aplicable al sistema
Opción Descripción
de archivos
defaults Cualquiera Equivalente a usar las opciones rw, suid, dev, exec, auto, nouser y async
Todas las operaciones de E/S son hechas de manera síncrona (sync) o asíncrona
sync / async Cualquiera (async). La opción sync es válida sólo para los sistemas de archivos ext2, ext3,
vfat y ufs.
auto / noauto Cualquiera Activa (auto) o desactiva (noauto) la posibilidad de ser montado con mount -a
dev / nodev Cualquiera Activa (dev) o desactiva (nodev) la interpretación de archivos de dispositivos.
exec / noexec Cualquiera Activa (exec) o desactiva (noexec) la ejecución de binarios.
suid / nosuid Cualquiera Activa (suid) o desactiva (nosuid) el efecto de los bits SUID o SGID en archivos.
Activa (user) o desactiva (nouser) la posibilidad de que un usuario ordinario
user / nouser Cualquiera (distinto de root) pueda montar el dispositivo. Esta opción implica las opciones
noexec, nosuid y nodev.
ro Cualquiera Monta el dispositivo en modo de sólo lectura.
rw Cualquiera Monta el dispositivo en modo de lectura y escritura.
remount Permite remontar un dispositivo ya montado para cambiar sus opciones de montaje.
Cualquiera
(No sirve para cambiar el punto de montaje).
Activa la posibilidad de que cualquier dispositivo montado por un usuario pueda ser
users Cualquiera desmontado por cualquier otro usuario. Esta opción implica las opciones noexec,
nosuid y nodev.
user=arg /
username=arg smbfs, cifs Especifica a través de arg el usuario con el cual conectarse.
password=arg smbfs, cifs Especifica a través de arg la contraseña del usuario con el cual conectarse.
Especifica a través de file la ruta del archivo que contiene las credenciales usadas
para la conexión. El contenido del archivo debe tener la forma:
credentials=file smbfs, cifs
username=arg
password=arg
uid=arg smbfs, cifs, vfat, ntfs, Especifica a través de arg el UID del usuario que figurará como propietario del
ntfs-3g, iso9660 sistema de archivos montado.
gid=arg smbfs, cifs, vfat, ntfs, Especifica a través de arg el GID del grupo que figurará como propietario del sistema
ntfs-3g, iso9660 de archivos montado.
domain=arg smbfs, cifs Especifica a través de arg el dominio (o grupo de trabajo) del usuario a conectarse.
umask=arg Especifica a través de arg en formato octal el valor de la máscara (umask) para el
vfat, ntfs, ntfs-3g
sistema de archivos montado.
acl ext2, ext3 Activa (acl) o desactiva (noacl) el soporte de ACL (Access Control List).
Especifica a través de arg el comportamiento a seguir cuando se encuentra un error
al realizar el montaje del dispositivo. Los posibles valores de arg son:
errors=arg ext2, ext3
continue : Ignora los errores y marca el sistema de archivos como erróneo.
remount-ro : Remonta el sistema de archivos en modo de sólo lectura.
panic : Provoca un kernel panic y detiene el sistema.
usrquota /
ext2, ext3 Activa el soporte de cuotas de usuario (usrquota) y/o cuotas de grupo (grpquota).
grpquota
user_xattr / Activa (user_xattr) o desactiva (nouser_xattr) el soporte de atributos
nouser_xattr ext2, ext3
extendidos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 65
Source Linux
Observaciones:
• Más información de opciones de montaje del sistema de archivos smbfs/cifs pueden ser encontraras en mount.cifs(8).
• El sistema operativo al arrancar ejecuta la orden mount -a. Por ello si se desea configurar un dispositivo para que siempre
se monte al arranque del sistema no debe olvidarse incluir la opción auto o defaults (o no incluir noauto) dentro de su
entrada en /etc/fstab.
Ejemplo 17:
Por otro lado la herramienta umount se encarga de desmontar un sistema de archivos. Este comando recibe como parámetro o bien el
punto de montaje o la ruta de un dispositivo actualmente montado.
Opciones:
Normalmente el comando mount requiere se indique tanto el dispositivo a montar como el punto de montaje, como se muestra debajo:
Sin embargo si ya existe en /etc/fstab una entrada que defina o bien el dispositivo a montar o bien el punto de montaje, entonces se
puede invocar al comando mount de una de las dos formas breves:
# mount <dispositivo>
En cualquiera de ambas formas, el comando mount intentará adivinar cuáles son las opciones de montaje y tipo de sistema de
archivos basado en la información encontrada en /etc/fstab.
Tener en cuenta que esta forma breve de montaje es la única que puede invocar un usuario ordinario (distinto de root) para montar un
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 66
Source Linux
dispositivo siempre y cuando tenga la palabra user o users entre sus opciones dentro de su entrada correspondiente en /etc/fstab.
Ejemplo 18:
# mount
# cat /etc/mtab
c) Mostrar todos los dispositivos montados con ext3 mostrando las etiquetas de cada uno:
# mount -t ext3 -l
d) Liberar el punto de montaje /mnt y montar ahí el dispositivo cuya etiqueta es DATA:
# umount /mnt
# mount -L "DATA" /mnt
e) Remontar en modo sólo lectura y activar el soporte ACL del dispositivo anteriormente montado:
f) Mover el punto de montaje de /mnt hacia /media del dispositivo anteriormente montado y luego reflejar el montaje de manera
concurrente en el directorio /opt evaluando la información de montaje luego de cada operación realizada:
g) Crear la configuración apropiada para que el dispositivo /dev/hdb5 sea montado como ext3 debajo de /data siempre de forma manual
(no debe ser montada automáticamente al arranque del sistema) y sea posible ser montada por un usuario ordinario:
$ mount /data
# umount /dev/cdrom
# eject
# eject -t
Observaciones:
• En realidad cuando se trabajamos con unidades de CDROM no es necesario desmontarlas si deseamos expulsar el disco ya
que el comando eject se encarga de hacerlo antes de expulsarlo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 67
Source Linux
Montaje de dispositivos NTFS
El kernel Linux trae consigo un soporte nativo para montar dispositivos NTFS. Sin embargo el soporte de éste es completo en modo de
sólo lectura, mientras que en modo escritura el soporte es inestable, limitado y prácticamente inservible.
Este soporte nativo se utiliza a través del tipo de sistema de archivos ntfs invocado desde la línea de comandos de mount como sigue:
Sin embargo si se desea un soporte estable de lectura y escritura de NTFS es necesario utilizar un driver de terceros (no está incluido
en el kernel Linux original). Este driver es conocido como NTFS-3G desarrollado bajo licencia GNU GPL, que se instala generalmente
como un componente aparte del sistema.
Afortunadamente la mayoría de distribuciones Linux modernas ya incluyen entre sus repositorios de paquetes a NTFS-3G (excepto
Red Hat, CentOS), por lo que ya debería estar listo para instalarse y usarse.
Para montar un dispositivo NTFS con el driver NTFS-3G debemos usar el tipo de sistema de archivos ntfs-3g en la línea de comandos
de mount como sigue:
Más información sobre NTFS-3G o sus opciones de montaje están disponibles en mount.ntfs-3g(8).
Cabe resaltar que siempre una imagen ISO se monta en modo sólo lectura, no es posible modificar su contenido. Esto debido a que el
estándar ISO 9660 ha sido diseñado para ser leído únicamente.
Ejemplo 19:
a) Montar la 1ra. partición de nuestro segundo disco SATA que contiene un sistema operativo Windows XP:
b) Montar la imagen ISO de DVD que acabamos de descargar de Red Hat Enterprise Linux 5.4:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 68
Source Linux
3.5. Laboratorio N° 3
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
El tamaño de cada partición puede quedar a criterio del usuario. No olvidar asignar los identificadores de partición a cada una
de las que se vayan creando.
Tener en cuenta que FreeBSD, Solaris y Windows no se instalan en particiones lógicas.
2. Sin reiniciar el sistema luego de la tarea anterior, preparar la partición para SWAP y crear un sistema de archivos ext3 en la
partición destinada para /boot2, configurándola para que se monte con soporte de ACLs al arrancar el sistema operativo.
3. Asignar la etiqueta "/boot2" a la partición destinada para /boot2 y consultar luego la información de dicho dispositivo para
averiguar su UUID y etiqueta asignada.
4. Activar la partición destinada para SWAP con una prioridad de 10, y configurarla para que se active al arrancar el sistema.
Apoyarse en la documentación de swapon(8) y fstab(5) para configurar correctamente la prioridad y otros parámetros de
activación de la swap según /etc/fstab.
5. Averiguar la cantidad de veces que ha sido montado el dispositivo destinado para /boot2, luego incrementar ese valor en 5 y
definir en 30 la cantidad máxima de montajes que puede hacerse del dispositivo antes de realizarle un chequeo.
6. Configurar el sistema para que los usuarios sin privilegios (distinto de root) puedan montar y desmontar la unidad de
CDROM.
7. Proyectar de manera concurrente el contenido del punto de montaje /boot2 en el directorio /mnt/boot. Luego consultar la
información de dispositivos montados.
8. Nuestro sistema ha sido conectado a una SAN usando Fibre Chanel con una LUN reconocida por Linux como /dev/sde (con 3
particiones dentro), y mantiene también una conexión hacia un NAS vía iSCSI hacia un dispositivo de almacenamiento
reconocido por Linux como /dev/sdf1. Ya se han definido puntos de montaje estáticos a dichos dispositivos a través de sus
rutas absolutas (/dev/sde1, /dev/sde2, /dev/sde3 y /dev/sdf1) en el archivo /etc/fstab.
Luego de una caída del suministro de energía todos los servidores son reiniciados, pero la SAN es restaurada 10 minutos
después que inicia el servidor NAS, trayendo como consecuencia que la LUN ofrecida por el SAN figura ahora como /dev/sdf
en nuestro sistema Linux.
¿Qué solución sugiere dar para que no suceda en el futuro aquel desorden en la nomenclatura de los dispositivos del SAN y
NAS?
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 69
Source Linux
3.5.1. Solución del laboratorio N° 3
El tamaño de cada partición puede quedar a criterio del usuario. No olvidar asignar los identificadores de partición a cada
una de las que se vayan creando.
Tener en cuenta que FreeBSD, Solaris y Windows no se instalan en particiones lógicas.
# fdisk /dev/sdc
Comando y parámetros: o
Comando y parámetros: t, 1, 7
Comando y parámetros: t, 2, a5
Comando y parámetros: t, 3, bf
Comando y parámetros: t, 4, 8e
Comando y parámetros: t, 6, 82
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 70
Source Linux
+ Guardar los cambios en la tabla de particiones:
Comando y parámetros: w
2. Sin reiniciar el sistema luego de la tarea anterior, preparar la partición para SWAP y crear un sistema de archivos ext3 en la
partición destinada para /boot2, configurándola para que se monte con soporte de ACLs al arrancar el sistema operativo.
# partprobe
# mkswap /dev/sdc7
+ Configuramos para que se monte al arranque con soporte de ACL agregando la siguiente línea al archivo /etc/fstab:
3. Asignar la etiqueta "/boot2" a la partición destinada para /boot2 y consultar luego la información de dicho dispositivo para
averiguar su UUID y etiqueta asignada.
# blkid /dev/sda6
4. Activar la partición destinada para SWAP con una prioridad de 10, y configurarla para que se active al arrancar el sistema.
Apoyarse en la documentación de swapon(8) y fstab(5) para configurar correctamente la prioridad y otros parámetros de
activación de la swap según /etc/fstab.
# swapon -p 10 /dev/sda7
+ Configurar para que se active al arranque con dicha prioridad agregando la siguiente línea al archivo /etc/fstab:
5. Averiguar la cantidad de veces que ha sido montado el dispositivo destinado para /boot2, luego incrementar ese valor en 5 y
definir en 30 la cantidad máxima de montajes que puede hacerse del dispositivo antes de realizarle un chequeo.
+ Consultar la información del sistema de archivos en /dev/sda6 y buscar la línea que diga Mount count:
# tune2fs -l /dev/sda6
+ Del valor obtenido (asumiendo que es 2) incrementarlo en 5 y asignarlo como cantidad de veces montada al dispositivo
/dev/sda6:
# tune2fs -C 7 /dev/sda6
# tune2fs -c 30 /dev/sda6
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 71
Source Linux
6. Configurar el sistema para que los usuarios sin privilegios (distinto de root) puedan montar y desmontar la unidad de
CDROM.
7. Proyectar de manera concurrente el contenido del punto de montaje /boot2 en el directorio /mnt/boot. Luego consultar la
información de dispositivos montados.
8. Nuestro sistema ha sido conectado a una SAN usando Fibre Chanel con una LUN reconocida por Linux como /dev/sde (con 3
particiones dentro), y mantiene también una conexión hacia un NAS vía iSCSI hacia un dispositivo de almacenamiento
reconocido por Linux como /dev/sdf1. Ya se han definido puntos de montaje estáticos a dichos dispositivos a través de sus
rutas absolutas (/dev/sde1, /dev/sde2, /dev/sde3 y /dev/sdf1) en el archivo /etc/fstab.
Luego de una caída del suministro de energía todos los servidores son reiniciados, pero la SAN es restaurada 10 minutos
después que inicia el servidor NAS, trayendo como consecuencia que la LUN ofrecida por el SAN figura ahora como /dev/sdf
en nuestro sistema Linux.
¿Qué solución sugiere dar para que no suceda en el futuro aquel desorden en la nomenclatura de los dispositivos del SAN y
NAS?
+ Los dispositivos SCSI son nombrados por el sistema operativo como /dev/sda, /dev/sdb, /dev/sdc y así sucesivamente según
el orden en el que son reconocidos o conectados. Por ello si no tenemos la certeza del orden en el que serán conectados
tanto el SAN como NAS al sistema debemos configurar su montaje en el archivo /etc/fstab en base a un valor invariable en el
arranque: según sus etiquetas o según sus UUID
+ Si deseamos trabajar con etiquetas, debemos averiguar los UUID de los dispositivos:
# blkid
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 72
Source Linux
Unidad 4: Administración de usuarios
4.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
Un usuario tiene la posibilidad de pertenecer a múltiples grupos, pero siempre sólo uno de ellos representa el grupo primario de dicho
usuario, mientras que los grupos restantes representan sus grupos secundarios.
En Linux los usuarios y sus atributos están definidos en el archivo /etc/passwd, mientras que los grupos en el archivo /etc/group.
El archivo /etc/passwd
Archivo de texto plano que contiene información de las cuentas de usuario del sistema y sus atributos. Este archivo debe tener
permisos de lectura para todos los usuarios, pero es modificable sólo por root. La sintaxis de este archivo es como sigue:
Directorio
Cuenta Contraseña UID GID GECOS Shell
personal
El archivo /etc/passwd separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
2. Contraseña : Puede contener la contraseña encriptada del usuario, un asterisco (1) (*) o la letra 'x' (2)
. Si se omite este campo
el usuario podrá iniciar sesión sin password alguno, tan sólo ingresando su cuenta.
5. GECOS : Campo opcional. Puede contener una serie de datos (nombre completo, número de oficina, número telefónico u
otros) cada uno separado por comas, pero generalmente sólo suele contener el nombre completo del usuario.
6. Directorio personal : La ruta absoluta del directorio personal del usuario, donde éste es ubicado tras su inicio de sesión.
7. Shell : Programa a ser ejecutado por el usuario tras el inicio de sesión. Si se omite se asume /bin/sh. Si se asigna a este
campo un valor que no represente una shell válida o ejecutable el usuario no será capaz de iniciar sesión.
A continuación se muestran dos ejemplos de entradas del archivo /etc/passwd, la segunda difiere de la primera en que se usa un
sistema shadow para la gestión de contraseñas.
eramirez:$1$2kQCDMeH$pbYGf5eL.alohiVI7CwRx.:1000:1000:Edson Ramirez:/home/admin:/bin/bash
achang:x:1001:1001::/home/achang:/bin/false
El archivo /etc/group
Archivo de texto plano que contiene información de los grupos a los cuales pertenecen los usuarios del sistema. Este archivo debe
tener permisos de lectura para todos los usuarios, pero es modificable sólo por root. La sintaxis de este archivo es como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 73
Source Linux
Nombre de grupo Contraseña GID Lista de usuarios
El archivo /etc/group separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
4. Lista de usuarios : Lista de usuarios separada por coma que son miembros del grupo.
(1) Un valor de 'x' en el campo de contraseñas significa que se utiliza el sistema shadow para la gestión de claves.
A continuación se muestran dos ejemplos de entradas del archivo /etc/group, la segunda difiere de la primera en que se usa un sistema
shadow para la gestión de contraseñas.
sysadmin:$1$2kQCDMeH$pbYGf5eL.alohiVI7CwRx.:500:eramirez,achang,root
guests:x:501:tsoto,guest1,mruiz,esolis
Contraseñas Shadow
En los inicios de UNIX, las contraseñas encriptadas de los usuarios y grupos era almacenada dentro del mismo archivo /etc/passwd y
/etc/group respectivamente, los cuales tienen acceso de lectura para todos los usuarios. Esto representaba cierto nivel de inseguridad
pues cualquier usuario sin privilegios tenía acceso a leer la contraseña encriptada de cualquier otro usuario (incluido root), y esto
conllevaba a un potencial ataque de fuerza bruta para adivinar los passwords.
Es así que como solución a este problema aparece alrededor del año 1988 el sistema de contraseñas Shadow para UNIX, siendo
portado a Linux alrededor del año 1992.
Este sistema de contraseñas Shadow tiene por objetivo almacenar los passwords encriptados de los usuarios en el archivo /etc/shadow
y de los grupos en /etc/gshadow, archivos que sólo usuarios privilegiados (root) tienen acceso de lectura.
Esto trae como consecuencia que los correspondientes campos de contraseñas de los archivos /etc/passwd y /etc/group son
reemplazados por la letra 'x' como se indicó con anterioridad.
Adicionalmente este sistema Shadow trae consigo otras funcionalidad importantes como la gestión de políticas de contraseñas,
expiración de cuentas y administradores de grupos.
El archivo /etc/shadow
Archivo de texto plano que contiene información sobre las contraseñas encriptadas de usuarios, atributos de las políticas de expiración
de cuentas y de contraseñas. Este archivo debe tener permisos de lectura sólo por root, ningún permisos para el resto de usuarios.
La sintaxis de este archivo es como sigue:
El archivo /etc/shadow separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
2. Contraseña : Contraseña encriptada (4) del usuario. Si este campo contiene un caracter inválido de contraseña (como ! ó *)
entonces queda deshabilitada la autenticación del usuario.
3. Fecha del último cambio de contraseña : Fecha en formato numérico de días (5) en que el usuario cambió por última vez su
contraseña.
4. Duración mínima de la contraseña : Cantidad de días que un usuario debe esperar para cambiar nuevamente su
contraseña desde la fecha del último cambio realizado.
5. Duración máxima de la contraseña : Cantidad máxima de días que puede durar una contraseña antes que expire.
6. Advertencia de expiración de contraseña : Cantidad de días anticipados en que se avisa a un usuario que su contraseña
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 74
Source Linux
está por expirar.
7. Duración máxima de contraseña expirada : Cantidad de días transcurridos (sin cambio de contraseña) luego de la fecha
de expiración de una contraseña que se considera que el usuario está inactivo y se ha de deshabilitar su cuenta. A este
campo también se le suele conocer como tiempo de inactividad.
(5)
8. Fecha en que la cuenta es deshabilitada : Fecha en formato numérico de días en que la cuenta de usuario será
deshabilitada.
(1) Las contraseñas en un principio fueron encriptadas usando el algoritmo DES, siendo reemplazados poco tiempo despúes por
el algoritmo MD5. Este último no es un algoritmo muy seguro, es vulnerable a un ataque de colisiones al igual que SHA-1,
pero es el que muchas distribuciones Linux aún usan por defecto. Sin embargo algunas distribuciones como openSuSE y
SuSE Linux Enterprise Server ya no usan DES ni MD5 sino Blowfish por defecto, algoritmo del cual aún no se le conocen
vulnerabilidades de colisión.
No obstante cambiar el algoritmo de encriptación de contraseñas desde DES o MD5 hacia Blowfish en otras distribuciones
Linux no es algo nada complicado de lograr.
(2) Este formato numérico de fecha se representa como la cantidad de días transcurridos desde el 1ro. de Enero del año 1970
(inicio del tiempo UNIX) hasta la fecha actual. Este valor se puede obtener así:
El formato +%s del comando date muestra la cantidad de segundos transcurridos desde el 1ro. de Enero de 1970, y para
hacer el cálculo en días lo dividimos entre 86400 (cantidad de segundos que tiene un día).
Una forma alterna de mostrar el mismo valor es a través del uso de Perl:
El archivo /etc/gshadow
Archivo de texto plano que contiene información sobre las contraseñas encriptadas de usuarios, atributos de las políticas de expiración
de cuentas y de contraseñas. Este archivo debe tener permisos de lectura sólo por root, ningún permisos para el resto de usuarios.
La sintaxis de este archivo es como sigue:
El archivo /etc/gshadow separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
2. Contraseña : Contraseña encriptada del grupo. Si este campo contiene un caracter inválido de contraseña (como ! ó *)
entonces queda deshabilitada la autenticación de usuarios a este grupo.
3. Lista de administradores : Lista de usuarios separada por coma que son administradores del grupo.
4. Lista de usuarios : Lista de usuarios separada por coma que son miembros del grupo.
El proceso de migración reversa también es posible (aunque no recomendado más allá de propósitos de prueba), es decir convertir los
archivos de usuarios y grupos del sistema shadow al sistema tradicional usando los comandos pwunconv y grpunconv
respectivamente.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 75
Source Linux
Herramientas de gestión de contraseñas
Ahora que ya conocemos la sintaxis de los archivos de usuarios y grupos en el sistema es tiempo de aprender a manipularlas desde al
línea de comandos.
El comando passwd es el encargado de asignar y modificar el password de los usuarios. Su sintaxis de uso se muestra a continuación:
Opciones:
-l : Deshabilita una cuenta. Lo hace colocando !! al inicio del campo de la contraseña en /etc/passwd o /etc/shadow
-u : Habilita una cuenta deshabilitada.
-e : Expira una contraseña de usuario inmediatamente. Usado para forzar el cambio de password de un usuario en su próximo
inicio de sesión. (No disponible en Red Hat).
-d : Elimina la contraseña de un usuario.
-x MAX : Define a través de MAX la duración máxima de una contraseña.
-x MIN : Define a través de MIN la duración mínima de una contraseña.
-w NUM : Define a través de NUM la cantidad de días de anticipados que se advierte a un usuario de su clave próxima a expirar.
-i NUM : Define a través de NUM la cantidad de días de días de inactividad permitidos desde la expiración de una contraseña antes
que se deshabilite una cuenta.
-S : Muestra el estado de la contraseña del usuario.
Este comando puede ser usado por usuarios sin privilegios (distintos de root) sólo para cambiar su password personal -invocando a
passwd sin argumentos- y conocer el estado de su contraseña usando el argumento -S (en Red Hat sólo root puede hacerlo).
En cambio el usuario root tiene la posibilidad de utilizar todos los argumentos existentes de esta herramienta, pudiendo modificar su
propio password, así como el de otros usuarios y las políticas de expiración de éstos.
admin PS 2009-11-13 10 30 7 5
Donde los campos de izquierda a derecha son: nombre de usuario, estado de la cuenta (PS o P cuenta habilitada con password, NP
cuenta habilitada sin password, LK o L cuenta deshabilitada), fecha del último cambio de clave, duración mínima de la contraseña,
duración máxima de la contraseña, días de advertencia previos a la expiración de contraseña y los días de inactividad luego de la
expiración para deshabilitar la cuenta.
El comando chage es otra herramienta especializada sólo en la gestión de políticas de expiración de contraseñas y cuentas. Coincide
en algunos usos que el comando passwd pero incluye otras funcionalidades adicionales como se muestra a continuación:
Opciones:
-d FECH : Define a través de FECH (en formato YYYY-MM-DD) la fecha del último cambio de contraseña del usuario.
-E FECH : Define a través de FECH (en formato YYYY-MM-DD) la fecha de expiración de la cuenta del usuario.
-M MAX : Define a través de MAX la duración máxima de una contraseña.
-m MIN : Define a través de MIN la duración mínima de una contraseña.
-W NUM : Define a través de NUM la cantidad de días de anticipados que se advierte a un usuario de su clave próxima a expirar.
-I NUM : (i mayúscula) Define a través de NUM la cantidad de días de días de inactividad permitidos desde la expiración de una
contraseña antes que se deshabilite una cuenta.
-l : Muestra el estado de la contraseña y cuenta del usuario.
El comando gpasswd es una herramienta encargada de gestionar los miembros, administradores y contraseñas de los grupos. Su
sintaxis de uso de muestra debajo:
Opciones:
-A USER : Agrega el usuario USER como administrador (mas no miembro) del grupo. Sólo root puede usar esta opción.
-a USER : Agrega el usuario USER como miembro del grupo. Sólo root o un administrador del grupo pueden usar esta opción.
-d USER : Elimina el usuario USER como miembro del grupo.
-r : Remueve la contraseña del grupo. Nadie puede acceder a él usando el comando newgrp excepto los miembros.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 76
Source Linux
El comando newgrp permite ingresar con un nuevo grupo tomando las credenciales de éste:
newgrp [grupo]
Ingresa con un nuevo grupo
Este comando cambia la identificación del grupo primario de quien lo invoca durante la duración de su sesión. Si el usuario ya es
miembro del grupo entonces el ingreso es inmediato, pero si no es miembro entonces el grupo puede solicitar una contraseña para
autorizar el ingreso.
id [opciones] [usuario]
Muestra la identidad de usuarios
Ejemplo 20:
# passwd admin
# passwd -l admin
c) Al usuario admin definirle en 30 la duración máxima de la clave, en 3 la duración mínima, 7 los días de inactividad tolerados tras su
expiración de contraseña y 5 los días de advertencia previos a su expiración de contraseña. Consultar luego el estado de la cuenta:
# passwd -x 30 -n 3 -i 7 -w 5 admin
# passwd -S admin
# chage -M 30 -m 3 -I 7 -W 5 admin
# chage -l admin
# passwd -u admin
# passwd -S admin
e) Establecer la fecha del último cambio de clave del usuario admin en un valor que represente 25 días previos a la fecha actual.
Probar luego el inicio de sesión con el usuario admin desde una consola virtual y evaluar los resultados.
g) Realizando la siguiente operación como el usuario admin, asignar una contraseña al grupo usuarios y agregar dos miembros:
$ gpasswd usuarios
$ gpasswd -a eflores usuarios
$ gpasswd -a mruiz usuarios
h) Realizando la siguiente operación como el usuario eramirez, intentar ingresar al grupo usuarios:
$ newgrp usuarios
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 77
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 78
Source Linux
4.3. Gestión de usuarios y grupos
Dado que ya hemos avanzado con una buena base de los conceptos de usuarios, grupos, sus atributos y políticas de contraseñas, de
ahora en adelante podemos concentrarnos sólo en las herramientas necesarias.
Administración de usuarios
La herramienta useradd nos permite crear usuarios, y su sintaxis de uso es la siguiente:
Opciones:
-c ARG : A través del valor de ARG define el atributos GECOS del usuario (comúnmente sus nombres).
-d DIR : A través del valor de DIR define la ruta del directorio personal del usuario.
-m : Usado en conjunto con -d permite crear el directorio personal del usuario si aun no existiese.
-s SH : A través del valor de SH define la ruta del intérprete de órdenes o Shell asignado al usuario.
-g GRP : A través del valor de GRP define el grupo primario del usuario.
-G GRP : A través del valor de GRP define los grupos secundarios del usuario, cada uno separado por comas.
-u UID : A través del valor de UID define el identificador numérico (UID) del usuario. No debe repetirse este valor.
-k SKEL : A través del valor de SKEL define la ruta del directorio esqueleto (skel) desde el cual se copiará la estructura para crear el
directorio personal del usuario.
-D : Muestra los valores por defecto del comando useradd
Opciones:
-c ARG : A través del valor de ARG define el atributos GECOS del usuario (comúnmente sus nombres).
-d DIR : A través del valor de DIR define la ruta del directorio personal del usuario.
-s SH : A través del valor de SH define la ruta del intérprete de órdenes o Shell asignado al usuario.
-g GRP : A través del valor de GRP define el grupo primario del usuario.
-G GRP : A través del valor de GRP define los grupos secundarios del usuario, cada uno separado por comas.
-u UID : A través del valor de UID define el identificador numérico (UID) del usuario. No debe repetirse este valor.
-l LOGIN : A través del valor de LOGIN define el nuevo nombre del usuario.
-L : Deshabilita una cuenta de usuario.
-U : Habilita una cuenta de usuario.
Opciones:
-f : Fuerza la eliminación del usuario aún si éste se encuentra logueado al sistema, o si su directorio personal o buzón de
correo tiene un propietario distinto.
-r : Permite eliminar el directorio personal del usuario.
Por defecto esta herramienta no permite eliminar un usuario actualmente logueado al sistema. Es necesario matar primero todos sus
procesos antes de intentar eliminarlo a menos que se use la opción -f
Administración de grupos
La herramienta groupadd nos permite crear grupos, y su sintaxis de uso es la siguiente:
Opciones:
-g GID : A través del valor de GID define el identificador numérico (GID) del grupo. No debe repetirse este valor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 79
Source Linux
La herramienta groupmod nos permite modificar grupos, y su sintaxis de uso es la siguiente:
Opciones:
-g GID : A través del valor de GID define el identificador numérico (GID) del grupo. No debe repetirse este valor.
-n GRP : A través del valor de GRP define el nuevo nombre del grupo.
groupdel <grupo>
Elimina grupos
No se puede eliminar un grupo que representa el grupo primario de algún usuario. Es necesario que primero se elimine el usuario o a
éste se le asigne otro grupo primario.
Las cuotas por inodos limitan la cantidad de ficheros (archivos y directorios) que un usuario puede crear. Las cuotas por bloques limitan
la cantidad de espacio en disco que un usuario puede utilizar, contabilizado en número de bloques cada uno de 1 KB de capacidad.
En el ámbito de las cuotas existen 3 conceptos importantes por conocer: límite blando, límite duro y tiempo de gracia. El usuario al
cual se le han definido cuotas por inodos o bloques, mantiene un límite blando que es numéricamente menor que el límite duro.
Cuando el usuario alcanza el límite blando (ocupa tantos inodos o bloques igual o mayores que el límite) el sistema le ha de
generar una advertencia, y es a partir de este momento que se inicia el conteo del tiempo de gracia, que significa el plazo que tiene
para reducir sus inodos o bloques usados hasta caer por debajo del límite blando.
Durante el tiempo de gracia el usuario aún podrá aumentar su consumo de inodos o bloques, siempre y cuando no supere el límite
duro (numéricamente mayor).
Si se cumple el tiempo de gracia y el usuario sigue por encima del límite blando entonces este límite se convierte en duro, esto
quiere decir que el usuario no puede incrementar su consumo de inodos o bloques, por más que permanezca por debajo del límite
duro original.
El límite duro no es permisivo, sino siempre más radical en su accionar, pues incluso cuando el usuario no ha cumplido el tiempo
de gracia éste no podrá jamás consumir más inodos o bloques de los que el límite duro le permite.
Finalmente una vez alcanzado el límite duro, el usuario tiene la posibilidad de reducir su consumo de inodos o bloques hasta
decaer por debajo del límite blando momento en el cual se elimina el tiempo de gracia.
Cabe resaltar que las cuotas por inodos o bloques no son aplicables a root, es decir no le afectan, este usuario siempre podrá
consumir por encima de cualquier límite que se le configure.
Configuración de cuotas
Los pasos a seguir para configurar nuestro sistema con soporte de cuotas de usuario y grupo se resumen a continuación:
Paso 1:
Sobre el sistema de archivos en el cual deseamos activar el soporte de cuotas, configurar su respectiva entrada en /etc/fstab como
sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 80
Source Linux
Paso 2:
La herramienta quotacheck nos permite crear los archivos de cuotas (aquota.user y aquota.group) en la raíz del sistema de archivos.
Asimismo es recomendable ejecutar esta herramienta periódicamente para verificar la consistencia de los archivos de cuota y corregir
en ellos cualquier error encontrado.
La forma en que debemos invocar quotacheck para este propósito es como sigue:
# quotacheck -avug
Tras ejecutar este comando debemos verificar en la raíz del sistema de archivos que se haya creado los archivos aquota.user y
aquota.group. Es necesario mantener las cuotas apagadas en un sistema de archivos antes de ejecutar quotacheck sobre él.
El uso de esta herramienta se puede revisar a detalle en quotacheck(8)
Paso 3:
El procedimiento para encender las cuotas se hace a través de la herramienta quotaon cuya forma de uso para nuestro requerimiento
debe ser:
# quotaon /dev/hdb2
Para apagar las cuotas usamos la herramienta quotaoff. Ambas herramientas tienen una sintaxis de uso como la siguiente:
Opciones:
-a : Encender/apagar las cuotas en todos los sistemas de archivos con la opción auto, usrquota y/o grpquota definidos en
/etc/fstab
-u : Permite encender/apagar cuotas de usuario (por defecto).
-g : Permite encender/apagar cuotas de grupo.
-p : En vez de encender o apagar las cuotas, muestra información de su estado (si están en ON u OFF)
Paso 4:
La edición de cuotas de usuario, grupo y los tiempos de gracia es posible a través del uso de la herramienta edquota, cuya sintaxis de
uso se muestra debajo:
Opciones:
Por tanto para editar las cuotas del usuario admin invocaremos el siguiente comando:
# edquota -u admin
El contenido del archivo que se nos abrirá en el editor de textos predeterminado tiene la siguiente forma:
Sistema de Bloques Límite blando de Límite duro de Límite blando de Límite duro de
Inodos utilizados
archivos utilizados bloques bloques inodos inodos
1. Cada uno de los campos está separado por espacios en blanco o tabulaciones.
2. Las columnas 1 (sistema de archivos), 2 (bloques utilizados) y 5 (inodos utilizados) son sólo informativas, no pueden
modificarse.
Luego que nosotros hagamos los cambios necesarios a las columnas de nuestro interés (límites blandos o duros de inodos y/o
bloques, no necesitamos modificar todos) guardamos los cambios en el editor y salimos de éste, momento en el cual ya se reflejarán
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 81
Source Linux
en el sistema los cambios hechos con edquota -u.
# edquota -t
El contenido del archivo que se nos abrirá en el editor de textos predeterminado tiene la siguiente forma:
Sistema de archivos Tiempo de gracia para bloques Tiempo de gracia para inodos
1. Cada uno de los campos está separado por espacios en blanco o tabulaciones.
2. La columna 1 (sistema de archivos) es sólo informativa, no puede modificarse.
Luego que nosotros hagamos los cambios necesarios a las columnas de nuestro interés (tiempo de gracia de bloques y/o inodos, no
necesitamos modificar todos) guardamos los cambios en el editor y salimos de éste, momento en el cual ya se reflejarán en el sistema
los cambios hechos con edquota -t.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 82
Source Linux
4.4. Laboratorio N° 4
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Crear el directorio /tmp/test y copiar dentro el contenido del directorio /boot. Luego crear el usuario alumno que no sea capaz
de iniciar sesión en línea de comandos pero sí vía FTP, además que use el directorio /tmp/test como esqueleto de su
directorio personal.
2. Habilitar el acceso vía Shell al usuario alumno y configurar su cuenta para que cambie su contraseña en el próximo inicio de
sesión.
3. Crear el grupo sistemas, los usuarios docente, invitado y turista. Asignar al usuario alumno como administrador del grupo
sistemas. Luego ejecutando una sesión del usuario alumno incluir a docente e invitado como miembros y además configurar
el acceso de usuarios externos a este grupo a través de una contraseña.
Intentar unir el usuario turista al grupo sistemas tras comprobar la configuración anterior solicitada.
4. Sin cerrar manualmente la sesión abierta del usuario alumno, eliminar a este último usuario y su directorio personal.
5. Asumiendo que el directorio personal del usuario docente es /home/docente y /home está montado como una partición /dev/sda3
separada de la raíz (/dev/sda2), configurarle su cuota de con límites duros de 100 elementos y 10 MB de espacio en disco, y
con límites blandos que sean el 90% de los límites duros.
Iniciar sesión con el usuario docente y someter a prueba los límites de cuota creando archivos de 1 MB, 3 MB, 5 MB y así
sucesivamente archivos mayores hasta alcanzar los límites duros y blandos.
6. Configurar el sistema para que la cuenta del usuario docente expire el 31 de Diciembre del 2009 a través de la edición
manual directa del archivo /etc/shadow. No utilizar los comandos passwd ni chage para lograr este objetivo.
7. Deshabilitar la cuenta del usuario docente a través de la edición manual directa del archivo /etc/shadow. No utilizar los
comandos passwd ni chage para lograr este objetivo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 83
Source Linux
4.4.1. Solución del laboratorio N° 4
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Crear el directorio /tmp/test y copiar dentro el contenido del directorio /boot. Luego crear el usuario alumno que no sea capaz
de iniciar sesión en línea de comandos pero sí vía FTP, además que use el directorio /tmp/test como esqueleto de su
directorio personal.
# mkdir /tmp/test
# cp -r /boot/* /tmp/test
2. Habilitar el acceso vía Shell al usuario alumno y configurar su cuenta para que cambie su contraseña en el próximo inicio de
sesión.
# passwd -e alumno
+ En Red Hat se podría expirar la contraseña asignando un periodo de duración máxima de la contraseña que sea menor a
la cantidad de días transcurridos desde el último cambio de contraseña del usuario que nosotros le alteremos.
El siguiente comando asume que nuestra fecha actual es 15 de Noviembre del 2009:
3. Crear el grupo sistemas, los usuarios docente, invitado y turista. Asignar al usuario alumno como administrador del grupo
sistemas. Luego ejecutando una sesión del usuario alumno incluir a docente e invitado como miembros y además configurar
el acceso de usuarios externos a este grupo a través de una contraseña.
Intentar unir el usuario turista al grupo sistemas tras comprobar la configuración anterior solicitada.
# groupadd sistemas
# useradd -m docente
# useradd -m invitado
# useradd -m turista
# su – alumno
$ gpasswd -a docente sistemas
$ gpasswd -a invitado sistemas
$ gpasswd sistemas
$ exit
# su – turista
$ newgrp sistemas
4. Sin cerrar manualmente la sesión abierta del usuario alumno, eliminar a este último usuario y su directorio personal.
+ Para eliminar el usuario alumno éste debe primero cerrar su sesión o debemos forzar su salida matando sus procesos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 84
Source Linux
Según el requerimiento sólo nos queda optar por lo segundo:
# killall -9 -u alumno
# userdel -r alumno
5. Asumiendo que el directorio personal del usuario docente es /home/docente y /home está montado como una partición /dev/sda3
separada de la raíz (/dev/sda2), configurarle su cuota de con límites duros de 100 elementos y 10 MB de espacio en disco, y
con límites blandos que sean el 90% de los límites duros.
Iniciar sesión con el usuario docente y someter a prueba los límites de cuota creando archivos de 1 MB, 3 MB, 5 MB y así
sucesivamente archivos mayores hasta alcanzar los límites duros y blandos.
+ Ahora creamos archivos de 1 MB, 3 MB y cada vez mayores hasta alcanzar los límites definidos:
# su – docente
$ pwd
/home/docente
$ dd if=/dev/zero of=archivo.00 bs=1M count=1
$ dd if=/dev/zero of=archivo.00 bs=1M count=3
$ dd if=/dev/zero of=archivo.00 bs=1M count=5
$ dd if=/dev/zero of=archivo.00 bs=1M count=8
$ dd if=/dev/zero of=archivo.00 bs=1M count=9
$ dd if=/dev/zero of=archivo.00 bs=1M count=12
6. Configurar el sistema para que la cuenta del usuario docente expire el 31 de Diciembre del 2009 a través de la edición
manual directa del archivo /etc/shadow. No utilizar los comandos passwd ni chage para lograr este objetivo.
+ Dado que los campos de fecha en /etc/shadow está expresado en días desde el 1ro. de Enero de 1970, debemos hacer el
cálculo de días transcurridos desde esa fecha hasta el 31 de Diciembre del 2009 con un formato manual del comando date:
+ Al ver la salida del comando anterior tenemos ya el valor para colocarlo en el campo número 8 (penúltimo) del archivo
/etc/shadow:
7. Deshabilitar la cuenta del usuario docente a través de la edición manual directa del archivo /etc/shadow. No utilizar los
comandos passwd ni chage para lograr este objetivo.
+ Este procedimiento es tan sencillo como editar el segundo campo del archivo /etc/shadow y colocar al inicio del mismo dos
veces el signo de exclamación (!!).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 85
Source Linux
Unidad 5: Seguridad local
5.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
Como se debe recordar, en una computadora con el sistema operativo MSDOS o Windows 9x (95, 98 y Me), cualquier persona que
acceda a ella puede en cualquier momento borrar todo el disco duro.
• Cada usuario puede pertenecer a varios grupos, pero sólo uno de ellos representa su grupo primario.
• Cuando un usuario crea un proceso, archivo o directorio se le transmiten a ellos la propiedad del usuario y grupo (primario)
propietario. Así el usuario admin cuyo grupo primario es users, al crear un archivo prueba.txt éste tendrá al usuario admin y
grupo users como propietario.
• La propiedad de usuario y grupo propietario que se aplica sobre procesos, archivos o directorios se da en base al UID y GID
y no en base al nombre del usuario. Un usuario puede ser renombrado sin afectar la propiedad de sus archivos, pero si se le
asigna un nuevo UID será necesario reflejar ese nuevo propietario sobre sus archivos.
• El usuario root pasa por encima de cualquier interpretación de permisos o propietarios. Es decir puede modificar archivos con
permisos de sólo lectura, puede leer y alterar archivos que no son de su propiedad, puede cambiar el propietario de archivos
y directorios que no son suyos, puede eliminar archivos, directorios y procesos ajenos, etc.
• En un sistema UNIX existen tres formas básicas de tratar un archivo: leerlo (read, r), escribirlo (write, w) o ejecutarlo
(execute, x). Estos representan la base de los permisos UNIX tradicionales que estamos próximos a estudiar.
• En un sistema UNIX la interpretación de la propiedad de los archivos y directorios se resume en tres clases: usuario (user),
grupo (group) y otros (others). Para cada una de estas clases de definen permisos de archivos. Así por ejemplo los permisos
de usuario pueden ser de lectura y escritura, los permisos de grupo de sólo lectura y los permisos de otros ser nulos (no
tienen ningún permiso).
• La representación de los permisos se hace generalmente a través de caracteres (r, w, x, s, t) y su equivalente numérico octal,
como se resume en la siguiente tabla:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 86
Source Linux
• Los permisos básicos (r, w y x) se definen siempre como una terna en el orden rwx, no se admite nunca una expresión de
permisos tal como wrx, rrw, xrw o cualquier forma distinta. Su representación octal se hace a través de la suma de los
valores numéricos de cada uno de los permisos. Ejm: rwx = 7, r-- = 4, rw- = 6
• La cadena rwx expresa la presencia de los 3 permisos, pero se puede expresar la ausencia de uno o más de ellos
reemplazando su respectiva letra por el caracter -
• Dado que la propiedad de los archivos se expresa a través de tres clases de usuario (user, group y others) entonces la
expresión completa de los permisos de un archivo se hace a través de tres ternas rwx, como sigue:
• La expresión completa de los permisos en forma octal se realiza a través de la suma de los valores numéricos de cada uno
de los permisos por clase de usuario. Ejm: rwxrwxrwx = 777, rw-r--r-- = 644, rw-r----- = 640
• Los permisos especiales (SUID = s, SGID = s, y Sticky Bit = t) no se suelen expresar como una cuarta terna visible, sino
como una casi oculta. Se le llama así pues la ubicación de los caracteres que representan estos permisos se da en las
mismas posiciones que las clases de usuarios user, group y others como se muestra en la tabla de abajo:
Permisos
SUID SGID Sticky Bit
especiales
Permisos
Usuario (user) Grupo (group) Otros (others)
básicos
rwx rwx rwx
s s t
Esta tabla no quiere decir que los permisos se muestran en 2 niveles o 2 líneas, sino que se pretende explicar que el permiso
SUID (caracter 's') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase user, el permiso
SGID (caracter 's') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase group y el permiso
Sticky Bit (caracter 't') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase others.
• En ausencia de cualquiera de los permisos especiales su ubicación en las tres ternas no se hace notar. Pero cuando uno de
ellos está presente se reemplaza el caracter 'x' (si es que el permiso de ejecución está presente) por el caracter 's' para SUID
y SGID, o por el caracter 't' para Sticky Bit.
Si en lugar del caracter 'x' existía un guión '-' (si es que el permiso de ejecución estaba ausente) entonces éste se reemplaza
por un caracter 'S' (mayúscula) para SUID y SGID o por un caracter 'T' (mayúscula) para Sticky Bit.
• La notación octal de los permisos normalmente se da a través de 3 números (Ejm: 644) como se explicó líneas arriba cuando
no existe ninguno de los permisos especiales activos. Sin embargo en presencia de alguno de estos permisos especiales la
expresión octal cambia ahora para estar formado por 4 números donde el primero de la izquierda representa la suma de los
permisos SUID, SGID y Sticky Bit. (Ejm: 4750, 6644, 0640).
Cierto es que la interpretación de los caracteres que representan los permisos puede resultar algo confusa o complicada en un inicio,
pero tras una lectura repetida, detallada de este apartado y el análisis de las siguientes imágenes debería quedar más claro la
comprensión de los permisos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 87
Source Linux
Fig. 5.1: Expresión binaria de los permisos básicos y especiales
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 88
Source Linux
Se puede ejecutar el archivo con los privilegios de su
SUID No tiene ningún efecto
usuario propietario.
Se puede ejecutar el archivo con los privilegios de su grupo Obliga que los archivos y/o directorios creados dentro
SGID
propietario. hereden el grupo propietario del directorio con SGID.
Previene que usuarios con permiso de escritura en un
Mantiene los archivos executables en memoria, no los directorio borren o eliminen archivos y/o directorios que no
Sticky Bit
manda a memoria de intercambio si están inactivos. les pertenecen. El propietario del directorio sí podrá borrar
y eliminar archivos y/o directorios ajenos.
Donde:
1. La 1ra. columna define el tipo de archivo y los permisos UNIX. El 1er. caracter de esta columna representa el tipo de archivo
cuyos posibles valores son:
d Directorio
b Dispositivo de bloques
c Dispositivo de caracteres
l Enlace simbólico
p Archivo FIFO
s Socket
- Archivo ordinario
Los caracteres desde la 2da. posición hasta la 10ma. (9 en total) representan las ternas de permisos para usuario, grupo y
otros.
6. La 6ta., 7ma. y 8va. columna indican la fecha y hora de la última modificación del archivo o directorio.
Ejemplo 21:
• rwxrw-r-- = 0764
• rwsr-xr-x = 4755
• rwsr-S--x = 6741
• r-xr-srwt = 3557
• rwxrwxrwt = 1777
• rwsrwSr-T = 7764
Interpretación de permisos asumiendo que el usuario y grupo propietario es admin y users respectivamente:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 89
Source Linux
• El usuario admin puede ingresar al directorio, listar su
contenido y crear, eliminar y renombrar lo que hay
dentro.
• El usuario admin puede leer, modificar y ejecutar el
archivo. • El grupo users puede listar los archivos que hay dentro
rwxrw-r-- mas no ver consultar sus atributos. Como carece de
• El grupo users puede leer, modificar mas no ejecutar el
ejecución tampoco puede aprovechar en absoluto el
archivo.
permiso de escritura para crear, eliminar y/o renombrar
• El resto de usuarios (otros) sólo pueden leer el archivo. elementos dentro.
• El resto de usuarios (otros) sólo pueden leer listar los
archivos que hay dentro mas no ver sus atributos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 90
Source Linux
• El resto de usuarios (otros) puede listar el contenido del
directorio, pero no ver los atributos de lo que hay
dentro ni ingresar al directorio.
• Este archivo se mantendría más tiempo en memoria • El permiso SUID es ignorado.
física durante su ejecución. • Los usuarios con permiso de escritura (usuario y grupo)
pueden crear archivos o directorios dentro, pero sólo
renombrar y eliminar sus propios archivos mas no
ajenos.
La herramienta chmod permite asignar permisos a archivos y/o directorios de la siguiente forma:
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus permisos.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus permisos.
-v : Informa de cada acción efectuada o no sobre los ficheros.
-R : Cambia de forma recursiva los permisos de directorios y sus contenidos.
La interpretación de los permisos que se asignarán a los ficheros se hace a través de modo que tiene una notación simbólica y una
notación octal.
La notación octal se hace a través de la expresión de un número que tenga entre 1 y 4 dígitos (entre 0 y 7). Los dígitos que falten
para completar el grupo de cuatro se han de completar con ceros iniciales (desde la izquierda).
[ugoa][+-=][rwxst]
Donde el primer grupo de caracteres hace referencia a la clase de usuario (u = user, g = group, o = other, a = all), el segundo grupo la
operación de modificación de permisos (+ agrega permisos, - remueve permisos, = asigna permisos igual a ...) y el último grupo
representa los permisos a aplicar (r = lectura, w = escritura, x = ejecución, s = SUID/SGID, t = Sticky Bit).
Se pueden representar varios modos en notación simbólica cada uno separado por comas.
La herramienta umask permite definir los permisos que tendrán los archivos y/o directorios automáticamente al crearse. Esto se hace
definiendo un valor de máscara que resta de los permisos por defecto para archivos (0666) o directorios (0777) para así obtener los
permisos resultantes para ficheros a punto de crearse.
Opciones:
Si se omite máscara entonces sólo muestra la actual, no la cambia. Debe tenerse en cuenta que las máscaras cualquiera sea la
combinación creada nunca permite crear archivos con permisos de ejecución, ni archivos y/o directorios con permisos especiales
(SUID, SGID o Sticky Bit).
Las herramientas chown y chgrp permiten cambiar el usuario y/o grupo propietario de archivos como abajo se muestra:
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus propietarios.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus propietarios.
-v : Informa de cada acción efectuada o no sobre los ficheros.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 91
Source Linux
-R : Cambia de forma recursiva los propietarios de directorios y sus contenidos.
Como se muestra en la sintaxis esta herramienta permite cambiar el usuario y también el grupo propietario de ficheros usando el
símbolo : como separados entre usuario y grupo.
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus propietarios.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus propietarios.
-v : Informa de cada acción efectuada o no sobre los ficheros.
-R : Cambia de forma recursiva los propietarios de directorios y sus contenidos.
Como se muestra en la sintaxis esta herramienta sólo permite cambiar el grupo propietario de ficheros.
Ejemplo 22:
a) Dado el archivo file.txt con permisos 0664, agregarle permisos de ejecución al usuario y al grupo, quitarle escritura al grupo y
remover todo permiso de otros usuarios.
Se puede hacer de la siguientes formas equivalentes:
b) Quitar todo permiso a todos los archivos del directorio /home a todos los usuarios que no tengan ningún vínculo de propiedad sobre
los ficheros.
# chmod -R o= /home
c) Establecer la máscara de creación de ficheros para nuestro usuario actual de modo que sólo nosotros podamos leerlos y/o
modificarlos (en caso de archivos) o ingresar a ellos (en caso de directorios); ni el grupo ni otros tendrán permiso alguno sobre estos
ficheros próximos a crearse.
Se puede hacer de la siguientes formas equivalentes:
$ umask u=rwx,g=,o=
$ umask 0077
$ umask -S
$ umask
e) Cambiamos la propiedad del directorio /home/administrador (y todo su contenido) al usuario admin y grupo usuarios:
f) Dado que el archivo /etc/shadow puede ser leído sólo por root, intentaremos explicar el uso del SUID con un caso práctico. Primero
consultamos los permisos y propiedad del archivo /bin/cat, luego utilizando esta herramienta procuraremos ver el archivo /etc/shadow:
$ ls -l /bin/cat
-rwxr-xr-x 1 root root 32136 abr 4 2008 /bin/cat
$ cat /etc/shadow
cat: /etc/shadow: Permiso denegado
Ahora como sabemos que el propietario del comando cat es root, podemos aprovechar esto para darle SUID a este binario y permitir
que cualquier usuario que ejecute el comando cat lo haga con privilegios de root para así tener acceso de lectura al archivo
/etc/shadow:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 92
Source Linux
$ cat /etc/shadow
Ahora que comprobamos que resultó el uso del SUID en el binario cat, por seguridad eliminamos este permiso especial:
Es por ello que aparecen las Listas de Control de Acceso (Access Control List en inglés) conocidas comúnmente sólo como ACL, las
que permiten lograr este nivel de permisos granulares en archivos y/o directorios.
Para hacer uso de la funcionalidad de ACL en nuestro sistema requerimos que el kernel lo soporte (viene por defecto activado en toda
distribución Linux moderna), y además el sistema de archivos (sobre el cual queremos hacer uso de las ACL) lo soporte desde el
momento de su montaje (opción acl del comando mount o en el archivo /etc/fstab).
Asumiendo que ambos requisitos ya son cumplidos en el sistema usaremos las herramientas getfacl y setfacl para consultar y
modificar las ACL de ficheros.
Consultas de ACL
A través de un listado detallado (ls -l) podemos saber qué ficheros tienen atributos de ACL al encontrar el símbolo + junto a los
permisos de la primera columna. Nótese el siguiente listado:
$ ls -l
drwx------ 2 angel angel 4096 nov 17 09:20 amsn_received
drwxr-xr-x+ 2 angel angel 4096 oct 17 21:48 compartido
drwxr-x---+ 8 angel angel 12288 nov 18 10:26 Descargas
drwxr----- 2 angel angel 4096 oct 11 15:01 Desktop
drwxr-x---+ 9 angel angel 4096 nov 6 22:05 Documents
lrwxrwxrwx 1 angel angel 22 jul 26 12:50 Imagenes -> /data/varios/Imagenes/
drwxr-x--- 7 angel angel 4096 jul 22 01:54 LimeWire
Podemos apreciar que los directorios compartido, Descargas y Documents poseen ciertos atributos de ACL debido al signo + que figura
junto a sus permisos.
Una vez que deseamos consultar las entradas ACL de los ficheros usaremos la herramienta getfacl cuya sintaxis de uso se muestra
debajo:
Opciones:
1: # file: file.txt
2: # owner: admin
3: # group: usuarios
4: user::rwx
5: user:mruiz:rwx #effective:r-x
6: group::rwx #effective:r-x
7: group:alumnos:r-x
8: mask:r-x
9: other:r-x
10: default:user::rwx
11: default:user:mruiz:rwx #effective:r-x
12: default:group::r-x
13: default:mask:r-x
14: default:other:---
Las líneas 1, 2 y 3 corresponden a la cabecera de información que contiene el nombre del archivo, el usuario propietario y grupo
propietario.
Las líneas 4, 6 y 9 corresponden a los permisos de las clases usuario, grupo y otros.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 93
Source Linux
Las líneas 5 y 7 representan los permisos para los usuarios (mruiz) y grupos (alumnos) nombrados
La línea 8 representa la máscara de permisos efectivos que puede tener cualquier usuario nombrado o grupo. El usuario propietario y
otros usuarios no son afectados por esta máscara.
Las líneas de la 10 a la 14 representan las entradas ACL por defecto de este directorio. Los directorios pueden tener ACL por defecto,
pero no los archivos.
Modificaciones de ACL
Cuando se desea modificar las entradas ACL de los ficheros usaremos la herramienta setfacl cuya sintaxis de uso se muestra
debajo:
Opciones:
-b : Remueve todas las entradas ACL de ficheros, preservando los permisos básicos de usuario, grupo y otros.
-k : Remueve las entradas de ACL por defecto de directorios.
-d : Asigna entradas de ACL por defecto a directorios.
-R : Asigna de forma recursiva las ACL de archivos, directorios y sus contenidos
-m ACLS : Define la(s) entrada(s) ACL a asignar a los ficheros
-x ACLS : Define la(s) entrada(s) ACL a remover de los ficheros. El campo perms no debe estar presente en ACLS.
[d:][ug:][usuario/grupo][:perms]
Donde d, default hace referencia a una ACL por defecto para directorios, u, user o g, group indica si se trata de un usuario o grupo la
entrada ACL, y finalmente el campo perms define en notación simbólica los permisos que se asignarán.
Ejemplo 23:
a) Administrar los permisos del archivo /tmp/test.txt -de propiedad del usuario y grupo root- de modo que el usuario admin tenga
permisos de lectura y escritura, el usuario aperez permisos de lectura, escritura y ejecución y el grupo alumnos tenga permisos de
lectura únicamente.
Comprobar que los permisos realmente se hayan aplicado sobre el archivo.
b) Configurar el sistema de modo tal que cualquier archivo creado dentro de /tmp (y cualquier directorio dentro) tenga permisos de
lectura y escritura por el usuario mruiz:
c) Eliminar cualquier entrada de ACL que exista dentro del directorio /tmp y su contenido:
# setfacl -R -b /tmp
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 94
Source Linux
5.3. Ejecución privilegiada
En los sistemas UNIX es muy común el trabajar con algún usuario sin privilegios y requerir convertirse en otro usuario -por ejemplo
root- u obtener los privilegios de éste ya sea durante una sesión prolongada, breve o incluso sólo necesaria para la ejecución de uno o
más procesos específicos.
Son estas situaciones en las que un usuario puede realizar una ejecución privilegiada a través del uso de las herramientas su y sudo
que según la configuración adecuada de éstas el usuario puede lograr su propósito.
La herramienta su
Esta herramienta, su, permite ejecutar una shell con las credenciales de usuario y grupo distintas. Si se desea utilizar las credenciales
de un usuario que tiene una contraseña asignada entonces ésta será pedida a quien haga uso de su.
La sintaxis de uso de esta herramienta se muestra a continuación:
Opciones:
-c CMD : En lugar de ejecutar una shell interactiva sólo invoca al comando CMD con los privilegios del usuario especificado.
-s SH : Ejecuta la shell SH en lugar de la que tenga asignada a su cuenta el usuario al cual se intenta convertir.
-l, - : Ejecuta la shell de usuario como un inicio de sesión con login. Esto permite ejecutar los shells de inicio de sesión y
variables de entorno del usuario así como también ser ubicado en su directorio personal.
La herramienta sudo
Esta herramienta permite ejecutar un comando con las credenciales de otro usuario. Si el usuario que invoca sudo es root o si el
usuario destino es el mismo que invoca la herramienta entonces no se solicita ningún password.
De lo contrario sudo requiere que los usuarios se autentiquen con un password que por defecto es el de ellos mismos. Una vez que el
usuario se ha autenticado se actualiza una marca de tiempo y el usuario puede seguir invocando sudo sin una contraseña por un corto
periodo de tiempo (que por defecto es 15 minutos a menos que se defina algo distinto en /etc/sudoers)
A través del uso de sudo es posible determinar qué usuarios, en qué hosts, con las credenciales de quién y qué comandos pueden
invocar a través de esta herramienta. Todo esto es posible a través de la configuración del archivo /etc/sudoers.
Se recomienda no editar directamente este archivo sino hacerlo a través de la herramienta visudo la cual es capaz de detectar
sintaxis incorrecta en su contenido para poder corregirla antes de cerrar el editor (el que se defina en la variable de entorno EDITOR).
Tener en cuenta que los cambios al archivo sudoers sólo se hacen efectivos tras cerrar el editor invocado desde visudo.
# Sección de Aliases
User_Alias <NOMBRE_ALIAS> = [!]<USUARIO|%GRUPO>, ...
Host_Alias <NOMBRE_ALIAS> = [!]<HOSTNAME>, ...
Runas_Alias <NOMBRE_ALIAS> = [!]<RUNAS>, ...
Cmnd_Alias <NOMBRE_ALIAS> = [!]<COMANDO>, ...
Donde:
La sintaxis de especificación de usuarios define que... "los usuarios especificados en user pueden ejecutar comandos en los hosts
especificados en hostlist con las credenciales de los usuarios especificados en runaslist los comandos especificados en
commandlist".
Cualquiera de los campos user, hostlist, runaslist y commandlist pueden ser reemplazados por la palabra ALL que será
equivalente a cualquier valor que tengan estos campos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 95
Source Linux
Por lo general no se suele especificar nombres de hosts distintos al de nuestro propio sistema, o la palabra ALL, a menos que
pretendamos usar una configuración distribuida del archivo sudoers en la red para varios hosts.
El uso de la herramienta sudo en la línea de comandos es como sigue:
Opciones:
-l : Permite listar los comandos que están permitidos al usuario en el host actual.
-k : Invalida la marca de tiempo del usuario de modo que la próxima vez que se invoque a sudo se requiera contraseña.
-u USER : Especifica a través de USER cómo que usuario invocar los comandos en lugar de root.
Ejemplo 24:
$ su - -c "fdisk -l"
La primera forma no requiere indicar la ruta completa del comando fdisk debido a que con el parámetro - se asigna el valor de PATH
que le corresponde a root y que incluye al directorio /sbin. En cambio si se omite el parámetro - como se ve abajo, sí se requiere
especificar la ruta absoluta del comando fdisk:
$ su -c "/sbin/fdisk -l"
b) Convertirse en el usuario postfix usando la shell /bin/bash sabiendo que este usuario tiene una shell deshabilitada:
# su - -s /bin/bash postfix
c) Configurar restricciones de ejecución privilegiada de modo tal que los usuarios admin y aperez tengan permisos sólo de ejecutar los
comandos shutdown, reboot, poweroff y halt:
# visudo
Luego de guardar los cambios y salir del editor los usuarios admin y aperez pueden invocar con sus contraseñas estos comandos
como sigue:
d) Permitir al usuario mruiz ejecutar como el usuario postgre los comandos createdb y psql sin ingresar su contraseña:
# visudo
Luego de guardar los cambios y salir del editor el usuario mruiz puede invocar sin contraseña los siguientes comandos:
$ sudo createdb
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 96
Source Linux
$ sudo psql
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 97
Source Linux
5.4. Laboratorio N° 5
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Se tiene un binario /bin/install que tiene por objetivo modificar un archivo /etc/install.conf que tiene permisos de sólo lectura y
escritura por el usuario root. Se desea que sólo los usuarios eflores y nalvarez sean los únicos capaces de alterar dicho
archivo de configuración a través del uso de /bin/install.
Indique los comandos necesarios a ejecutar para lograr cumplir este requerimiento.
2. Se tiene una aplicación Web escrita en PHP que es servida por Apache desde el directorio /var/ww//html/website. Esta
aplicación suele crear archivos y/o directorios dentro de esa ruta, y también otros usuarios tales como eflores, nalvarez y admin
suben información dentro a través de un acceso FTP provisto por el administrador.
Indique los comandos necesarios a ejecutar para que se asegure que todo archivo creado dentro de dicho directorio
pertenezca siempre al grupo apache con permisos de lectura y escritura.
3. Luego de un análisis del administrador hacia el directorio servidor por Apache en el ejemplo anterior, encontró que dentro de
esa ruta existen al menos 200 ficheros entre archivos y directorios que no tenían como grupo propietario a apache y la
aplicación Web está generando errores de permisos al intentar acceder a ellos.
Indique los comandos necesarios para corregir de forma directa los permisos sobre esos ficheros considerando que no debe
alterar los permisos de la clase del usuario ni grupo propietario de los mismos.
4. El webmaster indica que la aplicación Web requiere tener acceso a modificar los parámetros de red del sistema operativo
(asignar direcciones IP a las interfaces con ifconfig y definir la puerta de enlace del sistema con route) para lo cual exige
que el servicio Apache no sea ejecutado como el usuario apache sino como root.
¿Qué solución más segura que la solicitada por el webmaster Ud. le daría?
5. Se tiene una configuración centralizada de sudoers a través de LDAP, la cual se distribuye con este protocolo a todos los
hosts de la red dentro del dominio consultorianet.com. Se requiere limitar el acceso a los comandos postsuper y postfix sólo
en el Gateway antispam (antispam.consultorianet.com) y Servidor de Correo (mail.consultorianet.com) para los usuarios
admin y eflores.
Indique los comandos necesarios para lograr este objetivo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 98
Source Linux
5.4.1. Solución del laboratorio N° 5
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Se tiene un binario /bin/install que tiene por objetivo modificar un archivo /etc/install.conf que tiene permisos de sólo lectura y
escritura por el usuario root. Se desea que sólo los usuarios eflores y nalvarez sean los únicos capaces de alterar dicho
archivo de configuración a través del uso de /bin/install.
Indique los comandos necesarios a ejecutar para lograr cumplir este requerimiento.
+ El binario /bin/install debería tener como propietario al usuario root y poseer el permiso SUID activo:
+ Para limitar la ejecución sólo a eflores y nalvarez se podría incluir a ambos como únicos miembros de un grupo, tal como
install, y sólo a este grupo permitir la ejecución en el binario /bin/install:
# groupadd install
# usermod -g install eflores
# usermod -g install nalvarez
# chgrp install /bin/install
# chmod u=rwx,g=rx,o= /bin/install
+ Otra opción más elegante sería utilizar ACLs para este control granular y quitar el permiso de ejecución a cualquier otro
usuario sobre el binario /bin/install:
2. Se tiene una aplicación Web escrita en PHP que es servida por Apache desde el directorio /var/ww//html/website. Esta
aplicación suele crear archivos y/o directorios dentro de esa ruta, y también otros usuarios tales como eflores, nalvarez y admin
suben información dentro a través de un acceso FTP provisto por el administrador.
Indique los comandos necesarios a ejecutar para que se asegure que todo archivo creado dentro de dicho directorio
pertenezca siempre al grupo apache con permisos de lectura y escritura.
+ El directorio /var/www/html/website (y cualquier directorio existente dentro) debería tener como grupo propietario a apache y
poseer el permiso SGID activo para asegurar que los ficheros creados dentro hereden el grupo solicitado:
+ Para asegurar que los nuevos archivos ahí creados tengan permisos de lectura y escritura para el grupo apache, haremos
uso de entradas ACL por defecto:
3. Luego de un análisis del administrador hacia el directorio servidor por Apache en el ejemplo anterior, encontró que dentro de
esa ruta existen al menos 200 ficheros entre archivos y directorios que no tenían como grupo propietario a apache y la
aplicación Web está generando errores de permisos al intentar acceder a ellos.
Indique los comandos necesarios para corregir de forma directa los permisos sobre esos ficheros considerando que no debe
alterar los permisos de la clase del usuario ni grupo propietario de los mismos.
4. El webmaster indica que la aplicación Web requiere tener acceso a modificar los parámetros de red del sistema operativo
(asignar direcciones IP a las interfaces con ifconfig y definir la puerta de enlace del sistema con route) para lo cual exige
que el servicio Apache no sea ejecutado como el usuario apache sino como root.
¿Qué solución más segura que la solicitada por el webmaster Ud. le daría?
+ Explicar al Webmaster que debe modificar su aplicación Web para que invoque los comandos que necesita con el uso de
sudo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 99
Source Linux
5. Se tiene una configuración centralizada de sudoers a través de LDAP, la cual se distribuye con este protocolo a todos los
hosts de la red dentro del dominio consultorianet.com. Se requiere limitar el acceso a los comandos postsuper y postfix sólo
en el Gateway antispam (antispam.consultorianet.com) y Servidor de Correo (mail.consultorianet.com) para los usuarios
admin y eflores.
Indique los comandos necesarios para lograr este objetivo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 100
Source Linux
Unidad 6: Particionamiento avanzado
6.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
La combinación que hace RAID de varios discos duros se consolida en una unidad lógica, la misma que se muestra al sistema
operativo como un único disco duro cuando trabajamos con un sistema RAID a nivel de hardware, utilizando por lo general de la misma
capacidad.
Esta capacidad de crear arreglos a nivel de hardware requiere que exista un controlador RAID ya sea en la placa madre del sistema o
a través de una tarjeta de expansión conectada a un bus PCI. Es el controlador RAID el que debe ser capaz de entender los niveles de
RAID existentes tales como 0, 1, 5, etc.
De manera alterna al RAID a nivel de hardware existe su equivalente a nivel de software implementado por lo general por un
controlador de bajo nivel del sistema operativo.
El kernel Linux incluye un controlador por software para crear dispositivos RAID conformados ya no por discos duros enteros, sino por
otros dispositivos de bloque tales como particiones de disco, Logical Volumes o incluso otros dispositivos RAID. Este controlador de
Linux soporta los niveles 1, 4, 5, 6 y 10 (1+0).
RAID nivel 0
Este nivel de RAID distribuye los datos entre dos o más dispositivos sin información de paridad que proporcione redundancia. El
objetivo de este nivel de arreglo es tener una unidad lógica de mayor tamaño producto de la agrupación de dispositivos de menor
tamaño. Se caracteriza también por ofrecer un rendimiento superior.
Este nivel de arreglo puede ser creado con dispositivos de distintos tamaños, pero el espacio total añadido a la unidad lógica consiste
de porciones equivalentes al tamaño del menor de todos los dispositivos. Así si se forma un RAID 0 con dispositivos de 300 GB, 400
GB y 500 GB se obtendrá una unidad lógica resultante de 900 GB (300 GB x 3).
RAID nivel 1
Este nivel de RAID crea réplicas exactamente iguales entre cada uno de los dispositivos que conforman el arreglo. El objetivo de este
nivel es principalmente la redundancia y rendimiento a través la lectura concurrente desde dos o más discos.
Este nivel de arreglo puede ser creado con dispositivos de distintos tamaños, pero el espacio total resultante de la unidad lógica será
equivalentes al tamaño del menor de todos los dispositivos. Así si se forma un RAID 1 con dispositivos de 300 GB y 400 GB se
obtendrá una unidad lógica resultante de 300 GB.
RAID nivel 5
Este nivel de RAID usa una división de datos a nivel de bloques con la información de paridad distribuida entre todos los discos. El
objetivo de este nivel es principalmente la redundancia lograda a través de un bajo costo.
Este nivel de arreglo requiere al menos de 3 discos y sólo es capaz de soportar la falla de 1 disco como máximo; la falla de un segundo
disco provocaría la pérdida de datos.
La capacidad total obtenido de un RAID 5 es igual a N-1, donde N es la cantidad total de dispositivos, tomando de ellos sólo la
capacidad correspondiente al menor de todos si se usan dispositivos de distintos tamaños.
RAID nivel 6
Este nivel es similar al RAID 5 pero agrega un segundo bloque de paridad, lo que permite soportar la falla de hasta 2 discos como
máximo; la falla de un tercer disco provocaría la pérdida de datos.
La capacidad total obtenido de un RAID 6 es igual a N-2, donde N es la cantidad total de dispositivos, tomando de ellos sólo la
capacidad correspondiente al menor de todos si se usan dispositivos de distintos tamaños.
RAID nivel 10
Este nivel provee una combinación de RAID 1 y RAID 0. Cada bloque de datos es duplicado y distribuido entre múltiples dispositivos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 101
Source Linux
Esto se logra construyendo arreglos de nivel 1 y sobre las resultantes construir un arreglo de nivel 0. Este tipo de arreglo es
recomendado para el uso intensivo de bases de datos debido a su alto rendimiento tanto en lectura, como escritura, así como también
en los buenos niveles de redundancia que ofrece.
La regla de capacidad del arreglo se rige como las anteriores, de cada dispositivo se usa la capacidad equivalente al menor de todos
los restantes para armar los arreglos de nivel 1 y 0.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 102
Source Linux
Administración de dispositivos RAID en Linux
Vamos a empezar a estudiar el proceso de creación de dispositivos RAID en Linux a través de la línea de comandos. Empezaremos
mencionando que las particiones de disco donde deseamos usar como miembros de un arreglo, deben tener el identificador de
partición fd asignándolo con fdisk como sigue:
# fdisk /dev/sda
Orden (m para obtener ayuda): t
Número de partición (1-4): 1
Código hexadecimal (escriba L para ver los códigos): fd
Se ha cambiado el tipo de sistema de la partición 1 por fd (Linux raid autodetect)
# partprobe
Nótese que hemos elegido trabajar con dos particiones del mismo tamaño (ambos tienen 98280 bloques) y sólo para fines de pruebas
ambas pertenecen al mismo disco. Lo recomendable siempre es poder utilizar particiones en diferentes discos.
Ahora que ya tenemos las particiones listas podemos proceder al estudio de la herramienta mdadm que es la encargada de administrar
los dispositivos RAID, que son de tipo MD en Linux.
Opciones:
Creación de arreglos
La siguiente sintaxis de mdadm es utilizada para crear arreglos:
# mdadm -C <disp. MD> -l <NIVEL> -n <NUM> <disp. miembros> [-x <NUM> <disp. repuesto>]
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 103
Source Linux
Desactivando arreglos
La siguiente sintaxis de mdadm es utilizada para desactivar arreglos:
Activando arreglos
Es necesario averiguar qué dispositivos conformaban un arreglo para poder activarlo (ensamblar el arreglo pre-existente). Para eso
consultamos el superbloque de uno o más dispositivos y según la información obtenida sabremos los miembros que conformaban el
arreglo.
# mdadm -E /dev/hdb1
# mdadm -E /dev/hdb2
Una vez identificados los miembros del arreglo usaremos la siguiente sintaxis de mdadm para reactivarlo:
Eliminación de miembros
La eliminación de miembros de un arreglo puede ser posible cuando éstos no están activos o están marcados como fallados. La
siguiente sintaxis de mdadm para eliminar miembros es como sigue:
Adición de miembros
La sintaxis de mdadm para agregar dispositivos como miembros del arreglo es la siguiente:
En todo momento el arreglo usará sólo la cantidad de dispositivos que se le definieron como activos (opción -n) en el momento de su
creación. Si al arreglo se le removió un miembro o fue marcado como fallado entonces se considera que el arreglo está incompleto e
intentará automáticamente reemplazar el miembro faltante por algún otro inactivo disponible como repuesto (opción -x).
Si no existen dispositivos activos para ser usados como repuesto entonces apenas se agregue uno como miembro al arreglo éste será
tomado como reemplazo del faltante y marcado como activo para su uso, empezando así el proceso de sincronización respectivo.
Crecimiento de arreglos
Un arreglo puede crecer en tamaño a través del incremento de dispositivos miembros activos. Esto es posible con el uso de mdadm
como sigue:
El parámetro numérico de la opción -n debe reflejar la nueva cantidad de miembros activos del arreglo. La opción --backup-file no
es necesaria pero sí recomendable para restaurar el arreglo en caso de corrupción durante el proceso si se interrumpe por alguna
razón (tal como cortes de fluido eléctrico).
En caso necesitemos ver información sobre el estado de sincronización de miembros de un arreglo lo podemos hacer viendo de forma
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 104
Source Linux
estática el contenido de /proc/mdstat o de examinando de forma dinámica su avance como sigue:
Ejemplo 25:
a) Asumiendo que se tienen a /dev/hdb1, /dev/hdb2 y /dev/hdb3 como particiones del mismo tamaño con identificador fd, crear un RAID 1
con dos de ellos dejando el tercero reservado como repuesto inactivo en el arreglo.
Consultar luego la información del arreglo comprobando que el tercer dispositivo se encuentre inactivo:
b) Crear un sistema de archivos ext3 en este primero arreglo creado y montarlo sobre /mnt/raid1. Luego copiar los archivos /etc/*.conf a
dicho sistema de archivos recién montado:
c) Provocar la falla de uno de los dispositivos activos del arreglo, comprobar que el inactivo haya tomado su posición como reemplazo y
finalmente eliminar el dispositivo fallado. Comprobar que sólo queden dos dispositivos activos y que los datos dentro del sistema de
archivos permanezcan intactos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 105
Source Linux
6.3. Logical Volume Management (LVM)
Conceptos básicos
LVM es la implementación para Linux de un administrador de volúmenes lógicos que permite tener una visión del almacenamiento de
disco en un nivel superior que el representado por el esquema tradicional de discos y particiones.
Los volúmenes de almacenamiento creados por LVM permiten aprovechar una serie de ventajas tales como:
✔ Mover volúmenes
✔ Redimensionar volúmenes
✔ Crear instantáneas de volúmenes (snapshots)
Pudiendo todas estas tareas ser realizadas en caliente. Esto representa una solución al problema típico de la difícil decisión de
particionamiento inicial al momento de instalación de un sistema operativo Linux. Es común que en un principio no se sepa cuánto
espacio reservar para cada sistema de archivos (/, /home, /usr; /var, /tmp, etc) por lo que puede suceder que a uno de ellos se reserve
menos espacio de lo debido y se llene rápidamente, o para evitarse problemas se decida asignar todo el espacio a la raíz trayendo
consigo un potencial riesgo de seguridad.
LVM representa una solución ideal permitiendo que cualquiera de esos sistemas de archivos creados sobre volúmenes lógicos sean
capaces de crecer en tamaño cuando se creen nuevas particiones o se conecten discos adicionales al sistema.
Utilizando el esquema tradicional de particionamiento no tendríamos otra opción diferente a utilizar otro punto de montaje para un disco
duro nuevo si pretendíamos expandir la capacidad de /home por ejemplo.
Anatomía de LVM
Para comprender la anatomía de LVM se deben estudiar los conceptos de cada uno de sus componentes los mismos que son
detallados a continuación:
Snapshots de LVM
Esta es quizás la mejor de las funcionalidades ofrecidas por LVM. Consiste en la creación de un dispositivo de bloques adicional que se
presenta como una copia idéntica de un Logical Volume congelando en algún punto del tiempo. Suele ser utilizado generalmente para
poder generar backups de sistemas de archivos en constante y rápida modificación sin detener el sistema generando para ello un
snapshot desde el cual se hace el respaldo de datos.
Una vez que el administrador termina de utilizar el snapshot éste puede ser eliminado sin ningún tipo de alteración sobre los datos del
Logical Volume original desde el cual se hizo la copia.
Un snapshot se crea de forma similar que un Logical Volume, es decir lleva un nombre y tamaño particular. Este último no tiene por qué
ser igual, menor o mayor al tamaño del Logical Volume original pero sí es muy importante tener en cuenta que una vez que el snapshot
se llena (la cantidad de datos escritos supera el tamaño del snapshot) éste queda deshabilitado; puede ser leído aún mientras está
montado pero no hacer ningún cambio dentro, y tras desmontarlo no será posible volver a montarlo más.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 106
Source Linux
Ilustración gráfica de componentes de LVM
# fdisk /dev/sda
Orden (m para obtener ayuda): t
Número de partición (1-4): 3
Código hexadecimal (escriba L para ver los códigos): 8e
Se ha cambiado el tipo de sistema de la partición 3 por 8e (Linux LVM)
# partprobe
pvscan
Escanea todos los discos en busca de Physical Volumes
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 107
Source Linux
Reporta información sobre Physical Volumes
Opciones:
Opciones:
--setphysicalvolumesize SIZE : Define el tamaño del Physical Volume según el valor de SIZE que puede tener sufijos como M, G.
Si no se especifica el tamaño del Physical Volume a través del parámetro arriba mostrado entonces se redimensionará al mismo
tamaño que tiene el dispositivo que lo alberga.
Opciones:
Esta herramienta permite mover los PE asignados en el PV origen hacia uno o más PV. Si se usa la opción -n entonces sólo se
moverán los PE que ocupa el LV especificado. Si se omite el PV destino entonces automáticamente se moverán los PE del PV origen
hacia cualquier otro PV del VG.
Opciones:
-s TAM : Define el tamaño del PE según TAM (debe ser múltiplo de 2) que puede llevar sufijos de tamaño como K, M, G, T.
Esta herramienta crea el VG conformado por uno o más PV especificados en la línea de comandos teniendo una capacidad total a la
suma de tamaños de cada uno de los PV.
vgscan
Escanea todos los discos en busca de Volume Groups y reconstruye caches
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 108
Source Linux
vgextend <VG> <PV> [PV] ...
Permite agregar uno o más Physical Volumes a un Volume Group para extender su tamaño
Opciones:
Opciones:
lvscan
Escanea todos los discos en busca de Logical Volumes
Opciones:
-l [+/-]EXT : Cambia el tamaño de un LV en unidades de LE expresadas en EXT. Con los signos + ó - el valor es agregado o
sustraído del tamaño actual del LV, y sin estos signos se asigna el valor de EXT como absoluto.
-L [+/-]SIZE : Cambia el tamaño de un LV según el tamaño expresado en SIZE que puede llevar sufijos como K, M, G o T. Con
los signos + ó - el valor es agregado o sustraído del tamaño actual del LV, y sin estos signos se asigna el valor de SIZE como
absoluto.
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 109
Source Linux
-a y|n : Activa (y) o desactiva (n) un Logical Volume
Opciones:
Ejemplo 26:
a) Asumiendo que se tienen a /dev/hdb5, /dev/hdb6 y /dev/hdb7 como particiones de tamaños 300 MB, 500 MB y 900 MB respectivamente
cada uno con el identificador 8e, crear un VG conformado por /dev/hdb5 únicamente y crear dentro 2 LV, uno de 100 MB y otro del
resto de capacidad. El primero de ellos usarla como SWAP adicional para el sistema y al segundo darle formato ext3, moviendo dentro
el contenido actual de /home y luego montándolo bajo esta ruta.
# pvcreate /dev/hdb5
# vgcreate sistema /dev/hdb5
# lvcreate -L 100M -n swap2 sistema
# mkswap /dev/sistema/swap2
# swapon /dev/sistema/swap2
# vgdisplay sistema # Consultamos el valor "Free PE / Size" para crear el siguiente LV
# lvcreate -l 46 -n home sistema
# mkfs -t ext3 /dev/sistema/home
# mkdir -t ext3 /mnt/lvm
# mount -t ext3 /dev/sistema/home /mnt/lvm
# mv -v /home/* /mnt/lvm
# mount --move /mnt/lvm /home
b) Dado que el VG sistema ya ha se llenado en capacidad, extenderlo en tamaño incluyendo a /dev/hdb6 como parte del VG. Luego
redimensionar el LV /dev/sistema/home a 500 MB y también expandir el sistema de archivos que hay dentro comprobando con df que
esto se haya logrado.
# pvcreate /dev/hdb6
# vgextend sistema /dev/hdb6
# vgdisplay sistema
# vgs sistema
# lvresize -L 500M /dev/sistema/home
# df -h /home
# resize2fs /dev/sistema/home
# df -h /home
c) Se requiere utilizar la partición /dev/hdb5 para otro uso por lo que hay que removerla del VG de LVM sin pérdida de datos. Como
prevención a este problema nos han dispuesto utilizar la partición /dev/hdb7 de mayor tamaño a donde debemos mover toda la
información actualmente ocupada. Realizar los pasos necesarios para lograr el objetivo utilizando herramientas de LVM:
# pvcreate /dev/hdb7
# vgextend sistema /dev/hdb7
# vgdisplay sistema
# pvdisplay /dev/hdb5 # Consultamos cuantos PE tiene asignados antes de moverlos
# pvmove -v -i 1 /dev/hdb5 # Movemos los PE de /dev/hdb5 a cualquier otro PV del VG
# df -h /home # Comprobamos la consistencia de /home y swap tras el cambio
# ls /home
# swapon -s
# pvs # Vemos el reporte final de uso de los PV
# vgreduce sistema /dev/hdb5 # Reducimos el VG quitandole el PV /dev/hdb5
# pvremove /dev/hdb5 # Limpiamos el dispositivo quedando listo para otro uso
# vgs sistema # Vemos el reporte final de uso del VG
d) Por mantenimiento del sistema se requiere desmontar todos los sistemas de archivos (excepto los necesarios para el
funcionamiento del sistema como la raíz) y desactivar los VG existentes; luego de 30 minutos se requiere volver a activarlos. Realizar
los pasos necesarios para lograr el objetivo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 110
Source Linux
# swapoff /dev/sistema/swap2
# umount /home
# vgchange -an sistema # Desactivar el VG sistema
# vgchange -ay sistema # Volver a activar el VG sistema
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 111
Source Linux
6.4. Laboratorio N° 6
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Utilizando como prueba los discos /dev/hdb, /dev/hdc, /dev/hdd y /dev/hde crear en cada uno de ellos particiones de 200 MB
para crear un arreglo de nivel 10 que a su vez forme parte de un Volume Group de nombre datos.
2. Crear un sistema de archivos ext3 en un LV que ocupe toda la capacidad del VG datos anteriormente creado. Montar dicho
sistema de archivos crear en él un archivo de 50 MB de tamaño.
3. Crear 1 partición de 1 GB en los discos /dev/hdb y /dev/hdc. Con ambas particiones formando un arreglo de nivel 1, expandir la
capacidad del VG.
4. Simular la falla de 3 dispositivos miembro del arreglo de nivel 10. Dada la situación de emergencia por el arreglo 10 en
estado degradado, como medida de precaución mover toda la información almacenada en ese arreglo a otra ubicación libre
dentro del VG datos.
5. Luego de restaurar el arreglo de nivel 10 (remover los dispositivos fallados y volverlos a agregar), crear un snapshot de 100
MB de capacidad del LV que contiene el sistema de archivos ext3. Montar el snapshot y crear tantos archivos en él como
sean necesarios para sobrepasar su capacidad hasta comprobar cómo el sistema lo deshabilita. Luego desmontar, eliminar
el snapshot y verificar si la información contenida en el LV original ha sido alterada o no.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 112
Source Linux
6.4.1. Solución del laboratorio N° 6
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Utilizando como prueba los discos /dev/hdb, /dev/hdc, /dev/hdd, /dev/hde crear en cada uno de ellos particiones de 200 MB para
crear un arreglo de nivel 10 que a su vez forme parte de un Volume Group de nombre datos.
# fdisk /dev/hdb
# fdisk /dev/hdc
# fdisk /dev/hdd
# fdisk /dev/hde
# pvcreate /dev/md0
# vgcreate datos /dev/md0
2. Crear un sistema de archivos ext3 en un LV que ocupe toda la capacidad del VG datos anteriormente creado. Montar dicho
sistema de archivos crear en él un archivo de 50 MB de tamaño.
# vgdisplay datos
+ Creamos el LV:
3. Crear 1 partición de 1 GB en los discos /dev/hdb y /dev/hdc. Con ambas particiones formando un arreglo de nivel 1, expandir
la capacidad del VG.
# fdisk /dev/hdb
# fdisk /dev/hdc
# pvcreate /dev/md1
# vgextend datos /dev/md1
4. Simular la falla de 3 dispositivos miembro del arreglo de nivel 10. Dada la situación de emergencia por el arreglo 10 en
estado degradado, como medida de precaución mover toda la información almacenada en ese arreglo a otra ubicación libre
dentro del VG datos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 113
Source Linux
# pvmove -i 1 /dev/md0
5. Luego de restaurar el arreglo de nivel 10 (remover los dispositivos fallados y volverlos a agregar), crear un snapshot de 100
MB de capacidad del LV que contiene el sistema de archivos ext3. Montar el snapshot y crear tantos archivos en él como
sean necesarios para sobrepasar su capacidad hasta comprobar cómo el sistema lo deshabilita. Luego desmontar, eliminar
el snapshot y verificar si la información contenida en el LV original ha sido alterada o no.
+ A través de mdadm eliminamos los dispositivos fallados y los volvemos a insertar en el arreglo:
+ Creamos dentro del sistema de archivos que contiene el snapshot archivos de gran tamaño hasta sobrepasar los 100 MB
de su capacidad:
+ ¿Se observó algún mensaje de error tras la última operación? ¿Alguna información de interés en la salida del comando
dmesg? Desmontemos y eliminemos el snapshot.
# umount /mnt/snapshot
# lvremove -f /dev/sistema/snap1
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 114
Source Linux
Unidad 7: Instalación
7.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
1. Conocer la arquitectura
El kernel Linux en la actualidad ha sido portado a un enorme número de arquitecturas como x86, x86-64, Itanium, Power,
PowerPC, Sparc (32 y 64 bits), Alpha, ARM, PA-RISC, entre muchos otros.
Aunque puede ser poco común que nos crucemos con una arquitectura distinta a x86 o x86-64, siempre es necesario estar
seguros de la arquitectura del hardware sobre el cual vamos a instalar el sistema.
Red Hat Enterprise Linux 5 está disponible para las arquitecturas x86, x86-64, Itanium, Power y zSeries (s/390), en cambio
CentOS 5 sólo para x86 y x86-64.
Debian GNU/Linux 5 está disponible en más arquitecturas que son alpha, amd64 (x86-64), arm, armel, hppa, i386 (x86), ia64
(Itanium), mips, mipsel, powerpc, sparc y s390.
2. Medio de instalación
La fuente de instalación del sistema operativo en la mayoría de casos ha de ser uno o más discos compactos (CDROM,
DVD) los cuales deben ser para la misma arquitectura que tenemos en nuestro hardware. Sólo en el caso puntual de x86-64
tenemos que es posible instalar encima un sistema operativo diseñado para x86 (32 bits) aunque esto implique no
aprovechar los beneficios reales de la arquitectura de 64 bits.
En muchos casos se puede optar por un método de instalación que inicie desde la red a través de PXE, siempre y cuando
sea soportado por nuestro hardware.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 115
Source Linux
inicial que tiene una forma como la siguiente:
• memtes86
• linux [parametros]
La primera de ellas realiza un test de la memoria del sistema. La segunda inicia el proceso de instalación con parámetros específicos,
algunos de los cuales se muestra a continuación:
Parámetro Descripción
text Inicia el proceso de instalación en modo texto, en lugar de hacerlo en modo gráfico (por
defecto).
mem=CANT Define a través del valor de CANT (con el sufijo M de MB) la cantidad de memoria a informar
como disponible al sistema de instalación.
dd Se utiliza si se ha de insertar algún driver para el kernel durante el proceso de instalación.
askmethod Consulta el método de instalación a usar (CDROM/DVD, Disco local, NFS, HTTP, FTP) en lugar
de usar por defecto el CDROM/DVD local.
resolution=<W>x<H> Define la resolución de la pantalla a usar según los valores de W y H (Ejm: 1024x768)
No arranca el proceso de instalación sino un entorno de rescate que tiene por objetivo ejecutar
rescue una shell que puede servidor para acceder a un sistema ya instalado con el propósito de
corregir errores.
ip=IP Define la dirección IP que se asignará al sistema durante el proceso de instalación.
netmask=MASCARA Define la máscara de red que se asignará al sistema durante el proceso de instalación.
gateway=GW Define la dirección del gateway que se asignará al sistema durante el proceso de instalación.
dns=DNS1,DNS2 Define las direcciones IP de los servidores DNS que se asignarán al sistema durante el proceso
de instalación.
syslog=IP:PUERTO Guardar el log del proceso de instalación en un servidor syslog en la red
vnc Activa el acceso remoto vía VNC al proceso de instalación
vncpassword=PASSWD Define el password de acceso VNC al proceso de instalación.
mpath Inicia el proceso de instalación con soporte multipath. También instala y configura el sistema
operativo para que pueda arrancar desde una SAN con soporte multipath.
ks=floppy:/ruta/ks.cfg
ks=cdrom:/ruta/ks.cfg
ks=http://URL/ruta/ks.cfg Inicia una instalación automática con Kickstart buscando el archivo ks.cfg en una de las rutas
ks=ftp://URL/ruta/ks.cfg especificadas.
ks=nfs:host:/ruta/ks.cfg
Métodos de instalación
Cuando invocamos el proceso de instalación con la opción askmethod, luego de la opción de configuración de idioma del sistema y
teclado, se nos preguntará qué método de instalación usaremos, entre los que tenemos disponibles:
• CDROM local : Opción por defecto Utiliza el contenido del CDROM/DVD para instalar.
• Disco duro : Busca en un disco duro local las imágenes ISO del CDROM/DVD para instalar desde ahí.
• Imagen NFS : Busca en un servidor NFS las imágenes ISO o el contenido del CDROM/DVD para instalar desde ahí.
• FTP : Busca en un servidor FTP y ruta específica el contenido del CDROM/DVD para instalar desde ahí.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 116
Source Linux
• HTTP : Busca en un servidor FTP y ruta específica el contenido del CDROM/DVD para instalar desde ahí.
4. Número de instalación
Este paso que se muestra sólo en Red Hat Enterprise Linux, no en CentOS, solicita que se indique el código de instalación
respectivo que vino con nuestro Media Kit (caja que contiene los DVDs de instalación de Red Hat a quien previamente se les
compró).
La instalación puede continuar si omitimos el número de instalación pero el instalador Anaconda no permitirá la instalación ni
configuración de los grupos de paquetes de Clustering y Virtualización.
6. Configuración de particionamiento
El instalador nos da algunas alternativas que pretenden particionar de forma automática nuestro(s) disco(s) duro(s).
Podemos optar también por configurar manualmente las particiones nosotros mismos. También es posible configurar un
almacenamiento externo a través de iSCSI.
Los pasos siguientes asumen que se eligió un diseño personalizado de la tabla de particiones.
7. Particionamiento manual
A través de una interfaz intuitiva se puede crear y eliminar particiones, definir dispositivos RAID y LVM, dar formato a las
particiones como swap o con un sistema de archivos y definir puntos de montaje.
1. Licencia
Este paso que se muestra sólo en Red Hat Enterprise Linux, no en CentOS, solicita leamos y aceptemos la licencia mostrada
para proseguir.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 117
Source Linux
2. Configuración del firewall
Podemos elegir qué servicios permitir a través del firewall o simplemente desactivarlo.
3. Configuración de SELinux
Podemos elegir una configuración Estricta o Permisiva de SELinux, o simplemente deshabilitarlo. Si realmente no se conoce
cómo se usa esta funcionalidad es mejor deshabilitarla.
4. Configuración de Kdump
Esta herramienta usada para depuración de errores del kernel debe ser activa sólo si realmente se sabe lo que se está
haciendo.
Particionamiento apropiado
Dado que el proceso de instalación implica hacer un particionamiento del disco, es importante tener en cuenta algunas
recomendaciones de rendimiento y seguridad.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 118
Source Linux
opciones de montaje.
Archivos variables del sistema, puede ser instalado sobre un arreglo o un
Logical Volume. Dado que los datos aquí almacenados pueden crecer
noexec,nosuid, rápidamente podrían llenar y colapsar el sistema si se incluye en una
/var nodev 10 GB
única partición dentro de la raíz.
Dentro de /var/tmp también se almacenan temporales que al igual que
/tmp pueden ser aprovechados para los mismos propósitos.
El directorio de usuarios del sistema, puede ser instalado sobre un arreglo
noexec,nosuid, o un Logical Volume. La cantidad de datos que puede crecer en estos
/home nodev 10 GB directorios, podría llenar y colapsar el sistema.
Al igual que /tmp puede ser usado por usuarios para instalar y/o ejecutar
software potencialmente peligroso, por ello las opciones de montaje.
Observaciones:
• Estas recomendaciones se mencionan con la seguridad en mente. Por ello puede que sean más apropiadas para
instalaciones de servidor, en lugar de instalaciones para desktop o uso personal.
• Para instalaciones de uso personal o desktop también es recomendable separar la partición /home para prevenir que la raíz
llene su capacidad y para facilitar la restauración de datos si se requiere reinstalar el sistema operativo: sólo se requiere
formatear la raíz y no /home.
• Las recomendaciones de tamaño son sólo eso, recomendaciones. Cada escenario es distinto en necesidades y se puede
requerir más o menos espacio dependiendo del rol que vaya a desempeñar nuestro sistema. Puede que se requiera más
espacio en /var si instalamos un servidor de correo, o quizás más espacio en /home si pretendemos implementar un servidor
de archivos y/o FTP para usuarios. Incluso podríamos optar por montar otros sistemas de archivos en directorios distintos
siempre teniendo en cuenta la misma lógica de seguridad arriba mencionada para considerar las opciones de montaje que
sean apropiadas para nuestro caso.
Algunas de las tareas que se puede automatizar usando Kickstart en un proceso de instalación incluye:
✔ Configuración de idioma.
✔ Configuración de mouse y teclado.
✔ Instalación y configuración del gestor de arranque.
✔ Particionamiento y montaje de discos.
✔ Configuración de red.
✔ Autenticación NIS, LDAP, Kerberos y Samba.
✔ Configuración de firewall.
✔ Selección de paquetes a instalar.
✔ Configuración del servidor gráfico X.
El procedimiento para realizar una instalación con Kickstart consiste en los siguientes pasos:
# Comandos de Kickstart
comando 1
comando 2
comando 3
...
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 119
Source Linux
# Paquetes a instalar
%packages [opciones]
@grupo-paquetes 1
@grupo-paquetes 2
@grupo-paquetes 3
...
...
paquete 1
paquete 2
paquete 3
...
...
# Scripts pre-instalación
%pre [opciones]
sentencias de script ...
sentencias de script ...
sentencias de script ...
...
...
# Scripts post-instalación
%post [opciones]
sentencias de script ...
sentencias de script ...
sentencias de script ...
...
...
El orden de estas secciones no puede alterarse, siempre irá primero la sección Comandos, luego los Paquetes a instalar, luego los
Scripts pre-instalación y luego los Scripts post-instalación.
Analicemos con mayor detalle la sintaxis de configuración de cada una de estas secciones:
Sección Comandos
En esta sección podemos definir una serie de comandos Kickstart cada uno con sus propios parámetros. Algunos de los comandos
más importantes se resume debajo:
autopart
Opcional. Crea particiones de forma automática: 1 GB o más para la raíz, una partición swap y otra para /boot
ignoredisk [opciones]
Opcional. Ignora ciertas unidades de disco durante la instalación.
Opciones:
--drives=<disco1>[,disco2],...
Define los discos a ignorar. Ejm: --drives=sdf,sdg,hdc
authconfig [opciones]
Obligatorio. Define las opciones de autenticación para el sistema.
Opciones:
--enablemd5
Usa cifrado MD5 para las contraseñas de usuarios.
--enableshadow
Usa el sistema de contraseñas shadow.
--enableshadow
Usa el sistema de contraseñas shadow.
bootloader [opciones]
Obligatorio. Define cómo debería ser instalado el gestor de arranque.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 120
Source Linux
Opciones:
--append=<BOOTPARAM>
Define los parámetros de arranque del kernel en BOOTPARAM. Ejm: --apend="ide=nodma hdd=ide-scsi"
--driveorder=<disco1>[,disco2]
Especifica qué disco es primero en el orden de arranque de la BIOS. Ejm: --driveorder=sda,hda
--location=<mbr|partition|none>
Define dónde instalar el gestor de arranque:
--password=PASSWD
Protege el gestor de arranque con una contraseña PASSWD en texto plano.
--md5pass=PASSWD
Igual que --password pero PASSWD está cifrado en MD5
clearpart [opciones]
Opcional. Elimina particiones del sistema antes de crear otras nuevas. Por defecto ninguna partición es eliminada.
Opciones:
--all
Elimina todas las particiones del sistema
--drives=<disco1>[,disco2],...
Especifica de qué discos eliminar las particiones. Ejm: --drives=sda,sdb
--initlabel
Inicializa la tabla de particiones
--linux
Elimina todas las particiones Linux
--none
No elimina ninguna partición
firewall [opciones]
Opcional. Define la configuración de firewall del sistema.
Opciones:
--enabled
Habilita el firewall en el sistema.
--disabled
Deshabilita el firewall en el sistema.
--port=<puerto1:protocolo1>[,puerto2:protocolo2],...
Define las conexiones cuyo puerto y protocolo indicados son permitidos. Ejm: --port=443:tcp –port=http:tcp,domain:udp
firstboot [opciones]
Opcional. Determina si el instalador debe ejecutar el asistente de Primer arranque (post-instalación) una vez culminada la instalación.
Opciones:
--enabled
El instalador sí ejecutará el asistente de Primer arranque.
--disabled
El instalador no ejecutará el asistente de Primer arranque.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 121
Source Linux
graphical
Opcional. Ejecuta la instalación en modo gráfico. Esto sucede por defecto.
halt
Opcional. Apaga el sistema tras culminar la instalación.
install
Opcional. Invoca al instalador a hacer una nueva instalación en lugar de una actualización de un sistema existente. Se debe
especificar el método de instalación cdrom, harddrive, nfs o url en una línea distinta al comando install.
cdrom
Instala desde el primer CDROM/DVD local.
harddrive [opciones]
Instala desde un disco duro con ext2 o vfat que almacene el contenido del CDROM/DVD de instalación.
--partition=<partición>
Define la partición desde la cual instalar. Ejm: --partition=hdb2
--dir=<directorio>
Define el directorio que contiene la fuente de instalación. Ejm: --dir=/var/install
nfs [opciones]
Instala desde un servidor NFS.
--server=<host>
Define el servidor NFS desde el cual instalar. Ejm: --server=172.31.0.1
--dir=<directorio>
Define el directorio en el servidor NFS que contiene la fuente de instalación. Ejm: --dir=/nfs/install
url [opciones]
Instala desde un servidor FTP o HTTP.
--url=<URL>
Define la URL fuente de instalación. Ejm: --url=http://10.1.0.1/install –url=ftp://user:pass@10.1.0.1/install
Opciones:
--skip
Omite el número de instalación. Si no se indica este número entonces Anaconda se detendrá hasta que el usuario lo ingrese.
keyboard <mapa>
Obligatorio. Define el mapa o idioma de teclado. Algunos valores posibles son: es, la-latin1, us
lang <idioma>
Obligatorio. Define el idioma de la instalación e idioma por defecto del sistema instalado. Algunos posibles valores son: en_US,
en_GB, es_ES, es_PE.
Opciones:
--fstype=<FS>
Define el sistema de archivos. Ejm: --fstype=ext3, --fstype=ext2
--noformat
Usa un Logical Volume existente y no lo formatea.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 122
Source Linux
--useexisting
Usa un Logical Volume existente y sí lo formatea.
--grow
Indica que el Logical Volume debe crecer hasta ocupar todo el espacio disponible o hasta el tamaño máximo definido.
--maxsize=<TAM>
Define el tamaño máximo del Logical Volume en MB cuando se le ordena crecer con --grow
--recommended
Define el tamaño del Logical Volume automáticamente.
--percent
Define el tamaño del Logical Volume como un porcentaje del espacio disponible en el Volume Group.
network [opciones]
Opcional. Configura los parámetros de red del sistema.
Opciones:
--bootproto=<dhcp|static>
Define cómo es configurada la interfaz de red.
--device=<interfaz>
Define la interfaz a la cual asignarle los parámetros de red.
--onboot=<yes|no>
Define si se habilita o no la interfaz de red al arranque.
--ip=<dirección>
Define la dirección IP
--netmask=<máscara>
Define la máscara de red
--gateway=<gateway>
Define el gateway por defecto o puerta de enlace del sistema.
--nameserver=<dns1>
Define el servidor DNS primario del sistema.
--hostname=<hostname>
Define el nombre de host del sistema.
Opciones:
--size=<TAM>
Define el tamaño del dispositivo en MB según TAM (no lleva sufijos como M, MB o similares)
--grow
Indica que la partición debe crecer hasta ocupar todo el espacio disponible o hasta el tamaño máximo definido.
--maxsize=<TAM>
Define el tamaño máximo de la partición en MB cuando se le ordena crecer con --grow
--noformat
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 123
Source Linux
Ordena al instalador no formatear la partición para ser usado de la mano con --onpart
--onpart=<partición>
Define el punto de montaje en una partición ya existente. Ejm: part /home --onpart=sda1
--ondisk=<disco>
Fuerza la creación de la partición en un disco específico. Ejm: --ondisk=sdc
--asprimary
Fuerza la creación de la partición como primaria.
--fstype=<FS>
Define el sistema de archivos. Ejm: --fstype=ext3, --fstype=ext2
--recommended
Define el tamaño de la partición automáticamente.
Opciones:
--level=<nivel>
Define el nivel del arreglo. Puede ser 0, 1 ó 5. Ejm: --level=1
--device=<disp. MD>
Define el nombre del dispositivo RAID. Ejm: --device=md0
--spares=<CANT>
Define a través de CANT la cantidad de dispositivos inactivos que formarán parte del arreglo como repuestos.
--fstype=<FS>
Define el sistema de archivos. Ejm: --fstype=ext3, --fstype=ext2
--noformat
Usa un arreglo existente y no lo formatea.
--useexisting
Usa un arreglo existente y sí lo formatea.
reboot
Opcional. Reinicia el sistema tras culminar la instalación.
--iscrypted
Indica que el password especificado está ya cifrado.
selinux [opciones]
Opcional. Declara el estado de SELinux en el sistema.
--enforcing
Habilita SELinux con una política estricta (Enforcing).
--permissive
Habilita SELinux con una política permisiva (Permissive), sólo genera advertencias mas no ejerce la política.
--disabled
Deshabilita SELinux por completo en el sistema.
--enabled
Habilita el arranque en el sistema de los servicios especificados en la lista.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 124
Source Linux
--disabled
Deshabilita el arranque en el sistema de los servicios especificados en la lista.
text
Opcional. Realiza la instalación en modo texto.
--utc
Permite interpretar la hora del reloj de hardware en el sistema UTC.
--groups=<grupo1>[,grupo2],...
Indica los grupos secundarios a los que pertenecerá el usuario.
--homedir=<dir>
Define a través de dir el directorio personal del usuario.
--password=<password>
Define el password del usuario.
--iscrypted
Indica que el password especificado está ya cifrado.
--shell=<SH>
Define a través de SH la shell del usuario.
--uid=<UID>
Define a través de UID el identificador numérico (UID) del usuario.
vnc [opciones]
Opcional. Permite que la instalación gráfica sea visible a través de VNC.
--port=<PORT>
Especifica a través de PORT el puerto de conexión al servidor VNC.
--password=<PASSWD>
Especifica a través de PASSWD el password de conexión al servidor VNC.
--noformat
Utiliza un Volume Group existente y no lo formatea.
--useexisting
Utiliza un Volume Group existente y sí lo formatea.
--pesize
Define el tamaño del PE en el Volume Group.
xconfig [opciones]
Opcional. Configura el servidor gráfico X.
--driver=<driver>
Define el nombre del driver de X que será usado.
--videoram=<CANT>
Define a través de CANT la cantidad de memoria de video que posee la tarjeta gráfica.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 125
Source Linux
--defaultdesktop=<GNOME|KDE>
Define cuál será el entorno gráfico por defecto.
--startxonboot
Define si se iniciará o no el inicio de sesión gráfico al iniciar el sistema.
--resolution=<W>x<H>
Define a través de W (ancho) y H (alto) la resolución de la pantalla. Ejm: --resolution=1024x768
--depth=<DEPTH>
Define a través de DEPTH la profundidad de color predeterminada en el servidor gráfico X.
Dado que los comandos de particionamiento pueden haber resultado poco claros y quizás confusos, se muestra un ejemplo que puede
facilitar su comprensión:
Los nombres de los grupos de paquetes tienen la siguiente forma dentro del archivo XML:
<comps>
<group>
<id>admin-tools</id>
...
...
<id>development-libs</id>
...
...
<id>editors</id>
...
...
<id>gnome-desktop</id>
...
...
Mientras que los nombres de los paquetes individuales tienen la siguiente forma:
<packagelist>
<packagereq type="optional">adjtimex</packagereq>
<packagereq type="optional">arpwatch</packagereq>
<packagereq type="optional">audit</packagereq>
...
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 126
Source Linux
Dado que este es un archivo XML que nos tomaría cierto tiempo leer con rapidez para encontrar los nombres de los paquetes, pero el
siguiente comando nos hace un listado rápido de los grupos existentes:
Así también los nombres de paquetes lo podemos encontrar con la siguiente sentencia:
Una vez identificados todos los nombres de paquetes y grupos de paquetes disponibles en una instalación de Red Hat Enterprise
Linux, pasaremos a identificar cómo especificarlos dentro del archivo Kickstart.
Como se mencionó antes, esta es la sintaxis de la sección de paquetes:
%packages [opciones]
@grupo-paquetes 1
@grupo-paquetes 2
...
paquete 1
paquete 2
...
--nobase
No instala el paquete @base si se pretende instalar un sistema realmente pequeño.
--ignoremissing
Ignorar los paquetes y grupos de paquetes faltantes en lugar de detener la instalación pidiendo intervención del usuario.
También es posible eliminar un paquete de la lista de predeterminados en su grupo colocando el signo – al inicio del nombre del
mismo.
Este sería un buen ejemplo de la sección %packages dentro de un archivo Kickstart:
%packages
@office
@development-libs
@editors
@text-internet
@gnome-desktop
@dialup
@core
@base
@games
@base-x
@graphics
@printing
@kde-desktop
@spanish-support
@sound-and-video
@development-tools
@graphical-internet
kdepim
device-mapper-multipath
xorg-x11-server-Xnest
xorg-x11-server-Xvfb
kdegraphics
libsane-hpaio
kdemultimedia
imake
-autofs
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 127
Source Linux
%pre [opciones]
sentencias de script ...
sentencias de script ...
sentencias de script ...
...
--interpreter <intérprete>
Especifica el intérprete de scripting a usar. Ejm: %pre --interpreter /usr/bin/python
%pre
#!/bin/bash
# Agregamos un comentario a /etc/motd
echo "Red Hat Enterprise Linux instalado el $(date)" > /etc/motd
%post [opciones]
sentencias de script ...
sentencias de script ...
sentencias de script ...
...
--nochroot
Indica que los comandos deben ser ejecutados fuera del entorno chroot de instalación.
--interpreter <intérprete>
Especifica el intérprete de scripting a usar. Ejm: %post --interpreter /usr/bin/python
Hay que considerar que por defecto el ámbito sobre el cual se ejecutan los scripts es un entorno chroot, es decir está dentro de una
jaula que no permite el acceso al exterior. Si se desea salir del entorno chroot se debe tener en cuenta que la raíz del sistema instalado
está debajo del directorio /mnt/sysimage.
%post
#!/bin/bash
# Definimos un punto de montaje CIFS predeterminado
echo "//10.0.0.10/data /share cifs defaults,credentials=/etc/smb.auth 0 0" >> /etc/fstab
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 128
Source Linux
Configuración gráfica de Kickstart
El proceso de configuración de Kickstart puede ser simplificado a través de una herramienta gráfica llamada Kickstart Configurator.
Esta herramienta está disponible sólo si se instala el paquete system-config-kickstart y se podrá acceder a ella desde un
entorno gráfico como GNOME o KDE.
Puede usarse Kickstart Configurator como reemplazo o complemento del proceso de configuración manual de un archivo Kickstart.
• En un disquete
• En un CDROM
• En la red
Si se usa un disquete, éste debe contener un sistema de archivos vfat o ext2. Se puede publicar el archivo Kickstart en la red a través
de un servicio NFS, HTTP o FTP. El archivo Kickstart siempre debe llevar el nombre ks.cfg.
Podemos crear nuestro archivo ks.cfg a partir de un modelo que se crea automáticamente tras cada instalación. Este modelo es
anaconda-ks.cfg ubicado en /root.
install
cdrom
lang es_ES.UTF-8
keyboard la-latin1
xconfig --startxonboot
network --device eth0 --bootproto static --ip 172.31.0.19 --netmask 255.255.255.0 –gateway
172.31.0.1 --nameserver 172.31.0.2 --hostname kickstart.consultorianet.com
rootpw --iscrypted $1$sV4KB8DZ$wEGf7LArS67xIMrjOXYPg0
authconfig --enableshadow --enablemd5
timezone --utc America/Lima
bootloader --location=mbr
clearpart --all --initlabel
part /boot --fstype=ext3 --size=100
part pv.01 --size=1 --grow
volgroup sistema pv.01
logvol swap --fstype swap --name swap --vgname=sistema --size=1024
logvol / --fstype ext3 --name=root --vgname=sistema --size=1 --grow
firewall --disabled
selinux --disabled
firstboot --disabled
services --disabled autofs,sendmail,portmap,nfslock,cups,rpcidmapd,pcscd,hplip,hidd,bluetooth
reboot
%packages
@office
@development-libs
@editors
@text-internet
@gnome-desktop
@dialup
@core
@base
@games
@base-x
@graphics
@printing
@kde-desktop
@spanish-support
@sound-and-video
@development-tools
@graphical-internet
kdepim
device-mapper-multipath
xorg-x11-server-Xnest
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 129
Source Linux
xorg-x11-server-Xvfb
kdegraphics
libsane-hpaio
kdemultimedia
imake
screen
%post
#!/bin/bash
cat >> /etc/yum.repos.d/dag.repo << EOF
[dag]
name=dag
gpgcheck=0
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag/
enabled=0
EOF
• @office
• @development-libs
• @editors
• @text-internet
• @gnome-desktop
• @dialup
• @core
• @base
• @games
• @base-x
• @graphics
• @printing
• @kde-desktop
• @spanish-support
• @sound-and-video
• @development-tools
• @graphical-internet
• kdepim
• device-mapper-multipath
• xorg-x11-server-Xnest
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 130
Source Linux
• xorg-x11-server-Xvfb
• kdegraphics
• libsane-hpaio
• kdemultimedia
• imake
• screen
23. Tras culminar la instalación se ejecuta un script en Bash que tiene por objetivo crear un archivo de repositorios .repo para
descargar software adicional de terceros.
Este archivo podríamos publicarlo en un directorio particular con Apache e invocar al proceso de instalación en el prompt boot: como
sigue:
Observaciones:
• Puede que requiera adquirir cierta práctica personalizar archivos de configuración tras un aprendizaje de pruebas y errores.
• El ejemplo arriba mostrado asume que se detectará automáticamente si existe uno o más discos en el sistema y los utilizará
todos para borrarlos por completo. Con un poco de cuidado en la creación del archivo Kickstart se puede detallar qué discos
duros utilizar para la instalación y formatear sólo algunas particiones si se pretende dejar otras intactas.
• Los parámetros de red especificados en el prompt boot: de arranque de la instalación no tienen por qué ser iguales a los
especificados en el archivo Kickstart, pues estos últimos son los que mandarán en la configuración final del sistema ya
instalado.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 131
Source Linux
7.3. Laboratorio N° 7
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Usando un disco duro que se pueda borrar por completo (no menor de 4 GB de capacidad) , realizar una instalación manual
en modo texto por red extrayendo la fuente de instalación desde un servidor HTTP. Seleccionar la instalación mínima (implica
instalar sólo el sistema base). Crear una partición para /boot con ext3, y el resto del disco utilizarlo para LVM creando dentro
un LV para swap de tamaño apropiado y otro LV para la raíz con el resto de capacidad restante dentro del VG de nombre
INSTALL1.
2. Tras culminar la instalación cree un archivo Kickstart basado en anaconda-ks.cfg que se debe haber creado en /root. Edítelo de
modo tal que incluya los comandos de particionamiento (eliminando todas las particiones existentes) acorde a:
• Firewall activado que permita el ingreso de conexiones sólo a los puertos TCP 22, 80 y 3128.
• SELinux deshabilitado.
• Deshabilitar los servicios portmap y nfslock.
• Instalar los paquetes adicionales httpd y squid.
• Reiniciar el sistema tras culminar la instalación.
• Agregar las opciones de montaje acl, usrquota y grpquota al sistema de archivos /home.
3. Con la experiencia adquirida en la instalación de sistemas Red Hat Enterprise Linux, realizar una instalación típica de
cualquier otra distribución Linux con el propósito de reforzar los conceptos básicos aprendidos.
Se sugiere instalar Debian GNU/Linux, openSUSE o Slackware por lo diferente que resultan sus procesos de instalación,
mientras que no optar Ubuntu o Fedora por ser éstas muy simples de instalar y no permitirá poner en práctica lo aprendido.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 132
Source Linux
7.3.1. Solución del laboratorio N° 7
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Usando un disco duro que se pueda borrar por completo (no menor de 4 GB de capacidad) , realizar una instalación manual
en modo texto por red extrayendo la fuente de instalación desde un servidor HTTP. Seleccionar la instalación mínima (implica
instalar sólo el sistema base). Crear una partición para /boot con ext3, y el resto del disco utilizarlo para LVM creando dentro
un LV para swap de tamaño apropiado y otro LV para la raíz con el resto de capacidad restante dentro del VG de nombre
INSTALL1.
+ Iniciar el instalador escribiendo lo siguiente tras el prompt boot (los parámetros de red pueden ser distintos o ser omitidos):
+ Tras elegir el idioma del sistema y teclado, al ser consultado sobre el método de instalación, elegir HTTP e ingresar el
nombre o IP de un servidor HTTP y debajo la ruta que publica la instalación.
Estos parámetros pueden ser facilitados por el docente durante la clase o desde otro equipo en la red podemos publicar
nosotros mismos el contenido de instalación. En un sistema Red Hat Linux típico se haría de este modo:
Esto publicaría el directorio de instalación bajo una URL como http://HOST/install donde HOST corresponde al nombre o IP
de nuestro equipo en la red que ofrece el servicio HTTP.
+ Indicar al instalador que se realizará una instalación nueva y tras continuar se llegará a la fase de particionamiento, donde
debemos elegir un Diseño personalizado para ejecutar lo siguiente:
• Dar clic en el botón Nuevo, elegir /boot como punto de montaje, definir 100 MB de tamaño, escoger ext3 como sistema
de archivos y finalmente dar clic en el botón Aceptar.
• Dar clic en el botón Nuevo, indicar que el tamaño ocupará hasta el máximo permitido, escoger physical volume (LVM)
como sistema de archivos y finalmente dar clic en el botón Aceptar.
• Dar clic en el botón LVM, escribir INSTALL1 como nombre del Volume Group, y luego dar clic sobre el botón Añadir dos
veces, una para crear un LV de nombre swap de 512 MB de tamaño y swap como sistema de archivos, y otra para crear
un LV de nombre root del tamaño restante con sistema de archivos ext3 y punto de montaje /
+ Tras terminar de definir las particiones, continuar con otros parámetros de configuración como la zona horaria, password de
root, gestor de arranque, etc.
+ Al llegar a la instalación de paquetes, elegir una selección personalizada y asegurarnos de desmarcar todos los grupos
(Editores, Sistema X Window, Gráficos, Juegos, etc...) excepto el llamado Base, de modo que nos aseguremos que se instale
un sistema sólo en modo texto.
+ Aceptar las configuraciones hechas al instalador e iniciar la instalación. Reiniciar el sistema y tras el arranque dejar intactas
las configuraciones del Primer arranque, esto implicaría dejar habilitado el Firewall y SELinux; opcionalmente se puede crear
una cuenta de usuario y/o cambiar la fecha y hora del sistema.
2. Tras culminar la instalación cree un archivo Kickstart basado en anaconda-ks.cfg que se debe haber creado en /root. Edítelo de
modo tal que incluya los comandos de particionamiento (eliminando todas las particiones existentes) acorde a:
• Firewall activado que permita el ingreso de conexiones sólo a los puertos TCP 22, 80 y 3128.
• SELinux deshabilitado.
• Deshabilitar los servicios portmap y nfslock.
• Instalar los paquetes adicionales httpd y squid.
• Reiniciar el sistema tras culminar la instalación.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 133
Source Linux
• Agregar las opciones de montaje acl, usrquota y grpquota al sistema de archivos /home.
# cp /root/anaconda-ks.cfg /root/ks.cfg
install
cdrom
lang es_ES.UTF-8
keyboard es
network --device eth0 --bootproto static --ip 172.31.0.34 --netmask 255.255.255.0 --gateway
172.31.0.1 --nameserver 172.31.0.2 --hostname kickstart.consultorianet.com
rootpw --iscrypted $1$QpaiQwMf$749DsiTXCB8vijhnZOl2u1
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
timezone --utc America/Lima
bootloader --location=mbr
part /boot --fstype=ext3 --size=100
part pv.1 --size=1 --grow
volgroup INSTALL2 pv.11
logvol swap --fstype swap --name swap --vgname=INSTALL2 --size=300
logvol /home --fstype ext3 --name=home --vgname=INSTALL2 --size=200
logvol /tmp --fstype ext3 --name=tmp --vgname=INSTALL2 --size=100
logvol / --fstype ext3 --name=root --vgname=INSTALL2 --size=1 --grow
firewall --enabled –port=22:tcp,80:tcp,3128:tcp
selinux --disabled
services --disabled portmap,nfslock
reboot
%packages
@base
@core
@spanish-support
keyutils
trousers
fipscheck
device-mapper-multipath
httpd
squid
%post
#!/bin/bash
# Utilizando sed identificamos la entrada de montaje de /home y reemplazamos su opción de
# montaje defaults con defaults,acl,usrquota,grpquota
3. Con la experiencia adquirida en la instalación de sistemas Red Hat Enterprise Linux, realizar una instalación típica de
cualquier otra distribución Linux con el propósito de reforzar los conceptos básicos aprendidos.
Se sugiere instalar Debian GNU/Linux, openSUSE o Slackware por lo diferente que resultan sus procesos de instalación,
mientras que no optar Ubuntu o Fedora por ser éstas muy simples de instalar y no permitirá poner en práctica lo aprendido.
+ Se puede instalar cualquiera de estas distribuciones con videos o tutoriales didácticos que se pueden encontrar en Internet.
Sin embargo la siguiente URL específica contiene videos de instalación de varias distribuciones Linux:
http://linux.pucp.edu.pe/downloads/videos/video_tutoriales/tutor_online/
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 134
Source Linux
Unidad 8: Administración de software
8.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
Introducción
En los sistemas operativos Linux es muy común la instalación de software a través de dos modalidades que son:
1. Paquetes binarios con formato definido : Los paquetes binarios con formato definido son típicos de distribuciones Linux
tales como Red Hat, Debian, Slackware, que manejan sus propios formatos de instaladores de software. Por ejemplo
Red Hat utiliza el formato RPM (extensión .rpm) para sus paquetes binarios, Debian usa el formato DEB (extensión
.deb) y Slackware el formato TGZ (extensión .tgz).
Cabe resaltar que otras distribuciones pueden usar estos mismos formatos como por ejemplo CentOS, Fedora, SuSE,
usan RPM, pero Ubuntu utiliza DEB también.
Estos paquetes binarios con formato definido se suelen instalar con una herramienta propia de cada distribución Linux,
tal como el comando rpm o el comando dpkg.
2. Paquetes binarios genéricos : Generalmente se distribuyen a través de archivos con extensión .bin o .run y el propósito
de estos es poder ser instalados de la misma forma en cualquier distribución Linux. La forma de instalar estos paquetes
consiste tan sólo en darles permisos de ejecución e invocarlos desde la línea de comandos.
Cabe recalcar que cada uno de estas modalidades de instalación trae consigo ciertas salvedades:
• Los paquetes binarios con formato definido mantienen una base de datos interna que organiza todo el software instalado. Sin
embargo deseamos seguir usando los paquetes del mismo formato para instalar software en el futuro si pretendemos
mantener la organización; y es posible que cierto software publicado por terceros no esté disponible en el formato de
paquetes utilizado por nuestra distribución Linux.
• Los paquetes binarios genéricos ofrecen la ventaja de instalarse de forma sencilla en cualquier distribución Linux, pero no
será posible incluirlo en nuestra base de datos de software instalado debido a que no es compatible con el formato de
paquetes de nuestra distribución.
• El software instalado desde código fuente goza de la misma ventaja y desventaja que los paquetes binarios genéricos, no se
incluyen por defecto en nuestra base de datos de paquetes instalados.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 135
Source Linux
• Consultar la lista de paquetes instalados
La sintaxis del comando rpm es la siguiente:
Opciones de instalación:
-q : Consulta un paquete.
Opciones de selección:
Opciones de consulta:
-V : Verifica los archivos que contiene un paquete contra el estado original de dichos archivo según información en la base de
datos RPM.
-v : Muestra información adicional sobre la tarea que se está realizando.
Opciones de consulta:
--import : Importa un archivo de llaves públicas para verificación de paquetes.
Ejemplo 27:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 136
Source Linux
d) Eliminar el paquete ccze:
# rpm -e ccze
Esta herramienta cuyo comando lleva el mismo nombre, yum, tiene la siguiente sintaxis de uso:
Opciones:
Comandos:
YUM dispone de muchas más opciones que pueden ser revisadas en yum(8).
Ejemplo 28:
# yum grouplist
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 137
Source Linux
# yum groupinstall "mysql database"
# yum update -y
Red Hat Enterprise Linux, de manera particular, no habilita la descarga de software a través de repositorios sino hasta que el sistema
haya sido registrado en Red Hat Network con su correspondiente licencia de suscripción.
El procedimiento para realizar este registro es de la siguiente manera:
# rhn_register
Esta herramienta iniciará un asistente que nos consultará paso a paso los datos de nuestra cuenta ya registrada en Red Hat, para así
poder acceder a las actualizaciones y otro software del repositorio utilizando yum.
Asumiendo que trabajamos con CentOS o con un sistema Red Hat Enterprise Linux ya registrado en Red Hat Network, procederemos
con la configuración de repositorios creando uno o más archivos de extensión .repo dentro del directorio /etc/yum.repos.d.
Cada archivo .repo tiene la siguiente forma:
[ID1]
directiva=valor
directiva=valor
...
...
[ID2]
directiva=valor
directiva=valor
...
...
[ID3]
directiva=valor
...
Donde:
ID : Es un nombre identificador del repositorio, debe ser único entre todos los repositorios.
directiva : Es una directiva de configuración.
valor : Es el valor asignado a una directiva.
Directiva Descripción
name Define una descripción del repositorio.
baseurl Define una URL donde la metadata de un repositorio (directorio repodata) está alojada.
mirrorlist Define una URL a un archivo que contiene una lista de repositorios definidos por directivas baseurl.
enabled Si su valor es 1 el repositorio está habilitado, si es 0 está deshabilitado.
gpgcheck Si su valor es 1 se chequea la firma GPG de los paquetes obtenidos de este repositorio, si es 0 no se hace tal
chequeo.
gpgkey Define una URL que apunta a un archivo de llaves GPG para la verificación de paquetes.
proxy Define la URL a un servidor proxy por el cual realizar las operaciones de YUM.
proxy_username Define el usuario de autenticación para el proxy.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 138
Source Linux
proxy_password Define el password de autenticación para el proxy.
Ejemplo 29:
# vim /etc/yum.repos.d/dag.repo
[dag]
name=Repositorio DAG para RHEL, CentOS y Fedora
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag
enabled=0
gpgcheck=1
gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
c) Lo anterior importaría el archivo de firmas GPG (tras confirmación del usuario) desde la URL descrita en gpgkey, pero podríamos
haberla importado manualmente de este modo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 139
Source Linux
8.3. Sistema de paquetes DEB
Este sistema de paquetes originalmente creado por el proyecto Debian para su distribución Linux que lleva el mismo nombre, es en el
que se basan actualmente muchas distribuciones Linux como Ubuntu para la instalación de paquetes de software.
Este sistema se caracteriza por poseer el soporte de identificación de dependencias, es decir nos permite saber qué otros paquetes de
software requerimos instalar antes del software de nuestro interés.
Las tareas de administración de paquetes de software DEB se hace a través del comando dpkg el cual permite hacer tareas como:
Opciones:
Ejemplo 30:
# dpkg -I install_flash_player_10_linux.deb
# dpkg -c install_flash_player_10_linux.deb
# dpkg -i install_flash_player_10_linux.deb
# dpkg -L adobe-flashplugin
# dpkg -s adobe-flashplugin
# dpkg -r adobe-flashplugin
# dpkg -l "*core*"
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 140
Source Linux
Gestión simplificada de software DEB
El comando dpkg de manera análoga como sucede con el comando rpm, no permite automatizar la instalación de paquetes faltantes
para cumplir una dependencia. Para la realización de dicha tarea entre muchas otras como búsqueda de paquetes en repositorios,
actualización de paquetes desde Internet, eliminación de paquetes con sus dependencias, existe APT que a través de herramientas
como apt-cache, apt-get y apt-key se puede facilitar la gestión de administración de software en Debian.
Opciones:
-f : Muestra todos los campos al ofrecer resultados de búsquedas con el comando search.
--names-only : Ordena al comando search a buscar sólo en criterio al nombre de los paquetes.
Comandos:
apt-cache dispone de muchas más opciones que pueden ser revisadas en apt-cache(8).
Opciones:
Comandos:
update : Actualiza la caché de APT descargando los nuevos índices de paquetes desde repositorios.
upgrade : Actualiza desde repositorios todos los paquetes instalados en el sistema. Este comando no instalará ningún
paquete nuevo ni eliminará tampoco alguno ya instalado. Se obviará la actualización de paquetes que requieran modificar el estado
de instalación de otros paquetes como producto de una dependencia.
dist-upgrade : Similar al comando upgrade, pero será capaz de instalar nuevos paquetes o eliminar otros con tal de cumplir los
cambios de dependencias producto de la actualización.
install : Instala la última versión de un paquete y sus dependencias.
remove : Remueve un paquete y sus dependencias.
clean : Borra la caché de los paquetes descargados desde repositorios.
apt-get dispone de muchas más opciones que pueden ser revisadas en apt-get(8).
Comandos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 141
Source Linux
Ejemplo 31:
# apt-get update
e) Intentar reparar cualquier dependencia rota en el sistema, mientras se informa de la cantidad de paquetes pendientes por actualizar:
# apt-get install -f
f) Instalar todas las actualizaciones de paquetes pendientes, sin modificar el estado de instalación de otros paquetes:
# apt-get upgrade -y
La configuración de repositorios se centraliza en el archivo /etc/apt/sources.list que tiene un contenido similar al siguiente:
Donde:
Ejemplo 29:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 142
Source Linux
# vim /etc/apt/sources.list
b) Luego de guardar los cambios descargamos nuevamente los índices de repositorios para tener la información reciente sobre
paquetes:
# apt-get update
# apt-cdrom add
Esto provocaría que APT nos pida el CDROM o DVD necesario cuando intentemos instalar un paquete que se encuentra en este
medio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 143
Source Linux
8.4. Instalación desde código fuente
Introducción
La instalación desde código fuente es un método que se puede seguir casi de manera idéntica en cualquier sistema operativo UNIX,
pues el procedimiento consiste en lo mismo: compilar software e instalarlo.
Razones comunes por las que podríamos desear instalar software desde código fuente pueden ser:
✔ El software no es publicado por el autor en un formato binario para nuestro sistema operativo sino sólo en fuentes.
✔ El software en formato binario sí existe para nuestro sistema operativo, pero no en su versión más reciente.
✔ Deseamos modificar algunos parámetros de funcionamiento del software que no es posible desde su versión binaria sino
sólo tras una recompilación del mismo.
✔ Simplemente para aprender cómo hacerlo.
Podrían existir otras razones distintas pero cada una de ellas sustentada por los mismos usuarios encargados de hacerlo. Lo
importante es conocer los pasos generales para poder hacerlo, los mismos que a continuación resumimos:
1. Preparación: Obtener el tarball del software desde Internet u otro medio, y desempaquetarlo/descomprimirlo.
2. Configuración: Verificar que se cumplan las dependencias para una compilación exitosa y opcionalmente configurar
parámetros de construcción del software.
3. Compilación: Construcción del software con el uso de algún compilador del sistema.
4. Instalación: Colocar los binarios producto de la compilación en directorios específicos del sistema y opcionalmente realizar
algunos procedimientos posteriores de configuración.
Paso 1: Preparación
Este paso consiste en el más simple quizás de todos. Tras identificar qué software o conjunto de ellos deseamos instalar desde fuentes
debemos conseguirlos desde algún medio que comúnmente es a través de Internet.
Nosotros obtendremos un tarball el cual por lo general viene empaquetado y/o comprimido, por ello es necesario extraer su contenido
para poder seguir con el paso 2:
Esto genera por lo general un directorio que lleva el mismo nombre del tarball removiéndole la extensión .tar.gz. Procedemos a ingresar
a dicho directorio y explorar su contenido donde por lo general podemos encontrar:
Puede que algunas o todas de estos ficheros estén presentes pero en cualquiera de los casos es siempre recomendable leerlos. En
ellos por lo general se encontrará el procedimiento de cómo compilarlo e instalarlo, pues podría el procedimiento de instalación diferir
de los lineamientos generales que aquí mostramos.
Paso 2: Configuración
Este paso consiste en preparar el entorno para la compilación a través de la verificación de dependencias requeridas durante la
construcción del software, así como también la configuración de parámetros del producto final de la compilación.
Esto se suele realizar por lo general a través de la ejecución de un script de nombre configure ubicado en el directorio raíz del código
fuente del software previamente desempaquetado/descomprimido. La forma de ejecutarlo sería así:
# pwd
/usr/src/software-VERSION
# ./configure
El script en su mayoría de casos va a admitir el parámetro --help que mostrará las opciones de configuración del software:
# ./configure --help
Algunos de los parámetros que podría admitir este script permitiría por ejemplo definir la ruta de instalación del software, activar o
desactivar funcionalidades del software una vez compilado, activar el soporte para integración con librerías u otro software, etc.
La ejecución de este script va a verificar que todo el software necesario para una correcta compilación esté instalado en el sistema,
sino por lo general puede generar un error similar a este:
checking for libssl... configure: error: not found. Check your installation and look into
config.log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 144
Source Linux
Claro que el mensaje de error puede diferir mucho, pero aquí se requiere mucha atención por parte del usuario para poder apreciar qué
dependencia es la que está faltando. Si se aprecia el mensaje de ejemplo se entiende que la librería libz parece no estar presente.
Con esta información de la dependencia faltante podemos buscarla como:
Nótese que se busca el nombre de la librería seguido de la palabra dev o devel dado que generalmente los paquetes que contienen
la librerías de desarrollo de cierto software requerido para la compilación terminan en esa palabra: Ejm: openssl-devel, libssl-
dev
Luego procedemos a instalar los paquetes que satisfacen las dependencias faltantes:
Paso 3: Compilación
Este paso consiste en iniciar la compilación del software con la ejecución del comando make:
# make
El proceso de compilación puede demorar dependiendo del tamaño del software y su complejidad. Sin embargo es posible que este
procedimiento pueda fallar por un error de dependencias, incompatibilidades con nuestro sistema o simplemente un bug.
Aunque es más difícil depurar los errores en este paso es posible de todos modos entender a veces el error que nos puede informar de
algún archivo de dependencia faltante (sí, incluso el script configure pudo no detectar esta dependencia).
Paso 4: Instalación
Este paso consiste en instalar el software ya compilado con la ejecución del comando make install:
# make install
Si el software ha sido configurado -previo a la compilación- para ser instalado en un directorio del sistema como /usr o /usr/local
entonces este paso de instalación necesariamente requerirá ser ejecutado como usuario root.
Sin embargo un usuario sin privilegios podría haber definido a través del script configure que el software se instale en su directorio
personal por lo que este paso de instalación no requeriría ningún privilegio superior al que ya actualmente tiene.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 145
Source Linux
8.5. Laboratorio N° 8
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. En un sistema Red Hat Enterprise Linux 5/ CentOS 5, instalar el grupo de paquetes "MySQL Database" y "Ruby".
2. Agregar un repositorio local para YUM que apunte a la URL http://172.31.0.1/centos con la verificación de firmas GPG
deshabilitada.
3. Tras descargar el paquete webmin-1.490-1.noarch.rpm consultar los archivos que trae dentro y luego instalarlo.
4. Hacer un listado de todos los paquetes que coincidan con el patrón de texto ssl en un sistema Debian.
5. Descargar e instalar la última versión del servidor Web Apache siguiendo el proceso de construcción del software desde las
fuentes. Instalarlo debajo del directorio /usr/local/apache.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 146
Source Linux
8.5.1. Solución del laboratorio N° 8
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. En un sistema Red Hat Enterprise Linux 5/ CentOS 5, instalar el grupo de paquetes "MySQL Database" y "Ruby".
+ Comprobamos que existan esos grupos de paquetes haciendo un listado de los grupos:
# yum grouplist
2. Agregar un repositorio local para YUM que apunte a la URL http://172.31.0.1/centos con la verificación de firmas GPG
deshabilitada.
+ Creamos un archivo de nombre local.repo dentro del directorio /etc/yum.repos.d/ con el siguiente contenido:
[local]
name=Repositorio local en la LAN
baseurl=http://172.31.0.1/centos
gpgcheck=0
enabled=1
3. Tras descargar el paquete webmin-1.490-1.noarch.rpm consultar los archivos que trae dentro y luego instalarlo.
4. Hacer un listado de todos los paquetes que coincidan con el patrón de texto ssl en un sistema Debian.
5. Descargar e instalar la última versión del servidor Web Apache siguiendo el proceso de construcción del software desde las
fuentes. Instalarlo debajo del directorio /usr/local/apache.
# wget http://mirror.its.uidaho.edu/pub/apache/httpd/httpd-2.2.14.tar.gz
+ Lo descomprimimos y con el script configure verificamos las dependencias así como también definimos el directorio de
instalación:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 147
Source Linux
Unidad 9: Otros tópicos de administración del sistema
9.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
El kernel al igual que cualquier otro software se ha de construir a través de un proceso de compilación donde podremos decidir qué
funcionalidades habilitar o deshabilitar, teniendo como resultado un kernel de mayor o menor tamaño.
Justamente en el proceso de configuración y compilación del kernel es donde podemos decidir si la gran mayoría de las
funcionalidades las deseamos incluir en una única gran imagen del kernel, o deseamos dividirlas en porciones pequeñas de código
ejecutable que se carguen en demanda, según sean necesitadas por el sistema operativo. Esta última forma de construcción del kernel
en porciones de código llamados módulos se le conoce como un kernel modular.
Un kernel modular por lo general consiste de una imagen de poco tamaño -no superior a los 2 MB en muchos casos- y un conjunto de
módulos de menor tamaño -entre 9 KB y 1 MB en promedio- que se alojan en un directorio del sistema. Cuando el kernel es cargado
en memoria luego del gestor de arranque, intentará ir cargando otros módulos que sean necesarios en demanda mientras va iniciando
el sistema operativo.
Opciones:
-r : Descarga un módulo.
-l : Imprime un listado de los módulos.
-v : Imprime información de las acciones que está realizando.
Esta herramienta cuando se usa para cargar un módulo puede recibir uno o más parámetros asociados a dicho módulo, los mismos
que por lo general están en la información provista por la herramienta modinfo.
Esta herramienta provee información de un módulo tal como su ubicación, versión, licencia, autor, descripción, dependencias y
parámetros válidos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 148
Source Linux
lsmod
Lista los módulos actualmente cargados en el sistema
Esta herramienta extrae la información desde /proc/modules y la muestra formateada para informar cuáles son los módulos
actualmente cargados, sus tamaños y qué otros módulos están actualmente usándolos.
Por lo general muchos de los parámetros configurables del kernel están asociados a un nombre de archivo ubicado bajo /proc/sys,
reemplazando cada separador de directorio (/) por un punto. Por ejemplo la configuración del kernel net.ipv4.ipv4_forward (IP
forwarding) está ubicada en el archivo /proc/sys/net/ipv4/ip_forward.
Opciones:
Esta herramienta normalmente usa el símbolo punto (.) como separador, pero también puede admitir el símbolo slash (/) de forma
alternativa.
La cantidad de parámetros de configuración del kernel pueden ser variables y por lo general pueden superar fácilmente los 700, de
donde muchos de ellos lamentablemente no están documentados o es muy difícil acceder a la información de los mismos.
Algunos de estos parámetros están escritos como comentarios dentro del archivo /etc/sysctl.conf, muchos otros tantos estarán dentro
del directorio Documentation/sysctl, y otros muy probablemente sean documentados en algún lugar de Internet.
Ejemplo 32:
a) Tras compilar un driver de nombre test para nuestro sistema Linux, comprobar si ya ha sido instalado dentro del directorio de
módulos del kernel:
# modprobe -l | less
# modinfo test
c) Cargar el módulo msdos e ir viendo cómo resuelve otras dependencias que sean necesarias para cargarlo:
# modprobe -v msdos
d) Descargar el módulo msdos viendo cómo descarga otras de sus dependencias ya no necesarias:
# sysctl -w net.ipv4.ip_forward=1
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 149
Source Linux
9.3. Arranque del sistema
El gestor de arranque
El arranque de un computador inicia desde el momento en el que éste se enciende, ejecutando por lo general primero una etapa POST
(Power On Self Test) que verifica e inicializa componentes del sistema, luego según la configuración de la BIOS se ha de buscar algún
medio desde el cual arrancar un sistema operativo (floppy, CDROM, USB, Red, etc) cediendo el control a los primeros 512 bytes de
dicho medio donde se espera encontrar código ejecutable de un software llamado gestor de arranque.
El gestor de arranque es una pequeña aplicación que suele estar instalado en el sector de arranque de los discos (MBR) y tiene por
objetivo buscar y elegir un sistema operativo a iniciar en alguno de los medios de almacenamiento instalados. Este proceso de elección
del sistema operativo a arrancar puede hacerse de manera automática o de forma manual tras intervención del usuario.
Para aquellos usuarios que sólo han utilizado un único sistema operativo en su ordenador -comunmente alguna versión de Microsoft
Windows- el gestor de arranque es algo que definitivamente pudo haber pasado desapercibido, dado que esta aplicación no se suele
notar antes del arranque del sistema operativo.
Sin embargo para quienes ya han tenido la experiencia de instalar dos o más sistemas operativos en un único ordenador el gestor de
arranque ya se les habrá hecho notar como un menú de selección entre los sistemas operativos instalados.
Existen en la actualidad muchos gestores de arranque tal como NTLDR (NT Loader, típico de sistemas Microsoft), LILO, GRUB u otros,
pero sin embargo este último GRUB es en el que nos centraremos para estudiar su forma de uso y configuración.
GRUB Legacy
La versión más extendida de GRUB es la perteneciente a la rama 0.9x la cual ya ha sido reemplazada por la versión 2. A la rama
antigua se le suele llamar GRUB Legacy, y simplemente GRUB se le llama a la versión 2 reciente.
Sin embargo este manual ha de basar la documentación en la versión GRUB Legacy, por ser aún la más extendida entre instalaciones
de servidores estables en producción.
Es así que sobre GRUB Legacy es importante tener en cuenta las siguientes características:
• GRUB Legacy no marca diferencias entre discos IDE/ATA, SCSI, SATA o cualquier otro. A todos los nombra de la misma
manera.
• GRUB Legacy identifica los discos duros en el sistema como hdN donde N es el número de disco duro empezando por cero
(0 para el 1er. disco, 1 para el 2do. disco y así sucesivamente).
• Las particiones también son identificadas por un número pero siempre partiendo desde el cero (0 para la 1ra. partición, 3
para la 4ta. partición y así sucesivamente).
• GRUB Legacy entonces identifica una partición específica como (hdN,M) donde hdN representa el disco y M la partición.
GRUB Legacy centra su configuración en el archivo /boot/grub/menu.lst que sólo requiere modificar su contenido para que se hagan
efectivos los cambios a ser apreciados desde el próximo reinicio del sistema. La sintaxis de este archivo es como sigue:
# Directivas globales
directiva1 valor1
directiva2 valor2
...
...
Las directivas globales definen el comportamiento de GRUB Legacy de forma general tal como el tiempo de espera predeterminado, el
sistema operativo a arrancar por defecto, una contraseña de protección del gestor de arranque entre otras. Algunas de estas directivas
son:
Directiva Descripción
Define el sistema operativo por defecto a arrancar según las entradas definidas con la directiva title. La
default
numeración de entradas empieza desde cero aumentando verticalmente hacia abajo.
timeout Tiempo de espera máximo antes de arrancar el sistema operativo por defecto definido con la directiva default.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 150
Source Linux
Oculta el menú de selección de entradas de sistemas operativos a arrancar mientras avanza el tiempo de espera
hiddenmenu máximo. Presionando la tecla Esc se muestra el menú oculto. Un valor 1 oculta el menú, mientras que 0 no lo
oculta.
Protege con contraseña la edición de las entradas del gestor de arranque (presionando la tecla e). El password
password puede ser escrito en texto plano o cifrado en MD5 (generado con el comando grub-md5-crypt) especificando
antes la opción --md5
color Define una combinación de colores (de frente y fondo) a utilizar para el menú de GRUB Legacy.
Las directivas de sistemas operativos definen las entradas de acceso a uno o más sistemas operativos que pueden arrancar desde
GRUB Legacy permitiendo asignarles una etiqueta, ubicación del sistema operativo en el disco, protección con contraseña, etc.
Algunas de estas directivas son:
Directiva Descripción
title Define el nombre de la entrada del sistema operativo a arrancar.
root Selecciona la partición de disco desde la cual se supone ha de cargar el kernel para inicializar el sistema
operativo.
Define la ruta de la imagen del kernel (buscada en la partición previamente definida por la directiva root) así
kernel
como también los parámetros pasados a éste para cargar.
Define la ruta de la imagen initrd (buscada en la partición previamente definida por la directiva root) a ser
initrd
cargada después del kernel para lograr un arranque conjunto de ambos archivos.
rootnoverify Selecciona la partición -sin montarla- desde la cual iniciar un sistema operativo. Usado generalmente para
arrancar sistemas operativos Microsoft Windows.
Realiza un arranque en cadena especificando un archivo o el sector de la partición la ubicación de otro gestor de
chainloader arranque ya instalado. Usar un valor como +1 indica que se cederá el arranque en cadena al primer sector de la
partición seleccionada con la directiva root.
Permite proteger el acceso a una entrada con contraseña. El password puede ser escrito en texto plano o cifrado
password
en MD5 (generado con el comando grub-md5-crypt) especificando antes la opción --md5
Ejemplo 33:
a) Definir un archivo de configuración de GRUB Legacy que permita iniciar Windows XP instalado en /dev/sda1, y Debian Linux en
/dev/sda3 cuya partición /boot está en /dev/sda2. Debian Linux debe ser el sistema operativo predeterminado a arrancar.
timeout 10
default 0
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 151
Source Linux
title Windows XP
rootnoverify (hd0,0)
chainloader +1
b) Generar un password MD5 y con ése proteger el gestor de arranque GRUB Legacy:
# grub-md5-crypt
Password:
Retype password:
$1$tmcUK/$dbpSPkV5/57WPsu4r.8X6.
timeout 10
default 0
password --md5 $1$tmcUK/$dbpSPkV5/57WPsu4r.8X6.
title Windows XP
rootnoverify (hd0,0)
chainloader +1
Niveles de arranque
Los niveles de arranque o ejecución, conocidos también como runlevels, representan fases de inicialización en un sistema UNIX
basado en System V. Estos niveles permiten definir diferentes acciones a ejecutarse en cada uno como por ejemplo el modo
monousuario o multiusuario del sistema, los servicios a levantar en cada uno, el arranque de la interfaz gráfica o no, entre otros.
Por lo general los niveles de arranque estándar son el 0, S y 6, y el resto suele diferir entre un sistema operativo u otro. La siguiente
tabla resume los niveles de ejecución de un sistema Red Hat Linux y Debian GNU/Linux:
El comando init permite cambiar de un runlevel a otro y el comando runlevel nos informa del runlevel actual (derecha) y el previo
(izquierda). Por ejemplo las siguientes líneas nos cambiarían al modo monousuario, luego al multiusuario en modo texto, y luego
reiniciaría el sistema en Red Hat Linux:
# init 1
# runlevel
# init 3
# runlevel
# init 6
La interpretación de estos niveles de arranque en Linux está definida en el archivo /etc/iniittab el cual es leído por el proceso init una
vez que éste se ejecuta luego del arranque del kernel.
Este archivo está compuesto de líneas donde cada una tiene la sintaxis siguiente:
id:runlevels:acción:proceso
Donde:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 152
Source Linux
• id : Secuencia de caracteres que identifican las entradas.
• runlevels : Niveles de ejecución para los cuales se ejecuta la acción.
• acción : Describe qué acción debe ser tomada.
• proceso : Proceso a ejecutar.
Algunas de las acciones válidas a tomar definidas en /etc/inittab pueden ser:
Los runlevels especificados en /etc/inittab no significan mucho por sí mismos, sino más bien son las acciones que realizan en base a
una serie de scripts localizados en /etc y varios directorios dentro los que le dan significado real a los runlevels. Cuando Linux se inicia
se invocan una serie de scripts para configurar el sistema y cambiar entre los runlevels, aunque la técnica usada difiere entre las
distribuciones Linux.
A continuación se muestra una serie de archivos usados para el arranque en entornos Red Hat Linux y Debian GNU/Linux:
Los scripts de inicialización de /etc/init.d/ no son invocados directamente por el proceso init, sino que en su lugar los directorios
/etc/rc0.d, /etc/rc1.d, ..., /etc/rc6.d, contienen enlaces simbólicos que apuntan a los scripts del directorio /etc/init.d. Así cuando el proceso
init entra al runlevel N examina todos los archivos del directorio /etc/rcN.d.
• K,S : Son los prefijos para Kill y Start respectivamente. Los servicios detenidos invocan a los scripts S para iniciarlo sy
los ya iniciados invocan a los scripts K para apagarlos.
• N : Es el número de secuencia u orden en el que se inician.
• nombre : El nombre del servicio tal como httpd, smb u otros.
Esta herramienta invoca script si éste se encuentra como un fichero dentro de /etc/init.d y le pasa como argumento el comando que
puede ser algo como start, stop, restart, status, u otros dependiendo de los comandos que acepte el script. Adicionalmente podría
recibir una o más opciones luego del comando a ejecutar.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 153
Source Linux
chkconfig [opciones] <script> <on|off>
Configura la ejecución de scripts según runlevels
Opciones:
Esta herramienta invoca script si éste se encuentra como un fichero dentro de /etc/init.d y le pasa como argumento el comando que
puede ser algo como start, stop, restart, status, u otros dependiendo de los comandos que acepte el script. Adicionalmente podría
recibir una o más opciones luego del comando a ejecutar.
Opciones:
Esta herramienta requiere que se indique a través de NN el número de secuencia u orden en el cual se iniciará o apagará el servicio,
y además los runlevels son especificados cada uno separado de otro por un espacio en blanco, finalizando la definición siempre con
un símbolo punto (.).
Observaciones:
• Es posible invocar los scripts SysV sin depender de los comandos service o invoke-rc.d ejecutándolos directamente
usando su ruta absoluta o relativa. Ejm:
# /etc/init.d/httpd restart
# /etc/init.d/postfix stop
Ejemplo 34:
a) Desactivar el reinicio del sistema con la combinación de teclas Ctrl+Alt+Del. Esto lo hacemos editando /etc/inittab como sigue:
# init q
b) Configuramos el runlevel por defecto del sistema a 3. Esto lo hacemos editando /etc/inittab como sigue:
c) Configuramos en un sistema Red Hat Linux el servicio httpd para que se inicie sólo en los runlevels 3 y 5:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 154
Source Linux
d) Apagar el servicio httpd y desactivarlo de cualquier runlevel al arranque:
e) Configuramos en un sistema Debian GNU/Linux el servicio apache2 para que se inicie sólo en los runlevels 3 y 5:
Luego configuramos el arranque de apache2 con un número de secuencia 10 en los runlevels 3 y 5, y un número de secuencia 40
para el apagado en los runlevels restantes (0, 1, 2, 4 y 6):
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 155
Source Linux
9.4. Programación de tareas
Introducción
La programación de tareas para su ejecución automática es una función básica que poseen la mayoría de sistemas operativos
modernos. Linux posee dos formas distintas de programación de tareas; una de ellas es a través del demonio cron que permite
programar la ejecución periódica (repetitiva) de tareas, y la otra a través del demonio at que permite programar la ejecución
postergada de tareas de una única ejecución (no repetitiva). Ambas serán estudiadas a continuación:
El archivo /etc/crontab
La configuración centralizada del archivo /etc/crontab se hace siguiendo la sintaxis debajo mostrada:
# Sección variables
VAR1=valor
VAR2=valor
...
...
# Sección tareas
<Minuto> <Hora> <Día_del_mes> <Mes> <Día_de_la_semana> <Usuario> <Comando>
...
...
Donde:
• La sección variables, como su nombre lo dice, define variables con sus respectivos valores que serán usados en el ámbito de
ejecución de las tareas programadas. Algunas variables que comúnmente suelen definirse con HOME (directorio desde el
cual se ejecutan las tareas), SHELL (intérprete de órdenes usado para ejecutar las tareas), PATH y MAILTO (a quién se
enviará un correo reportando el resultado de las tareas ejecutadas).
• La sección tareas, define a través de entradas individuales (una por línea) las tareas a ejecutar en fechas y horas
específicas. Los campos que conforman estas entradas son:
Observaciones:
Los campos de fecha y hora ofrecen ciertas flexibilidades en su configuración como sigue:
30 8,13,18 * * 1 admin /bin/comando Ejecuta /bin/comando como el usuario admin todos los Lunes a las 08:30
am, 01:30 pm y 06:30 pm.
*/15 * 15,30 apr-dec fri admin /bin/comando Ejecuta /bin/comando como el usuario admin los días Viernes o en los
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 156
Source Linux
días 15 y 30 de cada mes entre Abril y Diciembre durante todo el día cada
15 minutos.
* 8-20/2 * * 1-5 root /usr/bin/comando Ejecuta /bin/comando como el usuario root de Lunes a Viernes cada 2
horas desde las 08:00 am hasta las 08:00 pm
0 9-13,15-19 * * 1,5 admin /usr/bin/comando Ejecuta /bin/comando como el usuario admin los días Lunes y Viernes
cada hora entre las 09:00 am y 01:00 pm y entre las 03:00 pm y 07:00 pm
crontab [opciones]
Edita los archivos cron personales
Opciones:
Esta herramienta utiliza el editor definido en la variable EDITOR. Una vez que terminamos de editar la(s) entrada(s) de programación
de tareas, guardamos los cambios y salimos del editor con lo que ya quedará lista nuestra tarea.
# Sección tareas
<Minuto> <Hora> <Día_del_mes> <Mes> <Día_de_la_semana> <Comando>
...
...
Como se notará, los campos son los mismos que el archivo /etc/crontab excepto la columna que especifica el usuario por razones
obvias.
Observaciones:
• La creación de archivos cron personales está controlada por los archivo /etc/cron.allow y /etc/cron.deny donde en cada uno de
ellos se puede definir los usuarios (uno por línea) que estarán permitidos o no de crear archivos cron.
Por ello en un entorno de servidor en producción se recomienda permitir la creación de archivos cron personales sólo al
usuario root a menos que de manera explícita otro usuario distinto requiera tal acceso.
• Cualquier cambio hecho a un archivo cron personal o el archivo /etc/crontab reflejará de manera inmediata las modificaciones
realizadas; no es necesario reiniciar el demonio cron (/etc/init.d/cron o /etc/init.d/crond).
at [opciones] <TIEMPO>
Programa la ejecución de tareas
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 157
Source Linux
La fecha y hora de ejecución es definida a través de TIEMPO que puede ser especificada de diversas formas como:
• Definiendo la hora y minutos exactos como HH:MM, llevando opcionalmente los sufijos AM o PM para formato de 12 horas.
• Definiendo una palabra que identifica una hora como noon (12:00 horas), midnight (00:00 horas) o teatime (16:00 horas)
• Definiendo la fecha como "MES DIA" donde MES puede ser Aug, Oct, Jan, etc. y DIA un valor entre 0 y 31.
• Definiendo la fecha como MMDDYY, MM/DD/YY o DD.MM.YY, donde DD es el día del mes, MM el mes del año y YY el año.
• Definiendo la fecha y hora como "HORA FECHA", usando HORA y FECHA formatos líneas arriba definidos.
• Definiendo la fecha y hora como "FECHA/HORA + INCREMENTO", donde INCREMENTO está conformado por un valor
numérico y un sufijo de tiempo (minutes, hours, days, weeks, etc).
Esta herramienta tras ser invocada con un formato de TIEMPO lleva al usuario a una shell en la cual se pueden ingresar los
comandos que se desean ejecutar, uno por línea tras presionar la tecla Enter, y cuando finalicemos presionamos ^D para salir de la
shell y dejar encolada la ejecución programada de la tarea.
Observaciones:
• La programación de tareas con at controlada por los archivo /etc/at.allow y /etc/at.deny donde en cada uno de ellos se puede
definir los usuarios (uno por línea) que estarán permitidos o no de usar este servicio.
Por ello en un entorno de servidor en producción se recomienda permitir la programación de tareas con at sólo al usuario
root a menos que de manera explícita otro usuario distinto requiera tal acceso.
Ejemplo 35:
a) Programar el reinicio del servicio postfix cada 3 horas durante los días de semana. Esto lo logramos agregando la siguiente
entrada a /etc/crontab:
c) Bajo una sesión del usuario admin, crear una tarea programada personal con cron que genere un backup de su directorio personal
dentro de /var/backups los días 1ro. de cada mes a las 02:15 AM:
$ crontab -e
d) Bajo una sesión del usuario root, ejecutar el apagado del sistema el 15 de Diciembre del 2009 a las 17:30 horas. Asumir 01 de
Diciembre como la fecha de hoy, y las 10:30 AM como hora vigente.
# at 17:30 Dec 15
> shutdown -h now
# at 17:30 + 13 days
> shutdown -h now
# at 17:30 + 13 days
> shutdown -h now
# at Dec 15 + 7 hours
> shutdown -h now
# at 17:30 15.12.2009
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 158
Source Linux
> shutdown -h now
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 159
Source Linux
9.5. Logs del sistema
El demonio syslog
En todo sistema UNIX es típico que las aplicaciones instaladas posean siempre cierta capacidad de generar registros (logs) de su
funcionamiento, ya sea a través de una escritura directa en algún archivo y directorio del sistema (por lo general debajo de /var/log) o a
través de la comunicación con un demonio de logs, llamado Syslog.
Syslog es un estándar de facto como demonio de registros para sistemas UNIX, teniendo varias implementaciones de software tales
como sysklogd, rsyslog y syslog-ng.
La documentación de este apartado se basará en sysklogd que es el que vino siendo usado por la mayoría de distribuciones Linux
durante el transcurso de los años.
Para comprender la configuración del demonio syslog es importante conocer los términos siguientes:
Facility Descripción
authpriv Mensajes de seguridad o autorización.
cron Mensajes de los demonios cron y at.
daemon Mensajes de demonios independientes del sistema.
ftp Mensajes de demonios ftp.
kern Mensajes del kernel.
local0 a local7 Mensajes reservados para uso local.
lpr Mensajes del sistema de impresión.
mail Mensajes de correo.
news Mensajes de news.
syslog Mensajes generados internamente por el demonio syslog.
user Mensajes genéricos de nivel de usuario.
uucp Mensajes de UUCP.
Priority Descripción
emerg Sistema inutilizable.
alert Debe tomarse una acción correctiva inmediatamente.
crit Condiciones críticas.
err Condición de error.
warning Condiciones de advertencia.
notice Condición normal pero significativa.
info Mensaje informativo.
debug Mensaje de nivel de depuración.
El archivo /etc/syslog.conf
El demonio syslog centra su configuración en el archivo /etc/syslog.conf el mismo que consta de está conformado por varias entradas
conformadas por un selector y una acción.
Cada entrada dentro del archivo se especifica como sigue:
selector acción
El selector define la naturaleza del mensaje a registrar (quién lo origina y qué prioridad tiene) y la acción define qué hacer con esos
mensajes (guardarlos en un archivo, mandarlo a otro demonio syslog en la red, enviarlo a un usuario, etc).
El detalle de la sintaxis y reglas que siguen los selectores y acciones se detalla debajo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 160
Source Linux
Sobre los selectores:
• Es posible especificar varios selectores para una acción, separando cada selector por el símbolo punto y coma (;).
• El selector está conformado por uno o más facilities -separados por comas- y priorities -también separados por comas. Los
facilities se separan de los priorities por un punto (.)
• Por defecto todos los mensajes que tenga una prioridad igual o mayor a la especificada en un selector serán guardados
según la acción definida en su respectiva entrada de /etc/syslog.conf.
• Si se desea filtrar sólo una prioridad específica y no ninguna superior (comportamiento por defecto), entonces se debe
colocar el símbolo igual (=) antes del priority.
• Se puede utilizar el símbolo asterisco para expresar todos los facilities o todos los priorities según se coloque este símbolo
antes o luego del punto (.) en un selector.
• Archivo regular : Los mensajes se guardan en un archivo cuya ruta completa (empezando con /) debe ser especificada. Si
antes de la ruta del archivo se coloca el símbolo guión (-) entonces se omitirá la sincronización del archivo tras cada
escritura de registro, lo cual podría traer una pérdida parcial de datos ante un corte eléctrico por ejemplo pero permite
obtener mejor rendimiento cuando se va a escribir muchos registros de manera intensa en este archivo.
• Terminal y consola : Se puede indicar la ruta de un dispositivo tty u otro dispositivo de terminal donde se mostrarán los
mensajes.
• Equipo remoto : Se puede enviar los mensajes a otro host (corriendo el demonio syslog) a través de la red. Para eso el host
destino debe ser indicado luego del símbolo @ y dicho host debe estar preparado para aceptar logs desde la red.
• Lista de usuarios : Se envía a la pantalla del usuario logueado al sistema el mensaje de registro. Se pueden indicar uno o
más usuarios cada uno separado por comas.
• Las implementaciones de demonios syslog tienen la posibilidad de funcionar de modo tal que estén a la escucha de recibir
mensajes desde la red (puerto UDP 514)de hosts remotos. En implementaciones como sysklogd o rsyslog es necesario
pasar el parámetro -r al arranque de estos demonios para habilitar esta funcionalidad de escucha en red.
La herramienta logger
El comando logger funciona como una interfaz de comunicación con el demonio syslog para enviarle a él mensajes de registro en una
facility y priority determinadas. Es útil para generar logs de forma manual como parte de alguna otra aplicación tal como un script
escrito en BASH o Perl.
La sintaxis de uso de esta herramienta se muestra debajo:
Opciones:
Los facilities y priorities válidos a usar son los mismos que se documentaron líneas arriba.
Ejemplo 36:
a) Crear una configuración en el demonio syslog de modo tal que los mensajes de facilities mail, cron y kern con prioridad igual o
mayor a warn sean enviados al archivo /var/log/mensajes. Considérese que los mensajes generados en este archivo serán abundantes
y debe procurar optimizar el rendimiento del demonio syslog.
mail,cron,kern.warning -/var/log/mensajes
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 161
Source Linux
b) Hacer efectivos los cambios anteriores y probar su correcta configuración.
# /etc/init.d/sysklogd restart
Generamos mensajes de prueba para syslog y analizamos el contenido del archivo /var/log/mensajes:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 162
Source Linux
9.6. Shell scripting básico
Shell scripting en BASH
La correcta administración de un sistema UNIX requiere un sólido entendimiento de los componentes del sistema operativo, las
herramientas que lo administran y poseer la habilidad de usar eficientemente estas herramientas a nuestro alcance de manera
conjunta.
Esta última habilidad mencionada no podría ser llevada a niveles considerables sin un conocimiento de programación de scripts de
shell, los que tienen por objetivo automatizar muchas de nuestras tareas de administración haciéndolas realmente fáciles y rápidas.
Esto sumado al hecho que BASH es la shell más usada en las distribuciones Linux nos lleva a la necesidad de elegir a esta shell como
la preferida para la programación de nuestros scripts.
Es así que si deseamos perfilar a convertirnos en un buen administrador de sistemas UNIX es necesario desenvolvernos sin problemas
con BASH scripting e ir preparando habilidades de scripting en Perl.
#!/bin/bash
# script1.sh
FECHA=$(date)
echo "Hola este es mi primer script"
echo "La fecha y hora actual es: $FECHA"
Tras guardar los cambios en el archivo, procederemos a darle permisos de ejecución e invocarlo desde la shell:
$ chmod +x script1.sh
$ ./script1.sh
Es recomendable dar permiso de ejecución a nuestros scripts, pero no indispensable pues aún sin dicho permiso podríamos ejecutarlo
del siguiente modo:
$ bash script1.sh
1. Ejecución de scripts en el entorno actual de shell : Esto permite cargar las variables o funciones de scripts en nuestra shell
actual como si se tratasen de variables locales. No ejecuta un proceso hijo para la shell invocada.
Este tipo de ejecución se hace de una de las dos formas siguientes:
$ source /ruta/del/script.sh
$ . /ruta/del/script.sh
2. Ejecución de scripts en un nuevo entorno de shell : Esto crea una nueva shell para la ejecución del script en entorno distinto
y propio. Se ejecuta como un proceso hijo y no permite acceder a variables o funciones en el script desde nuestra shell
actual.
Este tipo de ejecución se hace de una de las dos formas siguientes:
$ bash /ruta/del/script.sh
$ /ruta/del/script.sh
Considérese que esta última forma de invocar al script requiere que éste tenga permiso de ejecución.
Funciones en BASH
Las funciones se definen con la palabra clave function seguido del nombre de la función y entre llaves encerradas las sentencias
que conforman la función. También es posible definir la función con tan sólo escribir el nombre de la misma seguida de ( ) y luego las
sentencias encerradas entre llaves.
Una vez definidas las funciones podemos invocarlas desde cualquier parte del script con tan sólo escribir sus nombres y parámetros
opcionales como si se tratase de ejecutar cualquier otra sentencia o comando de shell.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 163
Source Linux
Ejemplos de funciones:
#!/bin/bash
function suma {
echo $(( $1 + $2 ))
}
resta( ) {
echo $(( $1 - $2 ))
}
suma 10 20
resta 20 7
#!/bin/bash
echo "Ingrese su edad: "
read EDAD
echo "Ud. ingreso $EDAD como edad"
Expresiones condicionales
Las expresiones condicionales son usadas para evaluar atributos de ficheros, comparaciones aritméticas y de cadena. Algunos de
estos operadores son:
Operadores Descripción
-e FILE Verdadero si el fichero FILE existe.
-d FILE Verdadero si el fichero FILE existe y es un directorio.
-f FILE Verdadero si el fichero FILE existe y es un archivo regular.
-r FILE Verdadero si el fichero FILE existe y tiene permiso de lectura.
-w FILE Verdadero si el fichero FILE existe y tiene permiso de escritura.
-x FILE Verdadero si el fichero FILE existe y tiene permiso de ejecución.
FILE1 -nt FILE2 Verdadero si el fichero FILE1 es más nuevo (respecto a la fecha de modificación) que FILE2.
FILE1 -ot FILE2 Verdadero si el fichero FILE1 es más antiguo (respecto a la fecha de modificación) que FILE2.
-z CADENA Verdadero si el texto CADENA tiene longitud cero.
-n CADENA Verdadero si el texto CADENA tiene longitud mayor que cero.
CAD1 == CAD2 Verdadero si las cadenas CAD1 y CAD2 son iguales.
CAD1 < CAD2 Verdadero si las cadenas CAD1 está alfabéticamente antes que CAD2.
CAD1 > CAD2 Verdadero si las cadenas CAD1 está alfabéticamente después que CAD2.
NUM1 -eq NUM2 Verdadero si los números NUM1 y NUM2 son iguales.
NUM1 -ne NUM2 Verdadero si los números NUM1 y NUM2 no son iguales.
NUM1 -lt NUM2 Verdadero si el número NUM1 es menor que el número NUM2.
NUM1 -le NUM2 Verdadero si el número NUM1 es menor o igual que el número NUM2.
NUM1 -gt NUM2 Verdadero si el número NUM1 es mayor que el número NUM2.
NUM1 -ge NUM2 Verdadero si el número NUM1 es mayor o igual que el número NUM2.
! Antecedido a cualquier evaluación de operadores niega su resultado.
La forma de utilizar estos operadores es a través del operador [ ] o el comando test como sigue:
$ [ expresión ]
$ test expresión
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 164
Source Linux
Si la expresión evaluada es verdadera entonces el código de estado retornado es 0, de lo contrario es 1. Debemos recordar que dicho
código de estado puede ser conocido consultando el valor de $?
Sentencias de control: if, then, elif, else
La sentencia if evalúa una expresión y si ésta es cierta podrá ejecutar una o más sentencias de comandos. A través del siguiente
ejemplo nótese su forma de uso:
#!/bin/bash
if [ "$1" -gt 10 ]
then
echo "El numero $1 es mayor que 10"
elif [ "$1" -eq 10 ]
then
echo "El numero $1 es igual a 10"
else
echo "El numero $1 es menor que 10"
fi
#!/bin/bash
NUM=1
while [ $NUM -le 10 ]
do
echo $NUM
NUM=$(($NUM+1))
done
#!/bin/bash
cd /
for i in *
do
echo "Fichero: $i"
done
IFS=":"
echo "Directorios que conforman el PATH"
for dir in $PATH
do
echo "Directorio: $dir"
done
#!/bin/bash
case $1 in
start)
service httpd start
;;
stop)
service httpd stop
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 165
Source Linux
;;
restart)
service httpd restart
;;
*)
echo "Uso: $(basename $0) start|stop|restart" > /dev/stderr
;;
esac
Un resumen de los archivos que se cargan al inicio de una sesión se muestra a continuación:
Archivo Descripción
Contiene configuraciones generales para todos los usuarios. Es ejecutado al inicio de sesión de cada usuario.
/etc/profile
Sólo root puede modificar este archivo.
Archivo personal de usuario que carga sus preferencias. BASH no ejecuta este archivo si ya existe ~/bash_login o
~/.profile
~/.bash_profile. Se carga en cada inicio de sesión del usuario.
~/.bash_profile Archivo personal de usuario que carga sus preferencias. Se carga en cada inicio de sesión del usuario.
Ejecutado por cada usuario cada vez que invoca a una shell BASH. Considérese que en una sesión activa el usuario
~/.bashrc
puede invocar muchas veces a una shell, tantas como ventanas de terminal ejecute.
~/.bash_logout Archivo de preferencias personales de usuario a ejecutarse al cierre de sesión.
✔ Alias de comandos.
✔ Variables de entorno personalizadas.
✔ Valor de umask que definirá los permisos por defecto de nuevos archivos y directorios.
✔ Definir propiedades del historial de comandos, tal como el tamaño, ruta del archivo o simplemente desactivarlo.
✔ Directorios de búsqueda de binarios para configurar un PATH propio.
✔ Entre otros...
Ejemplo 37:
a) Configurar el perfil de usuario de modo tal que los archivos creados siempre tengan permisos 600 y los directorios 700 por defecto.
Asimismo configuramos parámetros por defecto para el comando grep y ls:
umask 077
alias ls='ls --color'
alias grep='ls –color'
b) Listar la ruta absoluta en la que se encuentran cada uno de los módulos actualmente cargados en el sistema.
#!/bin/bash
lsmod | awk '{ print $1 }' |
while read modulo
do
modinfo -n $modulo
done
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 166
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 167
Source Linux
9.7. Laboratorio N° 9
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Identificar a todos los usuarios que tienen una shell válida en el sistema (/bin/bash o /bin/sh) y deshabilitarle a cada uno
de ellos la posibilidad de programar tareas con cron o at y también colocarle /bin/false como shell. . No aplicar esta
restricción al usuario root.
2. Generar una tarea que se ejecute entre Lunes y Viernes a las 22:00 horas que se encargue de generar un reporte del uso de
espacio en el directorio personal de cada uno de ellos. El reporte debe ser enviado por correo al usuario root.
Cada línea del reporte debe tener la forma "USUARIO TAMAÑO".
3. Configurar en un sistema Debian que el servicio vsftpd sea iniciado sólo en los niveles 2 y 3, mientras que en el resto de
niveles debería ser apagado dicho servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 168
Source Linux
9.7.1. Solución del laboratorio N° 9
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Identificar a todos los usuarios que tienen una shell válida en el sistema (/bin/bash o /bin/sh) y deshabilitarle a cada uno de
ellos la posibilidad de programar tareas con cron o at y también colocarle /bin/false como shell. No aplicar esta restricción al
usuario root.
#!/bin/bash
# script1.sh
#
# Filtramos con grep los usuarios que tienen una shell como /bin/*sh y
# obtenemos de cada línea sólo la primera columna
grep '\/bin\/.*sh$' /etc/passwd | cut -d : -f 1 |
while read usuario
do
# Cada usuario lo agregamos a la denegación de cron y at
echo $usuario >> /etc/cron.deny
echo $usuario >> /etc/at.deny
# Cambiamos la shell del usuario
usermod -s /bin/false $usuario
done
# chmod +x script1.sh
# ./script1.sh
2. Generar una tarea que se ejecute entre Lunes y Viernes a las 22:00 horas que se encargue de generar un reporte del uso de
espacio en el directorio personal de cada uno de ellos. El reporte debe ser enviado por correo al usuario root.
Cada línea del reporte debe tener la forma "USUARIO TAMAÑO".
#!/bin/bash
# script2.sh
#
# Creamos un archivo temporal
file=$(mktemp)
du -sh /home/* |
while read size home
do
user=$(echo $home | cut -d / -f 3)
echo "$user $size" >> $file
done
# chmod +x script2.sh
# ./script2.sh
3. Configurar en un sistema Debian que el servicio vsftpd sea iniciado sólo en los niveles 2 y 3, mientras que en el resto de
niveles debería ser apagado dicho servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 169
Source Linux
Unidad 10: Administración de red
10.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Configurar correctamente los parámetros de red de un sistema Red Hat Linux y Debian GNU/Linux.
✔ Saber manejar sin problemas las herramientas de configuración y consulta de parámetros de red.
✔ Desenvolverse en el manejo de utilitarios de red para la ejecución de tareas rutinarias y de diagnóstico.
✔ Manejar aplicaciones de conexión remota gráfica para sistemas Linux y Windows.
Estas configuraciones de red tienen por objetivo simplificar la asignación de parámetros de red de forma persistente entre cada reinicio
del sistema. Se hace esta mención pues existen herramientas de línea de comandos estándar para todas las distribuciones que se
encargan de asignar los parámetros de red pero éstas no aplican los cambios de modo tal que se mantengan aún luego de reiniciar el
equipo.
Por ello nos centraremos en algunos archivos de configuración específicos para cada función según lo mencionemos líneas abajo.
search dominio
nameserver host1
nameserver host2
...
...
Donde:
• search : Define el dominio por defecto en el cual se buscarán los nombres de host en cada consulta DNS.
• nameserver : Define la dirección IP o nombre de un servidor DNS, uno por línea. E
La configuración de este archivo es igual en cualquier distribución Linux, por lo que es aplicable tanto para Red Hat como para Debian
GNU/Linux y sus derivados.
El orden vertical (de arriba hacia abajo) de los servidores DNS definidos con la directiva nameserver define el orden de preferencia
para consultas.
Normalmente podemos definir hosts en este archivo cuando no existe un nombre DNS asociado a uno o más equipos particulares, o
simplemente podemos preferir utilizar estas asociaciones manuales sólo por comodidad personal.
Donde:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 170
Source Linux
• alias : Define uno o más nombres alternos equivalentes para dicho host.
La configuración de este archivo es igual en cualquier distribución Linux, por lo que es aplicable tanto para Red Hat como para Debian
GNU/Linux y sus derivados.
El archivo /etc/sysconfig/network
Este archivo es utilizado para especificar parámetros básicos de configuración de red que no están asociados a una interfaz específica.
Dentro de este archivo se admiten las siguientes directivas:
• NETWORKING=<valor> : A través de un valor yes o no se decide si la red debería ser configurada en el sistema.
• HOSTNAME=<valor> : Se define a través de valor el valor del nombre de host del equipo.
• GATEWAY=<valor> : Se define a través de valor la dirección IP del gateway por defecto del sistema.
• GATEWAYDEV=<valor> : Se define a través de valor por qué interfaz de red se accede al gateway por defecto.
Los archivos de configuración para interfaces de red Ethernet (ifcfg-eth*) pueden admitir las siguientes directivas:
• BOOTPROTO=<valor> : Donde valor es bootp (se usa BOOTP), dhcp (se usa DHCP) o none (no se usa protocolo de
arranque para su configuración).
• DEVICE=<valor> : Define a través de valor el nombre de la interfaz de red.
• IPADDR=<valor> : Define a través de valor la dirección IP de la interfaz.
• NETMASK=<valor> : Define a través de valor la máscara de red.
• NETWORK=<valor> : Define a través de valor la dirección de red.
• BROADCAST=<valor> : Define a través de valor la dirección de broadcast.
• ONBOOT=<valor> : Define a través de valor (yes o no) si la interfaz se activará al arranque del sistema.
• USERCTL=<valor> : Define a través de valor (true o false) si la interfaz puede ser configurada por usuarios
distintos de root.
• HWADDR=<valor> : Identifica a la interfaz de red por la dirección MAC que posee según valor.
Para crear alias es necesario luego del nombre de la interfaz de red el símbolo dos puntos (:) y luego un identificador tal como
eth0:0, eth0:1. Los alias permiten asignar múltiples direcciones IP a una única interfaz de red física.
# /etc/init.d/network stop
# service network start
Adicionalmente las herramientas ifup e ifdown permiten manipular interfaces de red específicas para activarlas o desactivarlas sin
afectar el resto de la configuración de otras interfaces existentes en el sistema.
# ifdown eth0
Para activar nuevamente una interfaz de red utilizaríamos ifup como sigue:
# ifup eth0
Es necesario tener presente que estas herramientas ifup e ifdown sólo pueden manipular interfaces de red con una configuración ya
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 171
Source Linux
definida a través de los archivos /etc/sysconfig/network-scripts/ifcfg-*
Finalmente es importante mencionar que Red Hat provee una herramienta de configuración intuitiva que entre otras cosas hace posible
la configuración de la red haciendo uso de menús sencillos de entender. Esta herramienta se invoca con el comando setup.
El archivo /etc/hostname
Este archivo es utilizado para definir en él el nombre de host del sistema, sin contener un dominio como parte de él (no FQDN).
El archivo /etc/network/interfaces
Dentro de este archivo se define la configuración de todas las interfaces de red y el gateway por defecto del sistema. La sintaxis de
este archivo es como sigue:
auto <interfaz0>
iface <interfaz0> inet <static|dhcp>
[address <dirección ip>]
[netmask <máscara de red>]
[broadcast <dirección de broadcast>]
[network <dirección de red>]
[gateway <dirección ip gateway>]
auto <interfaz1>
iface <interfaz1> inet <static|dhcp>
[address <dirección ip>]
[netmask <máscara de red>]
[broadcast <dirección de broadcast>]
[network <dirección de red>]
[gateway <dirección ip gateway>]
auto <interfaz2>
...
...
Donde:
• interfaz : Define el nombre de la interfaz de red como eth0, eth1, eth0:0, etc.
• static|dhcp : Definen el modo de configuración de la interfaz como dhcp (dinámico) o static (estático).
• address : Define la dirección IP de la interfaz.
• netmask : Define máscara de red de la interfaz.
• broadcast : Define la dirección IP de broadcast de la interfaz.
• network : Define la dirección IP de red de la interfaz.
• gateway : Define el gateway por defecto del sistema.
Para crear alias es necesario luego del nombre de la interfaz de red el símbolo dos puntos (:) y luego un identificador tal como
eth0:0, eth0:1. Los alias permiten asignar múltiples direcciones IP a una única interfaz de red física.
# /etc/init.d/networking stop
# invoke-rc.d networking start
Adicionalmente las herramientas ifup e ifdown permiten manipular interfaces de red específicas para activarlas o desactivarlas sin
afectar el resto de la configuración de otras interfaces existentes en el sistema.
# ifdown eth0
Para activar nuevamente una interfaz de red utilizaríamos ifup como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 172
Source Linux
# ifup eth0
Es necesario tener presente que estas herramientas ifup e ifdown sólo pueden manipular interfaces de red con una configuración ya
definida a través del archivo /etc/network/interfaces.
10.3. Utilitarios de red
En esta sección estudiaremos una serie de herramientas de manipulación de parámetros de red, consulta, diagnóstico, conexión y
copia remota segura que deben ser conocidas por todo administrador de sistemas operativos Linux.
Opciones:
-a : Muestra todas las interfaces de red del sistema, incluso aquellas desactivadas.
-s : Muestra una breve estadística de las interfaces.
Argumentos:
up : Activa la interfaz.
down : Desactiva la interfaz.
[-]arp : Activa o desactiva el uso de ARP en la interfaz.
[-]promisc : Activa o desactiva el modo promiscuo en la interfaz.
metric N : Asigna la métrica N a la interfaz.
mtu N : Asigna el MTU N a la interfaz.
[-]pointopoint DIR : Define la dirección destino DIR para conexiones Punto a Punto (como PPP).
netmask DIR : Define la máscara de red según DIR.
[-]broadcast DIR : Define la dirección de broadcast según DIR.
hw CLASE DIR : Define la dirección de hardware según DIR y la CLASE soportada por el driver.
Esta herramienta ejecutada sin parámetros muestra la información de las interfaces de red activas. Las clases de hardware disponible
para interfaces de red son ether (Ethernet), ax25 (AMPR X.25), ARCnet y netrom (AMPR NET/ROM).
Opciones:
Argumentos:
speed VEL : Define la velocidad VEL de la interfaz (10, 100, 1000 ó 2500)
duplex half|full : Define el modo half o full duplex.
autoneg on|off : Activa o desactiva el autonegociado.
Esta herramienta ejecutada sin parámetros muestra la información de una interfaces de red específica, indicando incluso si ésta tiene
conectividad física o no.
Ejemplo 38:
a) Mostrar información de las interfaces de red activas y luego mostrar sólo la de eth0:
# ifconfig
# ifconfig eth0
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 173
Source Linux
b) Asignarle una dirección IP y máscara a la interfaz eth0 según 192.168.32.4/255.255.255.0. Luego desactivar esa interfaz.
c) Verificar que dicha interfaz eth0 sea visible con el parámetro -a de ifconfig, luego cambiarle la dirección MAC a un valor distinto al
actual y levantar nuevamente la interfaz de red.
# ifconfig -a
# ifconfig eth0 hw ether 00:34:11:B4:9E:FD
d) Consultar la información de eth0 para conocer qué driver usa, la velocidad a la que actualmente trabaja y si tiene o no conexión
física a la red.
# ethtool -i eth0
# ethtool eth0
route [opciones]
route <argumentos> <destino>
Manipula la tabla de enrutamiento del sistema
Opciones:
Argumentos:
Esta herramienta ejecutada sin parámetros muestra la tabla de enrutamiento principal del sistema.
Opciones:
-f TTL : Define el tiempo de vida en un valor TTL en lugar del predeterminado que es 1.
-n : Muestra la información de hosts en modo numérico, no resuelve a sus nombres.
-i IFACE : Utiliza la interfaz IFACE para enviar los paquetes a través de él.
Opciones:
Ejemplo 39:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 174
Source Linux
# route -n
b) Agregar una ruta para llegar a la red 172.16.34.0/24 a través del host 172.31.0.1:
c) Hacer un trazado de rutas hacia algún host de la red hacia la cual agregamos una ruta recientemente; reforzamos nuestras pruebas
de conectividad y rendimiento con 3 peticiones ECHO de ping:
# traceroute 172.16.34.39
# ping -c 3 172.16.34.39
netstat [opciones]
Informa sobre las conexiones activas del sistema
Opciones:
Opciones:
La herramienta telnet fue desarrollada como un cliente de shell remoto para el acceso a otros hosts en la red. En la actualidad dada
la inseguridad de esta aplicación la usaremos sólo para evaluar la conectividad hacia un puerto específico de un host.
Ejemplo 40:
# netstat -tnl
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 175
Source Linux
b) Comparar los resultados de nuestras conexiones activas del ejercicio anterior contra un escaneo de puertos local:
c) Comprobar que los puertos TCP estén realmente en escucha haciendo un telnet a cada uno de ellos:
# telnet localhost 22
# telnet localhost 80
d) Mostrar todas las conexiones TCP y UDP activas, mostrando información detallada y el proceso que las origina:
# netstat -tunape
Opciones:
Esta herramienta por defecto utiliza los servidores DNS definidos en /etc/resolv.conf para realizar las consultas DNS, pero se le puede
indicar como argumento final el nombre de otro servidor DNS distinto al cual dirigir dichas consultas.
Opciones:
Expresiones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 176
Source Linux
Las expresiones son filtros para limitar la cantidad de información mostrada por la herramienta. Estas expresiones pueden ser
agrupadas con paréntesis de manera similar a las operaciones matemáticas.
iptraf [opciones]
Herramienta de monitoreo de redes LAN
Opciones:
-i IFACE : Inicia la herramienta en modo monitor de tráfico IP escuchando por la interfaz IFACE
-d IFACE : Inicia la herramienta en modo detalle estadístico de la interfaz IFACE
-s IFACE : Inicia la herramienta en modo monitor de tráfico TCP y UDP escuchando por la interfaz IFACE
-l IFACE : Inicia la herramienta en modo monitor de LAN escuchando por la interfaz IFACE
-z IFACE : Inicia la herramienta en modo contador de paquetes por tamaño escuchando por la interfaz IFACE
Ejemplo 40:
b) Analizar sólo el tráfico generado desde el host 190.41.72.1 que sea TCP del puerto 80:
# tcpdump -ni eth0 src host 190.41.72.1 and port 80 and tcp
c) Analizar sólo el tráfico que atraviesa nuestra interfaz eth0 excepto las conexiones SSH, HTTP y HTTPS:
Opciones:
Por defecto la herramienta intenta conectarse al host remoto con el nombre del usuario que actualmente tenemos activo en nuestra
sesión, a menos que se especifique algo distinto con la opción -l o usando la sintaxis user@host en la línea de comandos.
El reenvío X permite poder conectarnos a otro host vía línea de comandos con SSH y desde ahí invocar la ejecución de un comando
que levante una aplicación gráfica (Ejm: Mozilla Firefox) cuya ventana no sea abierta en el host remoto sino en nuestra propia
pantalla. Esto sólo es válido cuando nos conectamos desde un sistema con Linux, aunque desde Windows también sería posible con
la previa instalación del software Xming.
ssh-keygen [opciones]
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 177
Source Linux
Herramienta de manejo de llaves SSH
Opciones:
-t TIPO : Crea una llave privada con el TIPO indicado. Los tipos válidos son rsa1 (sólo SSH v1), rsa y dsa (SSH v2).
-f FILE : Invoca al archivo FILE como la llave privada.
-p : Ordena el cambio de clave de una llave privada en vez de crear una nueva.
-R HOST : Remueve cualquier coincidencia de HOST en el archivo known_hosts (hosts conocidos)
El procedimiento de manejo de llaves privadas para las conexiones SSH consiste en lo siguiente:
1. Generar un par de llaves, privada y pública, donde se recomienda muy encarecidamente proteger con contraseña la llave
privada.
$ ssh-keygen -t rsa
Tras ingresar una contraseña dos veces, se debe haber creado un par de archivos de nombre id_rsa e id_rsa.pub dentro del
directorio ~/.ssh, donde el primero representa la llave privada y el segundo la llave pública.
2. La llave pública de dicho par debe permanecer en el host al cual nos deseamos conectar. Esta llave pública debería
guardarse con el nombre authorized_keys dentro del directorio .ssh ubicado en el directorio personal del usuario con el cual
deseamos conectarnos.
Asumiendo que deseamos conectarnos con las credenciales del usuario root a este host, entonces en él colocaremos la llave
pública con el nombre /root/.ssh/authorized_keys.
3. La llave privada de dicho par debe ser mantenida con mucho recelo y cuidado sólo por el usuario que pretende conectarse al
host remoto usando dicha llave. Si la llave privada permanece dentro del directorio personal de nuestro usuario con el
nombre ~/.ssh/id_rsa entonces sólo nos bastará conectarnos al host remoto de esta manera:
$ ssh root@host-remoto
Por defecto el comando ssh busca la llave privada en esa ubicación con ese nombre, pero en caso de no encontrarla como
tal será necesario entonces indicarle manualmente la ruta del archivo de al llave privada como sigue:
PasswordAuthentication No
UsePAM No
Como recomendaciones adicionales de seguridad puede ser recomendable cambiar el puerto de escucha por defecto del 22 a otro
valor distinto, deshabilitar el acceso de root por SSH e incluso limitar qué usuarios serán los permitidos a conectarse vía SSH con las
siguientes directivas:
#Port 22
Port 481
#PermitRootLogin Yes
PermitRootLogin No
Si se opta por seguir las recomendaciones arriba mostradas (PermitRootLogin No) hay que tener entonces en cuenta que
tendremos que colocar la llave pública ~/.ssh/authorized_keys ya no en el directorio personal del usuario root sino en uno de los usuarios
permitidos a conectarse (según la directiva AllowUsers).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 178
Source Linux
scp [opciones] [usuario@host]:<archivo/directorio>
Copia segura de archivos en red
Opciones:
Al igual que el comando ssh, por defecto la herramienta intenta conectarse al host remoto con el nombre del usuario que actualmente
tenemos activo en nuestra sesión, a menos que se especifique algo distinto con la opción usando la sintaxis user@host en la línea de
comandos.
Ejemplo 41:
a) Conectarnos al host remoto 172.31.0.1 con las credenciales del usuario root y un archivo de llave privada ~/llave.ssh:
b) Copiar el directorio ~sergio/notas del host 192.168.10.32 hacia un directorio de nombre ~/temporal en nuestro equipo:
• Tener acceso vía SSH a un equipo UNIX con una o más aplicaciones gráficas instaladas.
• Verificar que el servidor SSH de aquel host UNIX tenga habilitado el reenvío X11, para lo cual debemos asegurarnos de
encontrar una directiva como X11Forwarding Yes en el archivo /etc/ssh/sshd_config.
• Conectarnos a aquel host UNIX vía SSH desde un equipo donde tengamos en ejecución algún servidor gráfico X11. Si nos
conectamos desde un equipo Linux con entorno gráfico en ejecución damos por hecho este requerimiento, sin embargo en la
plataforma Windows -que no tiene servidor X11- se requerirá primero instalarle uno como Xming
(http://sourceforge.net/projects/xming/)
• En el momento de conectarnos debemos indicar a nuestro cliente SSH que active el reenvío X11. Desde la línea de
comandos Linux lo hacemos con el parámetro -x del comando ssh; sin embargo en Windows podemos encontrar dicha
opción también a través de las secciones de configuración de un cliente como el PuTTY.
• Una vez conectados a una shell vía SSH con el reenvío X11 activo, simplemente procederemos a ejecutar en el host remoto
cualquier comando que lance una aplicación gráfica. Ejemplo:
$ firefox &
Par ambos casos se requiere tener instalado una versión de servidor VNC. Así que procederemos a instalar uno:
La configuración de XDMCP con VNC requiere configurarlo con el demonio xinetd, para lo cual crearemos la siguiente configuración al
final del archivo /etc/services:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 179
Source Linux
vnc-1024x768 5901/tcp
Luego de guardar los cambios, crearemos el archivo /etc/xinetd.d/vnc con el siguiente contenido:
service vnc-1024x768
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = :2 -inetd -query localhost -geometry 1024x768 -once securitytypes=none
}
Luego tras iniciar una sesión como el usuario root en el entorno gráfico, ejecutaremos el comando:
# gdmsetup
y vamos a la pestaña "Remota", donde seleccionaremos la opción que dice "Igual que en la entrada local". De manera alternativa en la
pestaña "Seguridad" podemos activar el check que dice "Permitir entrada remota al administrador del sistema" lo cual en términos de
seguridad no es recomendable pero para fines de prueba estará bien.
Tras un reinicio del GDM -podemos matar todos sus procesos- iniciaremos nuevamente este Display Manager y ya lo tendremos listo
para acceder vía VNC.
Sólo necesitaremos acceder desde algún cliente VNC a la dirección 172.31.0.1:1 (asumiendo dicha dirección IP de ejemplo) y se nos
mostrará la pantalla de inicio de sesión GDM.
Ambas son aplicaciones gráficas intuitivas de fácil uso. Si no trabajamos con ninguno de estos entornos de escritorio podemos instalar
simplemente el paquete rdesktop y conectarnos como sigue a un host remoto vía RDP:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 180
Source Linux
10.5. Laboratorio N° 10
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Configurar un sistema Debian GNU/Linux con 3 direcciones IP (192.168.10.3, 192.168.10.4 y 192.168.10.20) asociadas a la
interfaz de red eth0. Asignarle 8.8.8.8 y 8.8.4.4 como servidores DNS y utilizar 192.168.10.1 como gateway por defecto.
2. Configurar un sistema Red Hat Linux para realizar la misma configuración que el ejercicio anterior utilizando los mismos
parámetros de red.
4. Copiar el contenido del directorio /boot hacia el directorio /tmp del host 172.31.0.10 utilizando las credenciales del usuario
root, limitando la transferencia a una tasa no mayor de 20 Kbit/s.
5. Tras averiguar cuáles son todas las direcciones IP a las que resuelve www.yahoo.com cree una expresión apropiada para
tcpdump de modo tal que se muestre sólo el tráfico HTTP y/o HTTPS originado desde y hacia dicho portal de Internet.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 181
Source Linux
10.5.1. Solución del laboratorio N° 10
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Configurar un sistema Debian GNU/Linux con 3 direcciones IP (192.168.10.3, 192.168.10.4 y 192.168.10.20) asociadas a la
interfaz de red eth0. Asignarle 8.8.8.8 y 8.8.4.4 como servidores DNS y utilizar 192.168.10.1 como gateway por defecto.
auto eth0
iface eth0 inet static
address 192.168.10.3
netmask 255.255.255.0
gateway 192.168.10.1
auto eth0:0
iface eth0:0 inet static
address 192.168.10.4
netmask 255.255.255.0
auto eth0:1
iface eth0 :1inet static
address 192.168.10.20
netmask 255.255.255.0
2. Configurar un sistema Red Hat Linux para realizar la misma configuración que el ejercicio anterior utilizando los mismos
parámetros de red.
+ Editamos el archivo /etc/sysconfig/network para asegurarnos que tenga la directiva GATEWAY como sigue:
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=redhat.consultorianet.com
GATEWAY=192.168.10.1
# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.10.255
HWADDR=08:00:27:C0:3D:DD
IPADDR=192.168.10.3
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
# /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
BOOTPROTO=static
BROADCAST=192.168.10.255
HWADDR=08:00:27:C0:3D:DD
IPADDR=192.168.10.4
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
# /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=static
BROADCAST=192.168.10.255
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 182
Source Linux
HWADDR=08:00:27:C0:3D:DD
IPADDR=192.168.10.20
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
+ Luego restablecemos la interfaz de red, opcionalmente con parámetros anteriores que tenía:
4. Copiar el contenido del directorio /boot hacia el directorio /tmp del host 172.31.0.10 utilizando las credenciales del usuario
root, limitando la transferencia a una tasa no mayor de 20 Kbit/s.
5. Tras averiguar cuáles son todas las direcciones IP a las que resuelve www.yahoo.com cree una expresión apropiada para
tcpdump de modo tal que se muestre sólo el tráfico HTTP y/o HTTPS originado desde y hacia dicho portal de Internet.
# host -t a www.yahoo.com
+ Tras obtener 69.147.76.15 y 209.191.93.52 como resultados, invocamos a tcpdump con los filtros requeridos de análisis
de paquetes:
# tcpdump -ni eth0 \( host 69.147.76.15 and 209.191.93.52 \) and \( port 80 and 443 \)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 183
Source Linux
Unidad 11: Servicios de infraestructura de red
11.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Entender los protocolos DHCP, DNS y NTP así como también su importancia en las redes.
✔ Administrar el direccionamiento IP dinámico en una LAN implementando el servicio DHCP.
✔ Saber configurar el servicio DNS con roles de maestro y esclavo para hospedar zonas de resolución directa e inversa.
✔ Manejar el servicio NTP para una correcta sincronización de tiempo en la red.
Un servidor DHCP puede proveer de distintos parámetros de red a un equipo, algunos de los cuales son:
• Dirección IP.
• Dirección de broadcast.
• Máscara de red.
• Servidores DNS.
• Gateway por defecto o puerta de enlace.
• Nombre DNS.
• MTU para la interfaz.
• Tiempo de espera máximo para consultas ARP.
• Servidores NTP.
• Servidores WINS.
1. El cliente envía un paquete DHCPDISCOVER a la dirección de broadcast (255.255.255.255 o la que corresponda a su subred)
para descubrir servidores DHCP disponibles.
El cliente también puede solicitar el arrendamiento de la última dirección IP que se le asignó si es que éste permanece
conectado a la misma red inicial, situación en la cual el servidor DHCP si es autoritativo le podrá otorgar dicha dirección
solicitada o si se tratase de otra red distinta el servidor le obligará a solicitar una dirección IP distinta.
2. El servidor DHCP al recibir una solicitud de arrendamiento IP desde un cliente, le reserva una dirección IP y le extiende el
ofrecimiento de arrendamiento a través de un paquete DHCPOFFER al cliente. Este paquete contiene la dirección MAC del
cliente, la dirección IP que el servidor está ofreciendo, la máscara de subred, el tiempo de arrendamiento y la dirección IP del
servidor haciendo el ofrecimiento.
3. El cliente puede recibir ofrecimientos DHCP de múltiples servidores pero sólo aceptará a uno enviando un paquete
DHCPREQUEST a la dirección de broadcast, el cual es recibido por el servidor elegido por el cliente (el cual le brindará
finalmente una dirección IP) y por otros servidores los cuales retirarán la oferta de dirección IP hecha inicialmente y la
devolverán a su grupo original de direcciones disponibles.
4. Cuando el servidor recibe el paquete DHCPREQUEST desde el cliente, el proceso de configuración entra en su fase final. La
fase de reconocimiento implica el envío de un paquete DHCPACK desde el servidor al cliente. Este paquete incluye el tiempo
de arrendamiento y otros parámetros de configuración que haya solicitado el cliente, terminando así el proceso de
configuración de IP.
5. Cuando el tiempo de arrendamiento está por vencer, el cliente puede percatarse de esto y enviar otro paquete
DHCPREQUEST al servidor, o éste notificar al cliente enviando un paquete DHCPNAK para consultar al cliente si desea
extender su tiempo de arrendamiento.
6. Cuando un cliente desea desconectarse puede enviar un paquete DHCPRELEASE al servidor para liberar así dicha dirección
IP.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 184
Source Linux
Implementación de un servidor DHCP
Luego de tener una breve introducción teórica del funcionamiento del protocolo, pasamos al proceso de instalación, configuración y
puesta en marcha de un servidor DHCP.
Se requiere instalar el paquete que contiene el software de servidor DHCP y dependiendo en la distribución Linux en la cual trabajemos
procederemos como sigue:
En Debian y derivados:
Observaciones:
• La instalación del servidor DHCP en Red Hat y derivados por defecto no crea un archivo /etc/dhcpd.conf válido, sino que en el
directorio /usr/share/doc/dhcp-*/ existe un archivo modelo de ejemplo, por lo general llamado dhcpd.conf.sample a partir del cual
podemos basarnos para crear nuestro archivo de configuración principal en /etc/dhcpd.conf.
• La instalación del servidor DHCP en Debian y derivados, lanza por defecto un asistente que dice:
En cualquier de los casos, trabajaremos con un archivo de configuración vacío desde el cual podamos empezar con nuestras propias
directivas explicando cada una de las que agreguemos, por ello procederemos a hacer una copia del original y crear uno en blanco:
# mv /etc/dhcpd.conf /etc/dhcpd.conf.orig
# touch /etc/dhcpd.conf
En Debian y derivados:
# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.orig
# touch /etc/dhcp3/dhcpd.conf
Antes de crear contenido es importante conocer la estructura del archivo de configuración dhcpd.conf que es como sigue:
# Sección global
parámetros globales...
host HOSTNAME1 {
parámetros específicos de host ...
}
host HOSTNAME2 {
parámetros específicos de host ...
}
}
host HOSTNAME3 {
parámetros específicos de host ...
}
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 185
Source Linux
}
Donde...
1. En la sección global es posible definir algunos parámetros generales tal como el dominio de la organización, los servidores
DNS, el tiempo de arrendamiento, soporte de Dynamic DNS, opciones de logging, entre otros. Cualquiera de estos
parámetros serán adoptados por las subnets o grupos definidos en el resto del archivo a menos que en dichas secciones se
sobreescriban con valores distintos.
2. La sección de subnets permite definir los rangos de direcciones IP a ser asignados a hosts, y para cada uno de ellos se
pueden asignar parámetros específicos o sobreescribir algunos declarados en la sección global. Algunos parámetros
configurables en esta sección puede ser la máscara de red, la dirección de broadcast, la puerta de enlace, el rango de
direcciones IP disponibles, servidores NTP, direcciones MAC para asignación estática de IP a hosts, etc.
Es así que ahora podemos crear un archivo de configuración con un contenido como el siguiente:
ddns-update-style none;
ignore client-updates;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
host eramirez {
hardware ethernet 00:A3:BF:32:81:E1;
fixed-address 172.31.21.250;
}
host aruiz {
hardware ethernet 03:1B:00:29:2C:CD;
fixed-address 172.31.21.251;
}
Directiva Descripción
Define el modo de trabajo de un sistema DNS dinámico. Valores admisibles son ad-hoc,
ddns-update-style
interim y none. Se elige el último para no usar esta funcionalidad.
ignore client-updates Ignora cualquier requerimiento de los clientes de actualizaciones dinámicas de DNS.
default-lease-time Tiempo por defecto de arrendamiento de direcciones IP.
max-lease-time Tiempo máximo de arrendamiento de direcciones IP.
authoritative Configura el servidor como maestro y autoridad de su segmento de red.
log-facility Define la categoría o facility bajo la cual generar logs para el demonio syslog.
subnet ... netmask Define un segmento de red sobre el cual trabajar.
range Define un rango de direcciones IP disponibles para entregar a clientes.
host Asocia un identificador a un nombre de host al cual se le aplicarán directivas específicas.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 186
Source Linux
hardware ethernet Identifica la dirección MAC de un host.
fixed-address Define una dirección IP que siempre será asignada (de forma estática) a un host.
option domain-name Define un nombre de dominio.
option subnet-mask Define la maścara de red.
option broadcast-address Define la dirección de broadcast.
option domain-name-servers Define uno o más servidores que usarán los clientes para resolución de nombres DNS.
option netbios-name-servers Define uno o más servidores que usarán los clientes para resolución de nombres NetBIOS.
option ntp-servers Define uno o más servidores que usarán los clientes para sincronizar la hora vía NTP.
option routers Define el gateway por defecto para los clientes.
Nosotros podemos ajustar el archivo de configuración a nuestras necesidades agregando o eliminando algunas de las directivas
descritas. Una vez que terminemos de editar el archivo de configuración dhcpd.conf es necesario verificar si la sintaxis está correcta
ejecutando:
# dhcpd -t
Internet Systems Consortium DHCP Server V3.0.5-RedHat
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
En Debian y derivados:
# dhcpd3 -t
Internet Systems Consortium DHCP Server V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
... comprobando que sólo el texto arriba mostrado sin negrita sea lo único que aparezca. En caso de encontrarse algún error o
advertencia, el comando ejecutado mostrará la observación correspondiente debajo.
Antes de iniciar el demonio DHCP es necesario que revisemos un archivo de opciones, en el cual podríamos indicar en qué interfaces
de red deseamos limitar el funcionamiento de este servicio a través de la modificación del archivo debajo indicado:
# vim /etc/sysconfig/dhcpd
En Debian y derivados:
# vim /etc/default/dhcp3-server
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 187
Source Linux
# chkconfig dhcpd on
# service dhcpd start
# tail -f /var/log/messages
En Debian y derivados:
Estos pasos se aseguran que el servicio DHCP se ejecute al iniciar el sistema, arranca el demonio y empieza a leer los logs para
analizar el funcionamiento del servicio tras hacer pruebas en el lado del cliente.
Un equipo con Linux, puede desde la línea de comandos solicitar una dirección IP vía DHCP como sigue:
# dhclient eth0
Mientras que en un equipo con Windows, desde la línea de comandos se puede realizar una acción similar (siempre y cuando la
interfaz de red esté configurada para obtener sus parámetros automáticamente) como sigue:
Al invocar una petición DHCP, podremos ver logs como los siguientes en el lado del servidor:
... donde apreciamos cómo se realiza la negociación de parámetros de red vía el protocolo DHCP, tal como se describió en teoría al
inicio de este apartado.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
5. Dentro de Webmin acceder a 'Servers -> DHCP Server' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 188
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 189
Source Linux
11.3. Servicio DNS
El protocolo DNS
El sistema de nombres de dominio, DNS (Domain Name System) es una base de datos distribuida y jerárquica. Este sistema guarda
información de asociación entre nombres de hosts de Internet a direcciones IP y viceversa, información de ruteo de mails y otros datos
usados por aplicaciones de Internet.
DNS es un protocolo de aplicación y usa tanto UDP como TCP. Los clientes solicitan a los servidores de DNS sus consultas por medio
de UDP para hacer mas rápida la comunicación y utilizan TCP sólo en caso de que llegara a ocurrir una respuesta truncada. En este
protocolo no existe diferencia entre minúsculas y mayúsculas.
Un cliente busca información en un DNS llamando a una librería de sistema conocida como resolver, el cual envía consultas a uno o
más servidores DNS e interpreta sus respuestas.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 190
Source Linux
Los datos asociados con cada nombre de dominio es almacenado en la forma de resource records (RRs) o registros de recurso y
algunos de estos pueden ser:
Donde:
• NOMBRE : Es el nombre del objeto referenciado por el registro del recurso. Puede ser un nombre de estación o un
nombre de dominio.
• TTL : Es el tiempo de vida del registro. Define la cantidad de segundos que la información sobre este registro
puede ser mantenida en la memoria de un servidor de dominios. Si el ttl es omitido usa el ttl indicado por el recurso definido
en la sección SOA.
• IN : Identifica la clase del registro como clase Internet.
• TIPO_REGISTRO : Identifica el tipo de recurso de acuerdo a la tabla anterior.
• VALOR : Es la información específica al tipo de recurso.
El dominio in-addr.arpa
Dentro del espacio de nombres de dominio de la red Internet se encuentra el espacio de nombres de dominio in-addr.arpa cuya función
es asociar una dirección IP con un nombre de dominio de esta manera el usuario a partir de una dirección IP puede conocer el nombre
de dominio asociado a dicha dirección IP. En este espacio de nombres de dominios la dirección IP se lee desde lo más especifico a lo
más general; Por ejemplo www.caida.org. (192.172.226.123) se leería 123.226.172.192.in-addr.arpa. lo cual retorna en una búsqueda a
www.caida.org.
Zonas
Para operar apropiadamente un servidor de nombres, es importante conocer la diferencia entre zona y dominio. Como lo mencionamos
anteriormente, una zona es un punto de delegación en el árbol DNS. Una zona consiste de esas partes contiguas del árbol de dominios
para el cual un servidor de nombres tiene información completa y sobre el cual tiene autoridad. Contiene todos los nombres de dominio
desde un cierto punto hacia abajo en el árbol de dominios excepto aquellos que son delegados a otras zonas.
Un punto de delegación es marcado por uno o más registros de recurso NS en la zona padre, el cual debería coincidir con registros de
recurso NS equivalentes en la raíz de la zona delegada.
Por ejemplo, considérese el dominio 'ejemplo.com' el cual incluye nombres como 'host.aaa.ejemplo.com' y 'host.bbb.ejemplo.com',
aunque sin embargo la zona 'ejemplo.com' incluye solamente delegaciones para las zonas 'aaa.ejemplo.com' y 'bbb.ejemplo.com'. Una
zona puede asociarse exactamente a un único dominio, pero podría también incluir solamente información de una parte de un dominio,
el resto del cual podría ser delegado a otros servidores de nombres. Cada nombre en un árbol DNS es un dominio, incluso si es
terminal u hoja (es decir, no tiene subdominios). Cada subdominio es un dominio y cada dominio excepto la raíz es también un
subdominio.
Métodos de búsqueda
Los servidores de nombres de dominio no sólo pueden ofrecer al resolver los datos de la zona que tienen autoridad sino que pueden
buscar a lo largo del espacio de dominios, datos sobre los que no tienen autoridad. A esto se le como conoce como resolución. La
resolución comienza siempre desde los servidores de nombres de dominio superiores "Servidores de nombres de dominio de raíz
primarios" hasta llegar al servidor de nombres de dominio de nivel secundario que tiene la información acerca de la zona solicitada por
el resolver. El proceso de resolución o búsqueda puede ser de tres tipos: Recursiva, Iterativa o Inversa.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 191
Source Linux
• Una búsqueda recursiva; consiste en que un servidor de nombres de dominios a medida que obtiene respuestas durante el
proceso de resolución de nombres de dominios este va guardando los nombres y su dirección IP asociada en una memoria
cache con el fin de acelerar el proceso de búsqueda si la misma información es solicitada nuevamente. Este tipo de consulta
es típicamente hecha por un cliente DNS (un resolver) a un servidor DNS.
• Una búsqueda iterativa; consiste en que el servidor de nombres de dominios da la mejor respuesta posible basado en la
información contenida en los archivos de la zona y en la memoria cache. La preguntas solicitadas a los servidores de
nombres de dominio raíz solo pueden ser iterativas. Este tipo de consulta es típicamente hecha por un servidor DNS a otro,
después de recibir una consulta recursiva desde el cliente.
• Una búsqueda inversa; consiste en que el cliente intenta averiguar el nombre de un nodo de un dominio a partir de una
dirección IP consultando el dominio especial in-addr.arpa
Servidores caché
Las librerías resolver provistas por la mayoría de sistemas operativos son por así decirlo limitadas en el aspecto que ellas no son
capaces de realizar el proceso de resolución DNS completo por sí mismos consultándole directamente a los servidores autoritativos.
En cambio, ellas dejan en manos de un servidor de nombres local la resolución. Este tipo de servidor es llamado servidor de nombres
recursivo; realiza búsqueda recursivas para clientes locales.
Para mejorar el rendimiento, los servidores recursivos guardan en caché los resultados de las búsquedas que ellos realizan. Debido a
que los procesos de recursividad y almacenamiento en caché están íntimamente conectados, los términos servidor recursivo y
servidor caché son usados como sinónimos a menudo.
La cantidad de tiempo que un registro de recurso puede ser retenido en la caché de un servidor de nombres caché es controlado por el
campo TTL (Time To Live o Tiempo de vida) asociado con cada registro de recurso.
Reenvío o forwarding
Incluso un servidor de nombres caché no realiza necesariamente la búsqueda recursiva completa por sí mismo. En cambio, puede
reenviar algunas o todas las consultas que no puede satisfacer desde su caché a otros servidores de nombres caché, comúnmente
conocidos como un forwarder.
Puede haber uno o más forwarders, y ellos son consultados en orden hasta que la lista se termine o hasta que se encuentre una
respuesta. Los forwarders son comúnmente usados cuando uno no desea que todos los servidores en un cierto sitio no interactúen
directamente con los servidores de Internet. Un escenario típico sería un número de servidores DNS internos y un firewall de Internet.
Los servidores que están impedidos de enviar paquetes a través del firewall podrían reenviar su consulta a un servidor que sí pueda
atravesar dicho firewall y este último servidor preguntaría a los servidores DNS de Internet para conseguir la consulta requerida en la
red local.
Un beneficio añadido de usar el reenvío es que la máquina central puede realizar una caché de información mucho más completa del
cual los clientes pueden beneficiarse.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 192
Source Linux
para ninguna zona y solamente ofrece servicios recursivos a clientes locales (un servidor de nombres caché) no necesita ser accesible
desde Internet y puede ser colocado dentro de una zona protegida por un firewall.
En Debian y derivados:
Observaciones:
• La instalación de BIND en Red Hat y derivados no crea ningún archivo de configuración /etc/named.conf, se debe crear uno
desde cero o basarse en un archivo de configuración de ejemplo ubicado en /usr/share/doc/bind-*/samples/etc/named.conf.
• La instalación de BIND en Debian crea un archivo de configuración válido y usable en /etc/bind/named.conf el cual por defecto
incluye otros archivos de configuración como /etc/bind/named.conf.options y /etc/bind/named.conf.local.
• El software BIND trae consigo el demonio named, que es el nombre del binario que realiza la función real del servidor DNS.
Por ello a partir de ahora cuando se haga mención al demonio named se estará hablando del servidor BIND.
En cualquier de los casos, trabajaremos con un archivo de configuración vacío desde el cual podamos empezar con nuestras propias
directivas explicando cada una de las que agreguemos, por ello procederemos a hacer una copia del original y crear uno en blanco:
# touch /etc/named.conf
En Debian y derivados:
# mv /etc/bind/named.conf /etc/bind/named.conf.orig
# touch /etc/bind/named.conf
Antes de crear contenido es importante conocer la estructura del archivo de configuración dhcpd.conf que es como sigue:
# Sección de ACLs
acl ACL { ... ... };
...
...
zone "ZONA" in {
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 193
Source Linux
...
...
};
};
Donde...
1. La sección de ACLs define a través del contenedor acl una o más ACLs que hacen referencia a clientes a través de
direcciones IP o rangos de red específicos.
2. En la sección de parámetros globales es posible definir dentro del contenedor options directivas del funcionamiento
general del demonio named, tal como los puertos y direcciones de escucha, direcciones de los forwarders, restricciones de
consultas de clientes, soporte de recursividad, etc.
3. En la sección de configuración de logs es posible definir dentro del contenedor logging directivas que especifican cómo se
han de clasificar los logs generados por el demonio named.
4. En la sección de vistas es posible definir dentro del contenedor view directivas que controlen como BIND ha de trabajar de
forma distinta según las consultas que hagan los clientes perteneciendo a una u otra vista. Dentro de una vista es posible
redefinir directivas incluidas en el contenedor options, así como también definir todas las zonas que utilizará el servidor.
A pesar que es posible configurar el servicio sin ninguna definición de vistas, cuando se declara al menos una vista es
obligatorio que todas las zonas estén declaradas en una u otra vista.
5. El archivo de configuración reconoce los comentarios en aquellas líneas que empiecen con el símbolo # o también al estilo
del lenguaje C con los símbolos // o los delimitadores /* y */
Configuración de ACLs
Las ACLs permiten identificar a través de un nombre a uno o más clientes, los cuales serán referenciados en otras secciones de
configuración del demonio named.
Las siguientes son las ACLs predeterminadas:
Configuraciones globales
Las directivas de configuraciones globales determinan aspectos del funcionamiento del demonio named. Algunas de estas directivas
son las siguientes:
Directiva Descripción
directory Define el directorio de trabajo de BIND. Cualquier referencia no absoluta a archivos será
referenciada en base a este directorio como punto de partida.
Si es yes (lo predeterminado), entonces un servidor maestro notificará a sus servidores
notify esclavo cuando se haya realizado cambios en los datos de la zona para la cual es
autoritativo.
recursion Si es yes, habilita las respuestas a consultas recursivas hechas por los clientes.
forwarders { }; Especifica la dirección IP de uno o más servidores DNS que se utilizarán como forwarders.
Si el valor es first (lo predeterminado), entonces el servidor primero consultará hacia un
forward forwarder y si éste no sabe la respuesta entonces recién se intentará buscar la respuesta
por sí solo.
Si el valor es only entonces el servidor solamente consultará hacia los forwarders.
allow-notify { ACLs; }; Directiva válida sólo para servidores esclavos. Permite definir qué servidores -aparte de los
maestros- están permitidos a enviar notificaciones de cambios de zona a este servidor.
allow-query { ACLs; }; Especifica qué hosts están autorizados a realizar consultas DNS ordinarias a este servidor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 194
Source Linux
allow-recursion{ ACLs; }; Especifica qué hosts están autorizados a realizar consultas DNS recursivas a este servidor.
allow-transfer{ ACLs; }; Especifica qué hosts están autorizados a recibir transferencias de zona desde este servidor.
listen-on { ADDRESSES; }; Especifica las direcciones IPv4 en las que ha de funcionar el demonio named.
listen-on-v6 { ADDRESSES; }; Especifica las direcciones IPv6 en las que ha de funcionar el demonio named.
Con estas directivas, podemos tener una sección de configuración global de ejemplo similar a la siguiente:
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
8.8.4.4;
};
forward first;
listen-on { 127.0.0.1; 172.31.0.202; };
allow-query { localhost; lan; };
};
Configuraciones de logs
La configuración de logs del demonio named se hace dentro de un contenedor logging donde se definen canales (los que clasifican
dónde y cómo se almacenan logs) y categorías (que identifican la naturaleza de logs) para poder así organizar el sistema de logs que
genera BIND.
Una configuración de logs se hace a través de un único contenedor logging con el uso conjunto de las directivas channel y
category siguiendo una sintaxis debajo mostrada:
logging {
channel CANAL {
file|syslog|stderr|null <ARGUMENTOS>;
severity <critical|error|warning|notice|info|debug [nivel]|dynamic>;
print-category <yes|no>;
print-severity <yes|no>;
print-time <yes|no>;
};
category CATEGORÍA {
CANAL1; [CANAL2; ... ]
};
};
Las directivas válida dentro de una sección de configuración de logs son las siguientes:
Directiva Descripción
channel contenedor de directivas de logs que permiten configurar dónde se almacenan, control de
versiones y tamaños de ficheros de logs, el formato usado, niveles de severidad, entre otros.
file Destino del log. Define la ruta de un archivo donde se almacenan los logs.
Usado como directiva complementaria de file, define la cantidad de archivos de logs
versions
antiguos que se almacenarán tras alcanzar cada uno de ellos su tamaño límite máximo.
Usado como directiva complementaria de file, define el tamaño máximo que puede tener
size
un archivo de log, pudiendo especificarse con sufijos como 'k' (KB), 'm' (MB) o 'g' (GB).
syslog Destino del log. Define el facility del demonio syslog al cual se enviarán los logs.
Destino del log. Envía los logs a la salida de error cuando named es ejecutado en primer
stderr
plano y no como demonio en background.
null Destino del log. Ignora cualquier log generado por el demonio named.
Define la severidad de los logs. Funciona exactamente igual que los priorities del demonio
severity
syslog.
print-category Si es yes, se incluirá el nombre de la categoría en el log.
print-severity Si es yes, se incluirá la severidad en el log.
print-time Si es yes, se incluirá la fecha y hora en el log.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 195
Source Linux
Identifica la naturaleza del log que genera el demonio named. Las categorías están ya
predefinidas y son default, general, database, security, config, resolver, xfer-
category
in, xfer-out, notify, client, unmatched, network, update, update-security,
queries, dispatch, dnssec, lame-servers, delegation-only y.edns-disabled
• default : Cualquier otra categoría para la cual no se ha creado una configuración específica aún.
• database : Lo relacionado a la base de datos interna que gestiona la información de zona y caché.
• resolver : Resoluciones DNS, tales como las consultas recursivas en favor de los clientes.
: Mensajes para los cuales BIND fue incapaz de determinar la clase o vista coincidente. Por defecto
• unmatched va al canal null.
• dispatch : Envío de paquetes entrantes a los módulos del servidor donde han de ser procesados.
: Lame servers (servidores mal configurados), encontrados por BIND al querer hacerles consultas a
• lame-servers
ellos.
• edns-disabled : Consultas forzadas a usar DNS plano debido a tiempos de espera agotados.
Así con estas directivas, podemos tener una sección de configuración de logs de ejemplo similar a la siguiente:
logging {
channel seguridad {
file "/var/log/named/seguridad.log" versions 3 size 2m;
severity info;
};
channel consultas {
file "/var/log/named/consultas.log" versions 3 size 5m;
severity debug;
};
channel general {
syslog local4;
severity info;
print-category yes;
};
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 196
Source Linux
category security { seguridad; default_syslog; };
category xfer-in { general; };
category xfer-out { general; };
category notify { general; };
category lame-servers { general; };
category client { general; };
category resolver { general; };
};
Observaciones:
• El ejemplo arriba mostrado asume que debe existir el directorio /var/log/named (o /var/named/chroot/var/log/named si es que el
demonio named corre en un entorno chroot debajo de /var/named/chroot) y tener permisos de escritura para el usuario con el
cual es ejecutado el demonio named.
channel default_syslog {
syslog daemon;
severity info;
};
channel default_debug {
file named.run;
severity dynamic;
};
channel default_stderr {
stderr;
severity info;
};
channel null {
null;
};
• Si no se define ningún contenedor logging entonces BIND utiliza la siguiente configuración de logs de manera
predeterminada:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Configuración de vistas
Las vistas en BIND son una potente funcionalidad que permite responder consultas DNS de manera diferente dependiendo quién sea
el que haga la consulta.
Una vista se define con el contenedor view y permite definir una vista del espacio de nombres que visualizarán un grupo de clientes.
Un cliente coincide con una vista si la dirección IP origen de su consulta coincide con una de las ACLs declaradas dentro de la directiva
match-clients y la IP destino coincide con una de las ACLs dentro de la directiva match-destinations.
Si no se especifican las directivas match-clients y/o match-destinations entonces ambas por defecto coincidirán con todas las
direcciones.
Debe tenerse en cuenta que el orden en el que se definan las vistas dentro del archivo named.conf es importante ya que un cliente será
tratado en el contexto de la primera vista con la que coincida.
Las zonas definidas dentro de un contenedor view serán visibles sólo a los clientes que coincidan con dicha vista, sin embargo una
zona puede ser definida dentro de más de una vista con igual o distinta información de zona.
Muchas de las directivas globales de BIND definidas dentro de un contenedor options pueden ser definidas dentro de una vista.
Cuando no se defina un valor específico de una directiva en una vista, se usará por defecto el valor definido dentro del contenedor
options.
Si no existen contenedores view declarados en el archivo de configuración entonces una vista por defecto que coincide con todos los
clientes será automáticamente creada. Así, cualquier declaración de zona (contenedor zone) declarada en el archivo de configuración
pertenecerá a esta vista por defecto, y el contenedor options aplicará dicha vista.
Si se declara de manera explícita al menos un contenedor view entonces todas las declaraciones de zona deben hacerse
necesariamente dentro de una de las vistas.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 197
Source Linux
Una configuración de vista se hace con una sintaxis como la debajo mostrada:
view VISTA {
match-clients { ACLs; };
match-destinations { ACLs; };
[ directivas-globales; ... ]
[ zone; ... ]
};
Algunas de las directivas que se pueden encontrar en una configuración de vista son las siguientes:
Directiva Descripción
match-clients { ACLs; }; Identifica a los clientes que serán tratados dentro del contexto de la vista a través de la
coincidencia de la dirección IP origen de su consulta con una de las ACLs declaradas.
match-destinations { ACLs; }; Identifica a los clientes que serán tratados dentro del contexto de la vista a través de la
coincidencia de la dirección IP destino de su consulta con una de las ACLs declaradas.
Si es yes, entonces sólo las consultas recursivas de los clientes coincidentes con la vista
match-recursive-only
serán tratadas dentro del contexto de la misma.
Configuración de zonas
La configuración de zonas se hace a través del contenedor zone el cual contiene muchas directivas que definen su comportamiento
dependiendo del tipo de zona como se configure.
Una configuración de zona se hace con una sintaxis como la debajo mostrada:
[ directivas-de-zona; ]
};
Donde algunas de las directivas que se pueden encontrar en una configuración de zona son las siguientes:
Directiva Descripción
Define cómo el demonio named controla una zona ya sea como master (maestro), slave
type
(esclavo) o hint.
file Define la ruta del archivo que contiene la información de zona.
allow-query { ACLs; }; Su significado es el mismo como directiva global dentro de un contenedor options.
allow-transfer { ACLs; }; Su significado es el mismo como directiva global dentro de un contenedor options.
notify Su significado es el mismo como directiva global dentro de un contenedor options.
masters { ACLs; }; Válido sólo para servidores esclavo. Define uno o más servidores maestros para una zona
desde los cuales solicitar transferencias de zona.
: El servidor contiene la copia maestra de los datos de zona y podrá dar respuestas autoritativas
• master
sobre ella.
• slave : El servidor contiene una réplica de una zona desde uno o más servidores maestros.
: Define el grupo inicial de servidores DNS raíz para a partir de ellos obtener la lista vigente de
• hint
servidores raíces.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 198
Source Linux
Además la clase CLASS que caracteriza una zona puede ser del tipo IN (Internet), HS (Hesiod) o CHAOS (Chaosnet), donde por lo
general se usará siempre la clase IN (a menos que se sepa realmente por qué se requiere usar otra clase distinta). Si no se especifica
la clase se asumirá IN.
Así, con las directivas estudiadas sobre vistas y zonas es posible crear una configuración de ejemplo de dos zonas, una como maestro
y otra como esclavo, ambas sin definiciones explícitas de vistas como sigue:
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
zone "0.31.172.in-addr.arpa" IN {
type slave;
file "/var/named/0.31.172.in-addr.arpa.db";
masters { 172.31.0.30; };
};
Donde...
1. Los archivos de zona db.root y consultorianet.com.db especificados como rutas no absolutas, se ubican dentro del directorio de
trabajo del demonio named definido en la directiva global directory.
3. A través de la directiva allow-transfer en la zona consultorianet.com se definen las direcciones IP de dos hosts
autorizados a solicitar y recibir transferencias de zona desde este servidor, los mismos que podrían ser casualmente
servidores esclavos de esta zona.
4. A través de la directiva masters se define la IP de un servidor maestro desde el cual se extraerá una réplica de la
información de zona a través de transferencias de zona que dicho servidor maestro debe haber autorizado para nuestro
servidor.
Y la siguiente sería un ejemplo de una configuración de las mismas dos zonas dentro de contextos de vistas:
view "INTERNA" {
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.INTERNA.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
zone "0.31.172.in-addr.arpa" IN {
type slave;
file "0.31.172.in-addr.arpa.db";
masters { 172.31.0.30; };
};
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 199
Source Linux
};
view "EXTERNA" {
/* Coincide con cualquier otro cliente que no coincidió con la vista anterior.
En esta vista podrían encajar los clientes de una red WAN o Internet */
match-clients { any; };
recursion no;
notify no;
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.EXTERNA.db";
allow-transfer { none; };
};
};
Donde...
1. La zona "INTERNA" tiene por objetivo atender a los clientes "de confianza" pertenecientes a una red LAN y localhost, a los
cuales se les permite hacer consultas recursivas y además se les muestra una información de zona distinta a la mostrada a
los clientes externos. A esto se suma la existencia de una zona de búsqueda inversa visible sólo para los clientes de la LAN.
2. La zona "EXTERNA" tiene por objetivo atender a otros clientes "no confiables" pertenecientes quizás a una WAN o Intenet, a
los cuales por motivos de seguridad no se les permite hacer consultas recursivas ni tampoco transferencias de zona, además
se les muestra una información de zona distinta a la mostrada a los clientes internos o de la red LAN.
Ahora con las principales directivas de configuración de BIND podemos crear un archivo named.conf de ejemplo completo como el
siguiente:
// Definición de ACLs
acl local { localhost; 172.31.0.0/24; };
acl lan { 172.31.0.0/24; };
// Configuración de logs
logging {
channel seguridad {
file "/var/log/named/seguridad.log" versions 3 size 2m;
severity info;
};
channel consultas {
file "/var/log/named/consultas.log" versions 3 size 5m;
severity debug;
};
channel general {
syslog local4;
severity info;
print-category yes;
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 200
Source Linux
};
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.INTERNA.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
zone "0.31.172.in-addr.arpa" IN {
type slave;
file "0.31.172.in-addr.arpa.db";
masters { 172.31.0.30; };
};
};
/* Coincide con cualquier otro cliente que no coincidió con la vista anterior.
En esta vista podrían encajar los clientes de una red WAN o Internet */
match-clients { any; };
recursion no;
notify no;
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.EXTERNA.db";
allow-transfer { none; };
};
};
El archivo de zona está conformado por líneas donde en cada una se define un registro de recurso, RR (resource record), con una
sintaxis como la siguiente (ya anteriormente estudiada):
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 201
Source Linux
Donde:
• TIPO_REGISTRO :El tipo de RR tal como SOA, NS, MX, A, PTR, TXT, etc.
En el archivo de zona hay muchas observaciones importantes que tener en cuenta, las cuales se mencionan a continuación:
1. La directiva $TTL al inicio del archivo de zona permite definir un valor TTL por defecto que será aplicado a todos los RR que
no tengan un valor específico de tiempo de vida.
2. La directiva $ORIGIN al inicio del archivo de zona define el nombre de dominio que será agregado al final de otros nombres
de dominio no absolutos o no completamente cualificados (no FQDN, aquellos que no terminan en punto "."). Si no se
especifica esta directiva el valor del dominio por defecto igual al nombre de la zona.
$ORIGIN si se define debe indicar un nombre de dominio que termine en punto "." (Ejm: $ORIGIN midominio.com.)
4. Si una línea de definición de RR valor NAME o nombre de dominio propietario (el primer campo) es omitido (dejado en blanco)
entonces se asumirá que se trata del mismo valor que el RR anterior.
5. El valor NAME -nombre de dominio propietario- puede ser especificado como un valor absoluto, completamente cualificado o
FQDN si éste termina en punto ".", sino entonces se le añadirá automáticamente el valor del dominio por defecto definido
en $ORIGIN y se usará el nombre de dominio resultante como valor NAME del RR.
6. Si una línea de definición de RR el valor de TTL se omite entonces se usará el valor por defecto definido por la directiva
$TTL al inicio del archivo de zona.
7. Si una línea de definición de RR el valor de CLASE se omite entonces se usará por defecto la clase IN.
9. Los comentarios se caracterizan por empezar con el símbolo punto y coma ";"
Registro SOA
Donde:
: El nombre de un servidor DNS autoritativo para la zona, pudiendo ser externo expresado como
• NAMESERVER FQDN o interno que de no ser FQDn se completará con el valor de $ORIGIN.
: Dirección e-mail de un administrador del servidor DNS para la zona. El símbolo @ de la dirección
• EMAIL
e-mail debe ser reemplazado por un punto "."
: Número entero de 32 bits que tiene como propósito servir de indicador de versiones del archivo de
zona, incrementándose en su valor por cada modificación hecha a los datos de la zona. Es una
• SERIAL
convención usar un formato de fecha como YYYYMMDDnn, donde 'nn' representaría un número de
revisión en caso que se realicen modificaciones a la zona en más de una ocasión al día.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 202
Source Linux
:Tiempo en segundos que debe esperar un servidor esclavo para consultar al maestro si se ha
• REFRESH incrementado el número serial para entonces iniciar un refresco de los datos con una nueva
transferencia de zona. Puede indicarse con sufijos de tiempo como 'm', 'h', 'd' o 'w'.
: Tiempo en segundos que el esclavo debe esperar para reintentar conectarse al servidor maestro si
• RETRY el número serial se ha incrementado y una conexión previa ha fallado. Puede indicarse con sufijos
de tiempo como 'm', 'h', 'd' o 'w'.
: Tiempo en segundos que debe transcurrir sin comunicación entre el esclavo y el maestro para que
el primero la información de zona como no autoritativa o inválida. Es decir, si por alguna razón un
servidor esclavo ya no puede establecer contacto con un servidor maestro, se inicia un conteo en
• EXPIRY segundos de esta incomunicación mientras el esclavo aún puede responder a consultas de manera
autoritativa, pero al llegar el conteo de segundos al límite impuesto por EXPIRY entonces la
información guardada en caché por el servidor esclavo ya no será válida.
Se recomienda asignar un valor de 2 a 4 semanas.
: Define el tiempo en segundos del TTL de la caché negativa, es decir el tiempo máximo que los
• NEG_CACHE clientes (resolvers) almacenarán en caché las respuestas NXDOMAIN (non-existent domain).
El valor máximo admisible es 3 horas.
Por lo general el registro SOA se define dividido en varias líneas usando los símbolos paréntesis para lograr facilitar la lectura de los
comentarios descriptivos de sus campos, pero nada impide declararlo en una única línea.
Registro NS
DOMINIO NS NAMESERVER
Donde:
: El nombre de un servidor DNS autoritativo para la zona, pudiendo ser externo expresado como
FQDN o interno que de no ser FQDN se completará con el valor de $ORIGIN. Si es interno este
• NAMESERVER nombre de host no puede ser un alias (CNAME) sino tener una dirección propia (registro A).
Se deben definir tantos RR de este tipo como servidores de nombres autoritativos para esta zona
existan.
Registro MX
Donde:
: Valor numérico (de 0 a 65535) que expresa la preferencia relativa a otros registros MX de la zona.
• PRIORIDAD
A menor valor numérico mayor será la preferencia.
: Nombre de host de un servidor de correo que puede ser externo expresado como FQDN o interno
que de no ser FQDN se completará con el valor de $ORIGIN. Si es interno este nombre de host no
• HOSTNAME puede ser un alias (CNAME) sino tener una dirección propia (registro A).
Se pueden crear tantos registros MX como servidores de correo válidos admitan la recepción de
correos electrónicos para el dominio referenciado en la zona.
Registro A
DOMINIO A ADDRESS
Donde:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 203
Source Linux
• ADDRESS : Dirección IP a la cual resuelve el nombre de dominio.
Registro CNAME
Donde:
Registro PTR
Donde:
: Nombre de dominio propietario (dirección IP) del objeto referenciado por el RR en una zona de
• ADDRESS búsqueda inversa (in-addr.arpa). Si no es FQDN se le agrega el valor de $ORIGIN.
Así con la sintaxis de un archivo de zona ya estudiada se puede mostrar dos archivos de ejemplo, uno que corresponda a una zona de
búsqueda directa y otro de una zona de búsqueda inversa acorde a los ejemplos de zonas previamente mostrados líneas arriba.
El siguiente correspondería a la zona consultorianet.com de la vista INTERNA anteriormente declarada como ejemplo:
$ORIGIN consultorianet.com.
$TTL 2h
NS ns1
NS ns2
ns1 A 172.31.0.201
ns2 A 172.31.0.202
mail A 172.31.0.20
www A 172.31.0.10
ftp A 172.31.0.14
correo CNAME mail
El siguiente correspondería a la zona consultorianet.com de la vista EXTERNA anteriormente declarada como ejemplo:
$ORIGIN consultorianet.com.
$TTL 2h
NS ns1
NS ns2
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 204
Source Linux
MX 10 mail
MX 20 aspmx.l.google.com.
MX 30 alt1.aspmx.l.google.com.
ns1 A 190.41.62.3
ns2 A 190.41.62.6
mail A 190.41.62.2
www A 190.41.62.4
correo CNAME mail
El siguiente correspondería a la zona de búsqueda inversa 0.31.172.in-addr.arpa de la vista INTERNA anteriormente declarada como
ejemplo:
$ORIGIN 0.31.172.in-addr.arpa.
$TTL 3h
; 172.31.0.201
201 PTR centos.consultorianet.com.
; 172.31.0.202
202 PTR debian.consultorianet.com.
; 172.31.0.20
20 PTR mail.consultorianet.com.
Finalmente, el archivo de la zona hint que define los servidores de nombres raíz suele tener un contenido predeterminado, no
necesitaremos modificarlo. Su información sería como la debajo mostrada:
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::803f:235
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:C27::2:30
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
Estos archivos de zona deberían ser creados en las rutas especificadas por las directivas file dentro de un contenedor zone, lo que
puede indicar una ruta específica o una ruta relativa al directorio de trabajo del demonio named (directiva directory).
El directorio de trabajo por defecto en Red Hat / CentOS y derivados es /var/named mientras que en Debian y derivados suele ser
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 205
Source Linux
/var/cache/bind.
Opciones:
-t DIR : Ingresa al entorno chroot del directorio DIR y en base a él se toman las referencias de rutas de archivos.
-z : Ejecuta una prueba de carga de todas las zonas maestras encontradas en named.conf
Opcionalmente se puede indicar la ruta del archivo named.conf si éste no es encontrado en una ruta predeterminada.
named-checkzone [opciones] <archivo de zona>
Herramienta de chequeo de sintaxis de archivos de zona
rndc [comandos]
Herramienta de control de named
Comandos:
Iniciando named
Luego de haber estudiado la sintaxis de los archivos de configuración, es necesario revisar si éstos no contienen ningún error para
proceder entonces a iniciar el demonio named.
# named-checkconf
... o si se ejecuta BIND en un entorno chroot (comportamiento por defecto en Red Hat / CentOS y derivados), ejecutaremos el comando
de la siguiente forma:
# named-checkconf -t /var/named/chroot
... el cual si no encuentra ningún error de sintaxis no mostrará salida alguna en la pantalla, de lo contrario informará de las advertencias
o errores encontrados en el archivo de configuración.
También es necesario verificar la sintaxis de los archivos de zona ejecutando comandos similares a:
... o si BIND corre en un entorno chroot en nuestro sistema (por defecto en Red Hat / CentOS y derivados) se ejecutaría como sigue:
... lo cual sólo debería mostrarnos una salida como la arriba mostrada. En caso se encuentre alguna inconsistencia o error de sintaxis
en el archivo éste será informado por la herramienta named-checkzone.
Al comprobar que la sintaxis de todos nuestros archivos de configuración son correctos ya es posible iniciar el demonio named como
sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 206
Source Linux
En Red Hat / CentOS y derivados:
# chkconfig named on
# service named restart
# tail -f /var/log/messages
En Debian y derivados:
Aquí nos aseguramos que el demonio named se ejecute al iniciar el sistema e iniciamos el análisis de los archivos de logs donde de
manera predeterminada se registran los eventos de este demonio. A partir de este momento ya se pueden realizar consultas de prueba
al demonio named referentes a una de las zonas configuradas para averiguar valores de registros NS, MX, PTR, A e incluso
transferencias de zona con el comando host.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
5. Dentro de Webmin acceder a 'Servers -> BIND DNS Server' (o 'Un-used Modules -> BIND DNS Server')y dentro revisar las
opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 207
Source Linux
11.4. Servicio NTP
El protocolo NTP
Network Time Protocol (NTP) es un protocolo de capa de aplicación utilizado en Internet para la sincronización de relojes informáticos a
través del ruteo de paquetes en redes con latencia variable. NTP se basa en UDP en su capa de transporte utilizando el puerto 123.
El uso de este protocolo permite mantener sincronizadas la hora y fecha de equipos informáticos de una red tales como computadores
personales, servidores, teléfonos IP, y otros dispositivos capaces de soportar este protocolo.
• Estrato 1 : Sincronizan con algún reloj externo como los atómicos, GPS o de radio. Son los más precisos.
• Estrato 2 : Sincronizan con algún otro servidor de estrato 1. Son menos precisos.
Un listado de servidores NTP de estrato 1 y 2 pueden ser encontrados en http://www.ntp.org. Es buena práctica mantener siempre al
menos un servidor NTP local en nuestra red para así evitar que los equipos informáticos y otros dispositivos consuman ancho de banda
consultando hacia servidores externos.
En Debian y derivados:
El archivo de configuración del demonio ntp es /etc/ntp.conf en el cual podemos indicar las direcciones IP de servidores NTP de estrato
1 o 2 que deseamos utilizar.
Nos basaremos en el contenido predeterminado de dicho archivo para realizar algunas modificaciones que sean de nuestro interés.
El siguiente ejemplo asume que nuestra red local es 172.31.0.0/255.255.0.0 y nuestro host (172.31.255.254) va a comportarse como
servidor NTP para dicha red permitiéndole sólo a ésta y localhost para que realicen consultas de tiempo a nuestro demonio ntp:
...
...
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
...
...
El siguiente ejemplo asume que formamos parte de la red local 172.31.0.0/255.255.0.0 y nuestro host (distinto del arriba mencionado)
va a comportarse como un cliente NTP que pretende sincronizar el tiempo con el servidor local 172.31.255.254 previamente
configurado:
...
...
server 172.31.255.254
server 0.pool.ntp.org
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 208
Source Linux
server 1.pool.ntp.org
server 2.pool.ntp.org
...
...
Como se muestra en este último ejemplo, para asegurarnos que sincronicemos con el servidor NTP de la red local es importante que
su definición con la directiva server esté en primer lugar.
# chkconfig ntpd on
# service ntpd start
En Debian y derivados:
Tras dejar pasar unos 15 a 20 minutos promedio para que nuestro servidor NTP local sincronice con otros servidores de estratos
superiores, ya podremos desde un cliente consultar la fecha y hora actual de nuestro servidor como sigue:
# ntpdate -q 172.31.255.254
Si deseamos modificar el reloj del sistema en base a la hora que se sincronice desde un servidor NTP ejecutaremos:
# ntpdate 172.31.255.254
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 209
Source Linux
11.5. Laboratorio N° 11
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Crear una configuración de servidor DHCP que atienda a un segmento de red con los siguientes datos:
2. Configurar un servidor DNS con BIND y crear una zona maestra de búsqueda directa de nombre laboratorio.com que sólo
pueda ser consultada por localhost y el segmento de red al cual pertenece dicho dominio según la configuración anterior del
servicio DHCP.
Este debe ser un servidor DNS autoritativo para su zona y por razones de seguridad no trabajar como servidor caché, es
decir no aceptar consultas recursivas de clientes.
La información de zona a crearse acorde a:
3. Actualizar la configuración anterior para permitir al host omega.laboratorio.com recibir transferencias de zona desde nuestro
servidor maestro y desde la dirección de localhost. Comprobar la correcta configuración realizando una transferencia de zona
manual desde la línea de comandos usando el comando host.
4. Actualizar la configuración anterior para permitir sólo a los hosts con un nombre definido (declarados con registro A en el
archivo de zona) y a localhost hacer consultas recursivas al servidor.
Comprobar la correcta configuración realizando una consulta a nombres de dominios para los cuales el servidor configurado
no es autoritativo. Complementar esta comprobación activando el registro de cada consulta DNS hecha por los clientes de
modo tal que sea visualizada en los logs del demonio named.
5. Sobre la configuración actual del servidor BIND, crear una zona maestra de búsqueda inversa para el segmento de red al
cual pertenece el dominio laboratorio.com. En la información de zona debe definirse la resolución inversa sólo para las
direcciones IP a las que resuelven los hosts con nombre definidos en la zona laboratorio.com.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 210
Source Linux
11.5.1. Solución del laboratorio N° 11
1. Crear una configuración de servidor DHCP que atienda a un segmento de red con los siguientes datos:
ddns-update-style none;
authoritative;
log-facility local7;
+ Para asegurarnos que este segmento de red pueda funcionar correctamente con nuestro servicio DHCP es necesario que
la interfaz de red a través de la cual se ofrecerá dicho servicio tenga asignada una IP perteneciente a dicha subnet, si quiera
una IP configurada como alias.
# dhcpd -t
# service dhcpd restart
2. Configurar un servidor DNS con BIND y crear una zona maestra de búsqueda directa de nombre laboratorio.com que sólo
pueda ser consultada por localhost y el segmento de red al cual pertenece dicho dominio según la configuración anterior del
servicio DHCP.
Este debe ser un servidor DNS autoritativo para su zona y por razones de seguridad no trabajar como servidor caché, es
decir no aceptar consultas recursivas de clientes.
La información de zona a crearse acorde a:
options {
// Opciones generales
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 211
Source Linux
directory "/var/named";
zone "laboratorio.com" IN {
// Ubicación del archivo de zona relativo al directorio de trabajo
file "laboratorio.com.db";
+ Creamos el archivo /var/named/laboratorio.com.db que contendrá los datos de la zona laboratorio.com, como sigue:
$ORIGIN laboratorio.com.
$TTL 3600
orion A 172.17.30.13
omega A 172.17.30.14
ftp A 172.17.30.25
wpad A 172.17.30.2
+ Luego de guardar los cambios en los archivos de configuración creados, verificar la correcta sintaxis de ambos y reiniciar el
demonio named si es que no existe ningún error de sintaxis:
# named-checkconf -t /var/named/chroot
# named-checkzone laboratorio.com /var/named/chroot/var/named/laboratorio.com.db
# service named restart
+ Utilizando el comando host verificaremos si es capaz de resolver consultas recursivas obteniendo respuestas erroneas
como prueba:
+ Utilizando el mismo comando host realizar consultas DNS para verificar si los datos de la zona fueron configurados de
acuerdo a lo solicitado:
3. Actualizar la configuración anterior para permitir al host omega.laboratorio.com recibir transferencias de zona desde nuestro
servidor maestro y desde la dirección de localhost. Comprobar la correcta configuración realizando una transferencia de
zona manual desde la línea de comandos usando el comando host.
...
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 212
Source Linux
zone "laboratorio.com" IN {
// Ubicación del archivo de zona relativo al directorio de trabajo
file "laboratorio.com.db";
+ Tras guardar los cambios en el archivo de configuración, verificamos la correcta sintaxis y recargamos el demonio named:
# named-checkconf
# rndc reload
+ Utilizando el comando host intentaremos hacer una transferencia de zona desde el mismo servidor DNS maestro
(orion.laboratorio.com):
4. Actualizar la configuración anterior para permitir sólo a los hosts con un nombre definido (declarados con registro A en el
archivo de zona) y a localhost hacer consultas recursivas al servidor.
Comprobar la correcta configuración realizando una consulta a nombres de dominios para los cuales el servidor configurado
no es autoritativo. Complementar esta comprobación activando el registro de cada consulta DNS hecha por los clientes de
modo tal que sea visualizada en los logs del demonio named.
...
...
options {
// Opciones generales
directory "/var/named";
// Habilitamos la recursividad
recursion yes;
};
...
...
+ Tras guardar los cambios en el archivo de configuración, verificamos la correcta sintaxis y recargamos el demonio named:
# named-checkconf
# rndc reload
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 213
Source Linux
# rndc status | grep logging
# rndc querylog
+ Visualizamos los logs mientras hacemos consultas no autoritativas de prueba desde localhost y desde otro equipo no
autorizado (no definido dentro de la ACL recursive-clients):
1. Sobre la configuración actual del servidor BIND, crear una zona maestra de búsqueda inversa para el segmento de red al
cual pertenece el dominio laboratorio.com. En la información de zona debe definirse la resolución inversa sólo para las
direcciones IP a las que resuelven los hosts con nombre definidos en la zona laboratorio.com.
...
...
+ Creamos el archivo /var/named/30.17.172.in-addr.arpa.db que contendrá los datos de la zona 30.17.172.in-addr.arpa, como
sigue:
$ORIGIN 30.17.172.in-addr.arpa.
$TTL 1w
13 PTR orion.laboratorio.com.
14 PTR omega.laboratorio.com.
25 PTR ftp.laboratorio.com.
2 PTR wpad.laboratorio.com.
+ Luego de guardar los cambios en los archivos de configuración, verificar la correcta sintaxis de ambos y recargar el
demonio named si es que no existe ningún error de sintaxis:
# named-checkconf -t /var/named/chroot
# cd /var/named/chroot/var/named
# named-checkzone 30.17.172.in-addr.arpa 30.17.172.in-addr.arpa.db
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 214
Source Linux
# rndc reload
+ Utilizando el comando host realizar consultas DNS para verificar si los datos de la zona fueron configurados de acuerdo a
lo solicitado:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 215
Source Linux
Unidad 12: Servidor de archivos e impresión
12.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Saber configurar un servidor Samba para que se comporte como servidor de archivos independiente, PDC de dominios al
antiguo estilo NT o como miembro de un dominio Active Directory.
✔ Configurar correctamente el demonio winbind para que sea capaz de mapear usuarios y grupos de un dominio Active
Directory utilizando una configuración de Kerberos.
✔ Conocer las configuraciones básicas necesarias para compartir y usar recursos compartidos de un servidor NFS.
✔ Implementar un servidor FTP básico a través del demonio vsftpd.
✔ Saber generar reportes gráficos amigables sobre el tráfico de las cargas y descargas del servicio FTP.
¿Qué es Samba?
Samba es una implementación libre para sistemas operativos UNIX de los protocolos SMB/CIFS, que permite implementar un servidor
de archivos para redes Microsoft.
Samba permite asumir las funciones de cliente, servidor o ambos en las redes Microsoft para realizar tareas comunes en ellas tales
como resolución de nombres NetBIOS, navegación de equipos en grupos de trabajo, acceder y compartir recursos compartidos,
comportarse como PDC para dominios NT.
En esta sección nos centraremos en aprender los procedimientos de configuración de un servidor Samba para adoptar distintos roles.
Instalación de Samba
El procedimiento de instalación de Samba es sencillo:
En Debian y derivados:
En ambos casos se instala la Suite Samba, que consiste de los programas de servidor y cliente además de otras herramientas útiles
asociadas a este servicio.
Observaciones:
• La instalación de Samba en Debian por defecto lanza un asistente que realiza dos preguntas, en una de ellas nos consulta el
grupo de trabajo por defecto que tenemos en nuestra red, y en la otra pregunta nos pide confirmación si deseamos o no
modificar la configuración de Samba para que se integre con un servicio DHCP.
No importa mucho las respuestas dadas a estas preguntas dado que empezaremos con una configuración desde cero.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 216
Source Linux
# Recurso especial que hace referencia a las impresoras configuradas en el sistema
[printers]
directiva1=VALOR
directiva2=VALOR
directiva3=VALOR
...
...
Cada una de las secciones de configuración tiene un nombre propio y éste se define dentro de los corchetes [ ], así global,
printers y homes son nombres especiales reservados por Samba para los propósitos arriba mencionados.
Cualquier otro nombre encerrado entre corchetes hace referencia a un recurso compartido, que puede ser un directorio que comparte
datos o una impresora.
Dentro del directorio /etc/samba también existe un archivo de nombre lmhosts el cual tiene por objetivo contener una lista de
asociaciones de nombres NetBIOS a direcciones IP.
• Samba tiene la capacidad de controlar los accesos a los recursos compartidos en base a las credenciales de autenticación
provistas por los clientes al conectarse.
Por defecto dichas credenciales no suelen ser las mismas que están asignadas en el sistema UNIX (según /etc/password y
/etc/shadow) sino que utiliza un sistema de gestión de usuarios y contraseñas propio de Samba pero que sin embargo
requiere que existan de todos modos dichos usuarios como cuentas del sistema.
Es decir, si se han de asignar los usuarios eruiz y mflores como los autorizados a acceder a uno o más recursos del servidor,
entonces dichos usuarios deben existir en el sistema operativo Linux en un sistema Shadow, cada uno de ellos con atributos
utilizados por Samba como son el UID, GID de los grupos de los que son miembros y el directorio personal.
• Cuando Samba brinda accesos a un usuario a un recurso, lo hace normalmente con el password asignado por el sistema de
contraseñas de Samba, pero usando los privilegios garantizados por el UID que identifica al usuario.
• Samba a través de su configuración permite brindar permisos de lectura y/o escritura según usuarios y grupos en sus
recursos compartidos, pero dichos permisos están limitados por los permisos UNIX reales que existan en el sistema de
archivos.
Esto quiere decir que si se pretende dar acceso de escritura al usuario eruiz sobre un recurso compartido, éste permiso no
se hará efectivo si es que el directorio que está asociado al recurso no permite escribir al usuario eruiz según la
interpretación vigente de los permisos UNIX tradicionales o ACLs definidas.
El esquema de seguridad basado en recurso se caracteriza por no requerir al usuario que inicie sesión en el servidor antes de intentar
conectarse a uno de los recursos compartidos, sino sólo se envían las credenciales de autenticación en base a cada recurso al cual se
conectará.
El esquema de seguridad basado en usuarios se caracteriza por forzar a los clientes que primero inicien sesión en el servidor con
algún juego de credenciales válidas antes de intentar conectarse a uno de los recursos compartidos.
En esta sección asumiremos que se usa este último esquema de seguridad. Para ello empezaremos creando un archivo de
configuración vacío:
# cd /etc/samba
# mv smb.conf smb.conf.orig
# touch smb.conf
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 217
Source Linux
... y crear como contenido del archivo smb.conf lo siguiente:
[global]
security = user
netbios name = fileserver
netbios aliases = samba servidor
server string = Servidor Samba %v
workgroup = CONSULTORIANET
wins support = yes
log file = /var/log/samba/samba.log
log level = 2
max log size = 2000
[homes]
browseable = no
comment = Directorio personal
writeable = yes
public = no
valid users = @users, admin
[musica]
path = /data/musica
comment = Musica compartida
writeable = no
public = no
valid users = admin, eruiz, mperez
[principal]
path = /data/principal
writable = yes
veto files = /*mp3*/*avi*/*mpg*/*wav*/*wma*/*wmv*/*swf*/*pps*/
valid users = @users @sistemas admin operador
read list = @users operador
write list = @sistemas admin
force group = sistemas
create mask = 0770
directory mask = 0770
inherit acls = yes
inherit owner = yes
Este archivo de configuración de ejemplo contiene sólo algunas de las directivas que posiblemente pueden existir en sus secciones
respectivas.
A continuación se muestra un listado detallado de las directivas más importantes que se pueden encontrar en una configuración de
Samba como servidor independiente:
Directiva Descripción
El grupo de trabajo del cual forma parte el servidor. También define el nombre del dominio si se
workgroup
usa el esquema de seguridad domain.
netbios name El nombre NetBIOS principal del servidor.
netbios aliases Nombres NetBIOS alternativos asignados al servidor.
server string Descripción del servidor.
security Esquema de seguridad. Valores posibles son: share, user, domain, ads
SI es yes (por defecto) entonces se utilizan contraseñas encriptadas en la negociación con los
encrypt passwords
clientes.
log file La ruta absoluta del archivo de logs de Samba.
log level El nivel de información de los logs.
max log size El tamaño máximo del archivo de logs en KB.
time server Si es yes entonces Samba se anunciará a los clientes de la red como un servidor de tiempo.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 218
Source Linux
wins support Si es yes entonces Samba se comporta como un servidor WINS en la red.
Directiva Descripción
path La ruta del directorio que se publica como recurso compartido.
browseable Si es yes entonces Samba hará visible este recurso en la lista de visualización a los clientes.
comment Texto descriptivo asociado al recurso.
valid users Lista de usuarios válidos que pueden conectarse al recurso. Un nombre de grupo se especifica
con un símbolo @ por delante.
invalid users Lista de usuarios válidos que no pueden conectarse al recurso. Un nombre de grupo se
especifica con un símbolo @ por delante.
admin users Lista de usuarios que tendrán privilegios de root al conectarse al recurso. Un nombre de grupo
se especifica con un símbolo @ por delante.
writeable Comparte el recurso en modo lectura/escritura. Es el opuesto de la directiva read only.
write list Lista de usuarios que tienen acceso de lectura/escritura.
read list Lista de usuarios que tienen acceso de sólo lectura.
Permite que se puedan conectar al recurso sin utilizar una contraseña. Sinónimo de la directiva
guest ok
public.
create mask Define los permisos por defecto que se aplicarán a archivos creados en este recurso.
directory mask Define los permisos por defecto que se aplicarán a directorios creados en este recurso.
force group Especifica el nombre de grupo que será asignado como grupo primario por defecto para los
clientes que se conectan al recurso.
force user Especifica el nombre de usuario que será asignado como usuario por defecto para los clientes
que se conectan al recurso.
hide dot files Permite mostrar como archivos ocultos aquellos que empiecen con un punto.
Lista de archivos y directorios que se mostrarán como ocultos en el recurso. Esta lista separa
hide files nombres formados por comodines (* y ?) separados por el símbolo slash.
Ejm: /*.tmp/*.mp3/*musica*/
Lista de archivos y directorios que serán invisibles e inaccesibles en el recurso. Esta lista separa
veto files nombres formados por comodines (* y ?) separados por el símbolo slash.
Ejm: /*.tmp/*.mp3/*musica*/
hosts allow Lista de hosts que sí serán permitidos conectarse al recurso.
hosts deny Lista de hosts que no serán permitidos conectarse al recurso.
inherit acls Permite asignar las ACLs por defecto a los archivos y directorios creados en el recurso.
Permite que los archivos y directorios creados adquieran el mismo usuario propietario que el
inherit owner directorio padre, en lugar que este valor sea gobernado por el nombre de usuario que se
conecta al recurso.
Permite que los archivos y directorios creados adquieran los mismos permisos que su directorio
inherit permissions
padre, en lugar que obedezcan a los valores de create mask y/o directory mask
Muchas de las directivas de configuración de Samba aceptan el uso de variables de las cuales algunas son detalladas a continuación:
• %G : Grupo primario de %U
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 219
Source Linux
• %I : Dirección IP del cliente.
• %g : Grupo primario de %u
• %H : Directorio personal de %u
Tras terminar de editar el archivo de configuración de Samba es siempre importante verificar la sintaxis del mismo en busca de errores
o inconsistencias ejecutando:
# testparm
... el cual informará a través de la salida estándar de cualquier advertencia o error encontrado en la configuración.
Si todo está correctamente configurado se puede proceder a iniciar el servidor Samba como sigue:
# chkconfig smb on
# service smb start
En Debian y derivados:
# groupadd sistemas
# useradd -s /bin/false admin
# useradd -s /bin/false operador
Una vez creados los usuarios en el sistema Shadow, procedemos a crear la cuenta en el sistema de usuarios de Samba como sigue:
# smbpasswd -a admin
# smbpasswd -a operador
... lo cual crea la cuenta y le asigna una contraseña ingresada por el usuario desde el teclado. Este mismo procedimiento debe ser
seguido para todas las cuentas de usuario que pretendamos utilizar en Samba para el acceso a nuestros recursos compartidos.
Para lograr esta configuración de Samba como PDC, empezaremos creando un archivo de configuración vacío:
# cd /etc/samba
# mv smb.conf smb.conf.standalone
# touch smb.conf
[global]
security = user
netbios name = fileserver
server string = PDC Samba %v
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 220
Source Linux
workgroup = CONSULTORIANET
wins support = yes
domain master = yes
local master = yes
preferred master = yes
os level = 33
passdb backend = tdbsam
domain logons = yes
logon home = \\%L\%U
logon path = \\%L\profiles\%U
logon script = logon.bat
add machine script = /usr/sbin/useradd -s /bin/false %u
admin users = admin
time server = yes
log file = /var/log/samba/samba.log
log level = 2
max log size = 2000
[profiles]
path = /data/profiles
writable = yes
public = no
browsable = no
force group = users
[netlogon]
path = /data/netlogon
writable = no
public = no
browsable = no
[homes]
browseable = no
writable = yes
public = no
Este archivo de configuración de ejemplo muestra algunas directivas no vistas hasta ahora, las mismas que a continuación se pasan a
detallar:
Directiva Descripción
Fuerza a que Samba se convierta en el visualizador maestro de dominio, conteniendo las listas
de visualización de todas las subredes existentes mantenidas por visualizadores maestros
domain master locales.
Por lo general este valor se configura por defecto en yes si domain logons = yes, y debe
ser configurado con un valor de no si se ha de configurar Samba como BDC.
local master Instruye a Samba a que intente convertirse en el visualizador maestro local en una subred
procurando ser el ganador en cada una de las elecciones realizadas para asumir este rol.
Instruye a Samba para que se convierta en el visualizador maestro de preferencia para su grupo
preferred master de trabajo, forzando una elección en la cual él se presente con cierta ventaja.
Se recomienda usar esta directiva si se configura domain master = yes
os level Valor entero que representa el nivel de SO con el cual Samba se identifica en la red, lo que le ha
de permitir ganar elecciones de visualizador maestro. El valor puede variar entre 0 y 255.
Backend utilizado para el almacenamiento de passwords de Samba. Se recomienda usar
passdb backend
tdbsam cuando se configure como PDC.
domain logons Instruye a Samba a comportarse como controlador de dominio para servicios de estilo NT4.
logon home La ubicación del directorio personal del usuario cuando un cliente inicia sesión en el PDC
controlado por Samba.
La ubicación donde se almacenan los perfiles móviles. Si se desea deshabilitar la funcionalidad
logon path
de perfiles móviles debe especificarse un valor vacío en esta directiva (logon path = "")
logon script Script a ser descargado y ejecutado por los clientes que inician sesión en el PDC controlado por
Samba. La ruta del archivo especificado en esta directiva se toma como una ruta relativa en
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 221
Source Linux
base al recurso [netlogon] el cual debe ser declarado. El script debe utilizar saltos de línea
CR/LF al estilo DOS.
Script ejecutado por Samba cuando se agregue una máquina al dominio y aún no exista una
add machine script
cuenta UNIX que coincida con el nombre de máquina agregándole el símbolo $ al final.
Acorde a la configuración realizada, debemos asegurarnos que existan los directorios referenciados por los recursos [profiles] y
[netlogon] así como también considerar los permisos adecuados que el primero de ellos tenga para un correcto funcionamiento.
Es así que creamos los directorios y asignamos los propietarios correspondientes:
# mkdir /data/profiles
# mkdir /data/netlogon
# chown :users /data/profiles
Además dentro del directorio /data/netlogon creamos el script logon.bat con un contenido que permita conectar el directorio personal del
usuario como una unidad de red y transformando su formato al estilo DOS:
Ahora ya podemos revisar la sintaxis del archivo de configuración de Samba y reiniciar el servicio para hacer efectivos los cambios:
# testparm
# service smb restart
En Debian y derivados:
# testparm
# service smb restart
A partir de este momento el servidor Samba ya se encuentra listo para unir equipos al dominio.
El sistema de impresión CUPS administra la configuración de sus impresoras por defecto en el archivo /etc/cups/printers.conf, el cual
puede tener un contenido como el siguiente:
<DefaultPrinter EpsonMatricial>
Info Impresora matricial Epson LQ-1070+
DeviceURI parallel:/dev/lp0
Location Sala de reuniones
Shared Yes
State Idle
Accepting Yes
</Printer>
<Printer HPLaser>
Info Impresora laser HP Laserjet 920c
DeviceURI usb:/dev/usb/lp0
Location Oficina de gerencia
Shared Yes
State Idle
Accepting Yes
</Printer>
Si bien es este un modelo del archivo de configuración de impresoras de CUPS, éstas deben ser configuradas accediendo desde el
mismo servidor que corre CUPS a la URL http://localhost:631 usando un navegador Web. En aquella dirección se puede configurar las
impresoras y otras opciones de impresión de CUPS de una forma bastante amigable e intuitiva.
Configurar Samba para que sea capaz de compartir las impresoras ya definidas en el archivo de configuración de CUPS
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 222
Source Linux
/etc/cups/printes.conf resulta sencillo creando un contenido como el siguiente en el archivo /etc/samba/smb.conf:
[global]
security = user
netbios name = fileserver
server string = Servidor de archivos e impresion
workgroup = CONSULTORIANET
log file = /var/log/samba/samba.log
log level = 2
max log size = 2000
load printers = yes
printing = cups
printcap name = cups
[printers]
path = /var/spool/cups
public = no
printable = yes
Tras guardar los cambios, verificar la sintaxis del archivo de configuración y reiniciar el servicio Samba ya podremos acceder a las
impresoras compartidas desde otro equipo, por ejemplo un sistema Microsoft Windows XP:
# testparm
# service smb restart
En Debian y derivados:
# testparm
# service smb restart
2. Sincronizar los tiempos del servidor Samba y el AD (una diferencia de tiempos menor a 5 minutos es requisito de Kerberos).
Esto implica configurar el servicio NTP.
3. Configurar la resolución DNS acorde al dominio que controla el servidor AD. Asumimos que se trata del dominio
consultorianet.com y el nombre del servidor AD es win2k3.consultorianet.com.
5. Configurar Samba para usar el esquema de seguridad basado en Active Directory (ads) y otros parámetros adicionales.
Paso 1
Este primer es aplicable únicamente para los sistemas Debian y derivados que no contienen por defecto los paquetes requeridos para
completar esta configuración de Samba y Active Directory.
Desde la línea de comandos instalar todos los paquetes necesarios para este fin:
Paso 2
Un servidor AD por defecto trae consigo habilitado el servicio NTP para permitir la sincronización de tiempo con los clientes de la red.
Dado que el protocolo Kerberos se basa en una precisión de tiempo, la diferencia entre el cliente y el servidor no debe superar los 5
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 223
Source Linux
minutos, así que para ello nos aseguraremos de mantener sincronizado a nuestro servidor Samba como cliente NTP del servidor AD.
Esto lo logramos definiendo una directiva server en /etc/ntp.conf que apunte a la dirección IP del servidor AD, y dicha directiva sea
colocada en el primer nivel sobre todas las demás.
server 172.31.0.203
En la configuración arriba mostrada se asume que 172.31.0.203 es la dirección IP del servidor AD. Ahora detendremos el servicio NTP
por un instante, refrescaremos la hora del servidor Samba desde el servidor AD e iniciaremos nuevamente el servicio NTP:
En Debian o derivados:
# hwclock --systohc
Paso 3
Es necesario asegurarnos de tener la resolución correcta de los nombres del dominio AD, para lo cual utilizaremos la dirección del
controlador de dominio como el servidor DNS preferido del sistema Samba, editando como sigue el archivo /etc/resolv.conf:
search consultorianet.com
nameserver 172.31.0.203
Además es necesario definir el nombre FQDN de nuestro servidor Samba (samba.consultorianet.com) en el archivo /etc/hosts como
sigue:
127.0.0.1 localhost
172.31.0.20 samba.consultorianet.com samba
El mismo nombre de host debería también ser inscrito en la zona consultorianet.com que administra del servidor AD, con su respectiva
resolución inversa.
Validamos ahora la correcta configuración de resolución de nombres realizando algunas consultas básicas:
Paso 4
Active Directory utiliza un método de autenticación seguro basado en Kerberos, en base al cual se deben seguir también directivas de
configuración de este protocolo en el servidor Samba.
Para ello es necesario editar el archivo /etc/krb5.conf sobre el contenido que trae por defecto como se muestra a continuación resaltado
con negrita los valores a agregar:
...
...
[libdefaults]
# default_realm = ATHENA.MIT.EDU
default_realm = consultorianet.com
...
...
[realms]
consultorianet.com = {
kdc = win2k3.consultorianet.com:88
admin_server = win2k3.consultorianet.com:749
default_domain = consultorianet.com
}
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 224
Source Linux
...
[domain_realm]
.consultorianet.com = consultorianet.com
consultorianet.com = consultorianet.com
...
...
Para verificar que la configuración de Kerberos es la correcta, haremos una solicitud inicial de ticket como sigue (respetando las
mayúsculas):
# kinit administrador@consultorianet.com
... donde ingresaremos el password del usuario administrador del dominio consultorianet.com del Active Directory. Si esto funcionó
como se esperaba, el comando klist nos ha de brindar la información del ticket adquirido y mantenido en caché:
# klist
Paso 5
Configurar Samba para especifica el esquema de autenticación ads, de modo que las credenciales de usuarios sean validadas por el
controlador Active Directory. Para ello crearemos un archivo vacío y en él colocaremos el siguiente contenido:
# cd /etc/samba
# mv smb.conf smb.conf.cups
# touch smb.conf
[global]
workgroup = CONSULTORIANET
realm = consultorianet.com
preferred master = no
server string = Samba miembro de AD
security = ads
log file = /var/log/samba/samba.log
log level = 2
max log size = 1000
[homes]
browsable = no
public = no
writable = yes
comment = Directorio personal de usuarios
# testparm
Paso 6
Unirse al dominio desde la línea de comandos es bastante sencillo utilizando el comando net como sigue:
Si no se obtiene el mensaje 'Joined ... to ream ...' y en su lugar se obtiene algún otro mensaje de error, entonces alguno de los
procedimientos anteriores pudo haberse hecho incorrectamente. Es necesario volver al inicio y repasar cada uno de los pasos.
Paso 7
Winbind es un componente de la suite Samba que se encarga de mapear los usuarios de dominios NT como cuentas locales de un
sistema Linux.
A fin de poder validar los accesos al servidor Samba por usuarios del dominio -dando así permisos sobre los recursos compartidos- se
hace necesario configurar winbind, agregando las líneas resaltadas en negrita dentro del archivo de configuración de Samba como se
muestra debajo:
[global]
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 225
Source Linux
...
[homes]
...
...
# mkdir /home/CONSULTORIANET
Además se requiere también actualizar el archivo /etc/nsswitch.conf como sigue (resaltado en negrita):
En Debian y derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 226
Source Linux
3. Editando el archivo /etc/pam.d/common-session como sigue (agregar lo resaltado en negrita):
Paso 8
Una vez que se realizaron todos los pasos de configuración, revisamos la correcta sintaxis del archivo /etc/samba/smb.conf como buena
costumbre y de no encontrar errores procedemos a reiniciar el sevicio samba y winbind:
# testparm
# service smb restart
# service winbind restart
En Debian y derivados:
# testparm
# service smb restart
# service winbind restart
Para validar que winbind está trabajando de la manera correcta, los comandos wbinfo -u y wbinfo -g nos deben imprimir la lista
completa de usuarios y grupos disponibles en el dominio Active Directory:
# wbinfo -u
# wbinfo -g
Además para comprobar el correcto mapeo entre los usuarios/grupos del dominio y el sistema Shadow de usuarios/grupos locales, los
comandos getent passwd y getent group nos deben imprimir la lista de usuarios del sistema UNIX sumados a los del dominio
Active Directory, en un formato correspondiente al de los archivos /etc/passwd y /etc/group respectivamente:
# getent passwd
# getent group
Desde este momento el servidor Samba ya corre como miembro de un dominio Active Directory. Esto significa que los usuarios
existentes en el dominio, pueden usar sus credenciales de inicio de sesión ya validadas para acceder a alguno de los recursos
publicados por el servidor Samba ya sean éstos de datos o impresión.
De acuerdo a la configuración de prueba que hemos creado, el recurso especial [homes] está habilitado lo que permitiría a cualquier
usuario ingresar a su directorio personal utilizando su password del dominio Active Directory.
Precisamente esta es la prueba que se debe realizar para comprobar el éxito de esta configuración, accediendo desde un equipo
Windows a nuestro servidor Samba como sigue:
En cualquier de ambos casos el acceso debe ser exitoso y pudiendo incluso crear archivos y/o directorios dentro sin ningún problema.
smbstatus [opciones]
Imprime un reporte de las conexiones activas de Samba
Opciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 227
Source Linux
-u USER : Sólo muestra información relevante al usuario USER.
-p : Imprime una lista de los procesos smbd actuales de Samba.
Opciones:
Opciones:
smbclient [opciones]
smbclient <SERVICIO> [opciones]
Herramienta cliente SMB/CIFS al estilo ftp
Opciones:
El SERVICIO al cual se puede conectar tiene la forma //servidor/recurso donde servidor puede ser un nombre NetBIOS o dirección IP,
y recurso identifica el nombre del elemento ofrecido para compartición.
Ejemplo 42:
a) Consultar la IP a la que resuelve el nombre NetBIOS win2k3 y consultar el estado del nodo:
# nmblookup -S win2k3
# smbstatus
# nmblookup -A 172.31.0.20
e) Imprimir un listado de los recursos compartidos por el host de nombre NetBIOS win2k3 sin usar password de autenticación:
# smbclient -L win2k3 -N
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 228
Source Linux
f) Conectarse al servicio //win2k3/C$ utilizando las credenciales del usuario administrador:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 229
Source Linux
12.3. Compartición de archivos con NFS
Introducción a NFS
NFS es un protocolo de capa de aplicación desarrollado por Sun Microsystems con el propósito de ser utilizado como la base de un
servicio de sistemas de archivos distribuidos en red. Esto hace posible que varios clientes puedan acceder a un sistema de archivos
remoto en la red y usarlo como si se tratase de uno local. NFS en la práctica está conformado por un conjunto de servicios
NFS en su versión 2 y 3 basa su funcionamiento en el uso de servicios RPC para enrutar peticiones entre clientes y servidores. Dichos
servicios RPC son controlados por el demonio portmap el cual configura las conexiones para cada una de las llamadas solicitadas.
Los siguientes son los procesos RPC que conforman el servicio NFS en su conjunto:
• rpc.mountd : Administra las peticiones de montaje desde clientes NFS verificando que el sistema de archivos
solicitado esté actualmente exportado.
• rpc.nfsd : El servidor NFS que trabaja a nivel de kernel para satisfacer las demandas de los clientes.
• rpc.lockd : Proceso opcional que permite a los archivos bloquear archivos en el servidor.
• rpc.statd : Proceso que monitorea el servicio NFS informando a los clientes de su estado si éste se reincia de
manera abrupta.
• rpc.quotad : Proceso que brinda información de cuotas de usuarios para los clientes remotos.
• rpc.idmapd : Proceso que brinda al cliente y servidor NFSv4 llamadas que hacen la correspondencia entre sus
nombres NFSv4, los UIDs y GIDs locales.
La instancia de servidor NFS implica la ejecución de los procesos rpc.mountd, rpc.nfsd y opcionalmente rpc.rquotad. Mientras
que un servicio opcional se encarga de iniciar los procesos RPC complementarios como rpc.lockd y rpc.statd.
En Red Hat / CentOS y derivados, el script SysV nfs se encarga de lanzar los procesos de servidor NFS como rpc.nfsd,
rpc.mountd, rpc.idmapd y rpc.quotad, mientras que en Debian es el script nfs-kernel-server (que lo contiene el paquete
del mismo nombre) lanza los procesos rpc.nfsd y rpc.mountd.
De manera análoga en Red Hat / CentOS y derivados, el script SysV nfslock se encarga de lanzar los procesos RPC
complementarios como rpc.statd y rpc.lockd, mientras que en Debian el script SysV nfs-common lanza el proceso rpc.statd
únicamente.
Cuando se pretende correr un servidor NFS es recomendable lanzar los procesos RPC de apoyo, con el script nfslock (Red Hat) o
nfs-common (Debian) de la mano con el inicio del script nfs (Red Hat) o nfs-kernel-server (Debian); además también con la
ejecución previa del demonio portmap.
Si se pretende trabajar sólo como un cliente NFS sólo haría falta correr el demonio portmap y los procesos RPC de apoyo como nfslock
o nfs-common.
Así, una vez que ya se cuenta con el software requerido es necesario asegurarnos que los servicios básicos de NFS sean ejecutados
al arranque del sistema, ejecutando:
# chkconfig portmap on
# chkconfig nfslock on
# chkconfig nfs on
En Debian derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 230
Source Linux
De donde los servicios nfs o nfs-kernel-server no serán necesarios si pretendemos sólo trabajar como clientes NFS.
Exportación de directorios
El servidor NFS centra su configuración en el archivo /etc/exports el cual contiene las definiciones de los directorios que serán
exportados (compartidos) hacia la red bajo ciertas condiciones y modificadores.
Este archivo está conformado por entradas (una por línea) donde cada una de ellas tiene el siguiente formato:
Donde:
• DIRECCIÓN : Dirección de uno o más hosts remotos autorizados a usar este recurso.
Las direcciones pueden ser especificadas como hosts únicos (Ejm: 172.10.30.2, sam.georgia.edu), segmentos de red (Ejm:
192.168.32.0/24, 10.32.0.0/16), o expresiones formadas por comodines (Ejm: *.georgia.edu, *.edu.*).
Con la revisión de la sintaxis de este archivo, podemos generar un ejemplo de directorios exportados como sigue:
/data/principal 172.17.30.0/24(ro,root_squash)
/home *.consultorianet.com(rw,no_root_squash) *.unmsm.edu.pe(ro,all_squash)
Una vez que se definimos los directorios a exportar, debemos indicar al servidor NFS que haga efectivas estas exportaciones
ejecutando:
# exportfs -a
Luego desde un equipo cliente podremos consultar los recursos exportados por el servidor NFS:
# showmount -e 172.17.30.1
El ejemplo anterior asume que el servidor NFS tiene IP 172.17.30.1, y una vez que comprobamos qué recursos exportados son
accesibles para nuestro host, podemos proceder a montarlo en un directorio local como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 231
Source Linux
12.4. Servidor FTP seguro
El protocolo FTP
File Transfer Protocol (FTP), es un protocolo de nivel de aplicación que utiliza conexiones TCP en la capa de transporte. Este protocolo
es uno de los más antiguos hoy vigentes y fue desarrollado para hacer posible la transferencia de archivos en un modelo
cliente/servidor.
Para hacer posible la comunicación entre un cliente y servidor, el protocolo FTP soporta mecanismos de autenticación con un nombre
de usuario y password. Bajo este modelo de autenticación existe la posibilidad que los servidores FTP acepten un nombre de usuario
válido sólo para conexiones anónimas sin ningún password válido asociado, donde por lo general dicho nombre de usuario suele ser
ftp o anonymous.
Es así que se llama servidor FTP anónimo a aquel que acepta el inicio de sesión de las cuentas ftp o anonymous (o cualquier otra que
se defina como anónima) sin una contraseña asociada a dicho usuario.
El protocolo FTP maneja dos canales de comunicación entre cliente y servidor: el canal de control y el canal de datos. El canal de
control está diseñado para que a través de él se envíen y reciban comandos FTP, instrucciones y información de estado, etc, mientras
que el canal de datos está diseñado exclusivamente para el tránsito de datos que son cargados o descargados del servidor.
Este modo representa un problema de seguridad para el cliente pues éste debe aceptar cualquier conexión entrante para un puerto
mayor a 1024, lo que se convierte en un peligro potencial si el cliente está conectado a una red grande como Internet.
Por cada nueva transferencia el cliente debe enviar un comando PASV o PORT al servidor según el modo en el que haya establecido
previa conexión, para así reiniciar el proceso de negociación de puertos de transmisión de datos.
En Debian y derivados:
La instalación del paquete vsftpd crea por defecto el archivo de configuración /etc/vsftpd/vsftpd.conf en Red Hat y derivados, mientras
que el archivo /etc/vsftpd.conf en Debian y derivados.
Haremos un backup del archivo original y crearemos uno vacío para crear dentro un contenido básico como el mostrado líneas más
abajo:
# mv /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.orig
# touch /etc/vsftpd/vsftpd.conf
En Debian y derivados:
# mv /etc/vsftpd.conf /etc/vsftpd.conf.orig
# touch /etc/vsftpd.conf
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 232
Source Linux
listen=YES
anonymous_enable=YES
anon_max_rate=30000
ftp_username=ftp
local_enable=YES
write_enable=YES
user_config_dir=/etc/vsftpd_users/
local_umask=0022
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
ftpd_banner=Bienvenidos al servidor FTP de Consultorianet
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
session_support=YES
Directiva Descripción
Si es YES entonces vsftpd se ejecuta de forma independiente, si es NO se ejecuta bajo el
listen
control de un demonio como inetd o xinetd.
anonymous_enable Soporte del FTP anónimo.
anon_max_rate Tasa máxima de tranferencia en bytes por segundo, permitida para clientes anónimos.
ftp_username Define el nombre de usuario utilizado para FTP anónimos.
local_enable Soporte del inicio de sesión de usuarios locales del sistema.
write_enable Soporte de operaciones de escritura FTP (Ejm: cargar, renomrar, eliminar, etc).
user_config_dir Directorio donde se han de buscar archivos de configuración cuyos nombres coincidan con los
usuarios que se conectan para definir en ellos directivas específicas de vsftpd por usuario.
local_umask Define la máscara de permisos para archivos y/o directorios recién creados.
xferlog_enable Guarda un registro de archivos cargados/descargados del servidor FTP.
xferlog_file Define la ruta del archivo de registro de cargas/descargas del servidor FTP.
xferlog_std_format Genera el registro de cargas/descargas en un formato estándar común de otros demonios ftp.
ftpd_banner Define un mensaje de bienvenida al servicio FTP.
chroot_list_enable Habilita el enjaulamiento a los usuarios definidos en una lista dentro de un archivo.
chroot_list_file Archivo que contiene la lista de usuarios enjaulados.
Almacena en los logs del sistema los inicios de sesión de los usuarios que pueden ser
session_support
consultados con el comando last
✔ Se habilita el FTP anónimo sólo para descargar ficheros -no es posible realizar operaciones de escritura- y se les limita la
tasa de transferencia a un límite que no sobrepase los 30 KB/s.
✔ Se pueden crear archivos de configuración personalizados por usuario creando archivos que lleven sus nombres dentro del
directorio /etc/vsftpd_users y en cada uno de ellos definir directivas que puedan sobreescribir los valores definidos en el archivo
/etc/vsftpd.conf
Siguiendo con la configuración, podremos crear archivos de configuración personalizados para los usuarios eruiz y admin como sigue:
# mkdir /etc/vsftpd_users
# echo "local_max_rate=50000" > /etc/vsftpd_user/eruiz
# echo "local_max_rate=75000" > /etc/vsftpd_user/admin
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 233
Source Linux
Además podemos ir definiendo una lista de usuarios (eruiz, mflores, atello y jlora) que deseamos mantener enjaulados en sus
directorios de trabajo cuando inicien sesión en el servidor FTP:
Luego de terminar de editar los archivos de configuración se puede proceder a reiniciar el demonio vsftpd y hacer pruebas de acuerdo
a las configuraciones realizadas:
# chkconfig vsftpd on
# service vsftpd restart
En Debian y derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 234
Source Linux
12.5. Reportes de tráfico FTP
La capacidad de generar reportes de los servicios de red instalados en un servidor resultan ser un requerimiento muy común en la
mayoría de organizaciones, más aún si se tratan de servicios de amplio uso público, tal como es el caso de los servidores FTP.
Por ello, en esta sección revisaremos el proceso de instalación y configuración de una excelente herramienta de generación de
reportes llamada AWStats, la que nos podrá generar informes en formatos bastante amigables para el administrador.
Descarga e instalación
AWStats puede ser descargado desde su sitio Web oficial (http://awstats.sourceforge.net), como un archivo tarball, o podemos
simplificar la instalación desde repositorios.
Este paquete está incluido en los repositorios oficiales para Debian, pero para Red Hat / CentOS no sucede lo mismo aunque no
obstante existe el repositorio DAG que sí incluye este paquete.
En Red Hat / CentOS y derivados, procederemos a crear un archivo de repositorio /etc/yum.repos.d/dag.repo con un contenido como el
siguiente:
[dag]
name=dag
gpgcheck=0
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag/
enabled=0
Este procedimiento es el recomendado para agilizar el proceso de resolución de dependencias de software y configuración
predeterminada del paquete.
Dentro del directorio /etc/awstats debe existir un archivo de nombre awstats.model.conf (Red Hat / CentOS) o awstats.conf (en Debian) el
cual contiene un modelo de la configuración de AWStats.
Crearemos una copia a partir de éste con un nombre como awstats.ftp.conf:
# cd /etc/awstats
# cp awstats.model.conf awstats.ftp.conf
En Debian y derivados:
# cd /etc/awstats
# cp awstats.conf awstats.ftp.conf
Editaremos este archivo awstats.ftp.conf creado y modificaremos su contenido de acuerdo al texto debajo resaltado en negrita :
...
...
LogFile="/var/log/vsftpd.log"
...
...
LogType=F
...
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 235
Source Linux
LogFormat="%time3 %other %host %bytesd %url %other %other %method %other %logname %other %code
%other %other"
...
...
LogSeparator="\s"
...
...
SiteDomain="ftp.consultorianet.com"
...
...
NotPageList=""
...
...
1. El paquete awstats instalado trajo consigo un archivo de configuración modelo para Apache ubicado en
/etc/httpd/conf.d/awstats.conf, del cual debemos modificar su contenido según el texto resaltado en negrita:
En Debian y derivados
1. El paquete awstats instalado trae consigo un archivo de configuración modelo para Apache ubicado en
/usr/share/doc/awstats/examples/apache.conf, del cual debemos crear una copia en /etc/apache2/conf.d/awstats.conf y modificar su
contenido según el texto resaltado en negrita:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 236
Source Linux
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Finalmente ya tenemos lista la configuración de AWStats para los logs del servidor FTP, sólo nos resta instruir a través de la línea de
comandos la generación de estadísticas recientes a partir del archivo /var/log/vsftpd.log configurado, haciendo uso del script awstats.pl
que viene con el paquete awstats como sigue:
En Debian y derivados:
El script awstats.pl genera las estadísticas por defecto en /var/www/awstats (en Red Hat / CentOS) o en /var/lib/awstats (en Debian), las
cuales son representadas por archivos de textos poco o nada entendibles.
Por ello la forma correcta de visualizar estas estadísticas generada es a través de la ejecución de un script CGI desde Apache
accediendo con un navegador a una URL como la siguiente:
http://172.17.30.1/awstats/awstats.pl?config=ftp
... donde se asume que el host donde se ejecuta el servidor FTP, Web y la herramienta AWStats, posee la IP 172.17.30.1.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 237
Source Linux
# invoke-rc.d webmin start
2. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de AWStats
rellenando con la URL de descarga (link obtenido desde la Web oficial de AWStats) el campo de nombre 'From ftp or http
URL' como sigue:
2. Una vez instalado el módulo acceder a 'System -> AWStats Logfile Analyzer' y revisar las opciones de configuración del
módulo de AWStats a través de su interfaz gráfica amigable.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 238
Source Linux
12.6. Laboratorio N° 12
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Teniendo configurado a Samba como servidor de impresión, configurar el recurso especial [print$] para proveer los
drivers de la impresora compartida de modo tal que estos se puedan instalar de manera automática por las estaciones de
trabajo Windows al conectar con el recurso de impresión compartido.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 239
Source Linux
12.6.1. Solución del laboratorio N° 12
1. Teniendo configurado a Samba como servidor de impresión, configurar el recurso especial [print$] para proveer los
drivers de la impresora compartida de modo tal que estos se puedan instalar de manera automática por las estaciones de
trabajo Windows al conectar con el recurso de impresión compartido.
Del primero de ellos, al extraer su contenido se encontrará dentro el directorio i386 de donde se deben copiar al directorio
/usr/share/cups/drivers los siguientes archivos:
• cups6.inf
• cups6.ini
• cupsps6.dll
• cupsui6.dll
Del segundo paquete tras ser instalado en un sistema Windows, deben encontrarse y copiarse al sistema Linux al directorio
/usr/share/cups/drivers los siguientes archivos:
• ps5ui.dll
• pscript.hlp
• pscript.ntf
• pscript5.dll
Todos estos archivos deben ser copiados con aquellos nombres exactamente iguales, respectando las minúsculas tal como
están, no deben ser alteradas a mayúsculas ninguna de sus letras de esos archivos.
[global]
security = user
netbios name = fileserver
server string = Servidor de archivos e impresion
workgroup = CONSULTORIANET
log file = /var/log/samba/samba.log
log level = 2
max log size = 2000
load printers = yes
printing = cups
printcap name = cups
[printers]
path = /var/spool/cups
public = no
printable = yes
[print$]
path = /etc/samba/drivers
browseable = yes
public = no
read only = yes
write list = root
# mkdir /etc/samba/drivers
+ Ahora será necesario asignar una contraseña de Samba al usuario root, reiniciar el servicio para aplicar los cambios al
fichero de configuración y luego realizar la configuración de drivers CUPS en el recurso compartido como sigue:
# smbpasswd -a root
# service smb restart
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 240
Source Linux
# cupsaddsmb -U root -a -v
En Debian y derivados:
# smbpasswd -a root
# invoke-rc.d samba restart
# cupsaddsmb -U root -a -v
Si este último procedimiento no hubiese generado ningún mensaje de error, ya habremos logrado el objetivo deseado. Ahora
tan sólo bastará acceder desde un equipo Windows a nuestro servidor Samba, conectarnos a una de las impresoras
compartidas y veremos cómo se instala automáticamente el driver necesario para dicha impresora, de modo tal que quede
lista para usarla.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 241
Source Linux
Unidad 13: Servidor Web y OpenSSL
13.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Comprender los componentes y forma de trabajo de una Infraestructura de Clave Pública, los certificados digitales y
OpenSSL.
✔ Implementación de un servidor Web básico a través del software Apache.
✔ Configuración de Apache para publicación de Hosts Virtuales y Sitios seguros con OpenSSL.
✔ Saber generar reportes gráficos amigables sobre el tráfico de visitas de los sitios Web publicados por Apache.
Propósito y funcionalidad
La tecnología PKI permite a los usuarios autenticarse frente a otros usuarios y usar la información de los certificados de identidad
(por ejemplo, las claves públicas de otros usuarios) para cifrar y descifrar mensajes, firmar digitalmente información, garantizar el
no repudio de un envío, y otros usos.
En una operación criptográfica que use infraestructura PKI, intervienen conceptualmente como mínimo las siguientes partes:
Las operaciones criptográficas de clave pública, son procesos en los que se utilizan unos algoritmos de cifrado que son conocidos
y están accesibles para todos. Por este motivo la seguridad que puede aportar la tecnología PKI, está fuertemente ligada a la
privacidad de la llamada clave privada y los procedimientos operacionales o políticas de seguridad aplicados.
Es de destacar la importancia de las políticas de seguridad en esta tecnología, puesto que ni los dispositivos más seguros ni los
algoritmos de cifrado más fuerte sirven de nada si por ejemplo una copia de la clave privada protegida por una tarjeta criptográfica
(del inglés 'smart card') se guarda en un disco duro convencional de un PC conectado a Internet.
Componentes
Los componentes más habituales de una infraestructura de clave pública son:
• La autoridad de certificación (o, en inglés, CA, Certificate Authority): es la encargada de emitir y revocar certificados. Es
la entidad de confianza que da legitimidad a la relación de una clave pública con la identidad de un usuario o servicio.
• La autoridad de registro (o, en inglés, RA, Registration Authority): es la responsable de verificar el enlace entre los
certificados (concretamente, entre la clave pública del certificado) y la identidad de sus titulares.
• Los repositorios: son las estructuras encargadas de almacenar la información relativa a la PKI. Los dos repositorios más
importantes son el repositorio de certificados y el repositorio de listas de revocación de certificados. En una lista de
revocación de certificados (o, en inglés, CRL, Certificate Revocation List) se incluyen todos aquellos certificados que por
algún motivo han dejado de ser válidos antes de la fecha establecida dentro del mismo certificado.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 242
Source Linux
• La autoridad de validación (o, en inglés, VA, Validation Authority): es la encargada de comprobar la validez de los
certificados digitales.
• La autoridad de sellado de tiempo (o, en inglés, TSA, TimeStamp Authority): es la encargada de firmar documentos con
la finalidad de probar que existían antes de un determinado instante de tiempo.
• Los usuarios y entidades finales son aquellos que poseen un par de claves (pública y privada) y un certificado asociado a
su clave pública. Utilizan un conjunto de aplicaciones que hacen uso de la tecnología PKI (para validar firmar digitales,
cifrar documentos para otros usuarios, etc.)
• Todo certificado válido, ha de ser emitido por una Autoridad de certificación reconocida, que garantiza la validez de la
asociación entre el tenedor del certificado y el certificado en sí.
• El poseedor de un certificado es responsable de la conservación y custodia de la clave privada asociada al certificado
para evitar el conocimiento de la misma por terceros.
• Las entidades de registro se encargan de la verificación de la validez y veracidad de los datos del que pide un certificado,
y gestionan el ciclo de vida de las peticiones hacia las AC's.
• El poseedor de un certificado válido puede usar dicho certificado para los usos para los que ha sido creado según las
políticas de seguridad.
• Toda operación que realice el poseedor de un certificado ha de realizarse de forma presencial por parte del poseedor del
certificado y dentro del hardware de cliente (ya sea la tarjeta criptográfica o PKCS#11 u otro dispositivo seguro como el
fichero seguro o PKCS#12, etc.
• Las comunicaciones con seguridad PKI no requieren del intercambio de ningún tipo de clave secreta para su
establecimiento, por lo que se consideran muy seguras si se siguen las políticas de seguridad pertinentes.
Criptografía asimétrica
La criptografía asimétrica es el método criptográfico que usa un par de claves para el envío de mensajes. Las dos claves pertenecen a
la misma persona a la que se ha enviado el mensaje. Una clave es pública y se puede entregar a cualquier persona, la otra clave es
privada y el propietario debe guardarla de modo que nadie tenga acceso a ella. Además, los métodos criptográficos garantizan que esa
pareja de claves sólo se puede generar una vez, de modo que se puede asumir que no es posible que dos personas hayan obtenido
casualmente la misma pareja de claves.
Si el remitente usa la clave pública del destinatario para cifrar el mensaje, una vez cifrado, sólo la clave privada del destinatario podrá
descifrar este mensaje, ya que es el único que la conoce. Por tanto se logra la confidencialidad del envío del mensaje, nadie salvo el
destinatario puede descifrarlo.
Si el propietario del par de claves usa su clave privada para cifrar el mensaje, cualquiera puede descifrarlo utilizando su clave pública.
En este caso se consigue por tanto la identificación y autenticación del remitente, ya que se sabe que sólo pudo haber sido él quien
empleó su clave privada (salvo que alguien se la hubiese podido robar). Esta idea es el fundamento de la firma electrónica.
Los sistemas de cifrado de clave pública o sistemas de cifrado asimétricos se inventaron con el fin de evitar por completo el problema
del intercambio de claves de los sistemas de cifrado simétricos. Con las claves públicas no es necesario que el remitente y el
destinatario se pongan de acuerdo en la clave a emplear. Todo lo que se requiere es que, antes de iniciar la comunicación secreta, el
remitente consiga una copia de la clave pública del destinatario. Es más, esa misma clave pública puede ser usada por cualquiera que
desee comunicarse con su propietario. Por tanto, se necesitarán sólo N pares de claves por cada N personas que deseen comunicarse
entre sí.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 243
Source Linux
Algunos de los algoritmos de técnicas de clave asimétrica son:
• Diffie-Hellman
• RSA
• DSA
• ElGamal
Certificados digitales
Un certificado digital es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la
vinculación entre la identidad de un sujeto o entidad y su clave pública.
Si bien existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UIT-T X.509. El
certificado contiene usualmente el nombre de la entidad certificada, número de serie, fecha de expiración, una copia de la clave pública
del titular del certificado (utilizada para la verificación de su firma digital) y la firma digital de la autoridad emisora del certificado de
forma que el receptor pueda verificar que esta última ha establecido realmente la asociación.
Emisores de certificados
Cualquier individuo o institución puede generar un certificado digital, pero si éste emisor no es reconocido por quienes interactúen
con el propietario del certificado, el valor del mismo es prácticamente nulo. Por ello los emisores deben acreditarse: así se
denomina al proceso por el cuál entidades reconocidas, generalmente públicas, otorgan validez a la institución certificadora, de
forma que su firma pueda ser reconocida como fiable, transmitiendo esa fiabilidad a los certificados emitidos por la citada
institución.
La gran mayoría de los emisores tiene fines comerciales, y otros, gracias al sistema de anillo de confianza pueden otorgar
gratuitamente certificados en todo el mundo, como:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 244
Source Linux
Pero para que un certificado digital tenga validez legal, el prestador de Servicios de Certificación debe acreditarse en cada país de
acuerdo a la normativa que cada uno defina.
OpenSSL
OpenSSL es un proyecto de software desarrollado por los miembros de la comunidad Open Source para libre descarga y está basado
en SSLeay desarrollado por Eric Young y Tim Hudson.
Consiste en un robusto paquete de herramientas de administración y librerías relacionadas con la criptografía, que suministran
funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS).
Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la
seguridad , como el Transport Layer Security (TLS). Este paquete de software es importante para cualquiera que esté planeando usar
cierto nivel de seguridad en su máquina con un sistema operativo Libre basado en GNU/Linux. OpenSSL también nos permite crear
certificados digitales que podremos aplicar a nuestro servidor, por ejemplo Apache.
El protocolo SSL
Secure Sockets Layer -Protocolo de Capa de Conexión Segura- (SSL) y Transport Layer Security -Seguridad de la Capa de
Transporte- (TLS), su sucesor, son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente
Internet.
Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El término "SSL" según
se usa aquí, se aplica a ambos protocolos a menos que el contexto indique lo contrario.
SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía.
Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin
autenticar; la autenticación mutua requiere un despliegue de infraestructura de claves públicas (o PKI) para los clientes. Los
protocolos permiten a las aplicaciones cliente-servidor comunicarse de una forma diseñada para prevenir escuchas
(eavesdropping), la falsificación de la identidad del remitente (phishing) y alterar la integridad del mensaje.
SSL implica una serie de fases básicas:
Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones
actuales proporcionan las siguientes opciones:
• Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza;
• Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple
DES o AES (Advanced Encryption Standard);
• Con funciones hash: MD5 o de la familia SHA.
Este primer paso debería ser ejecutado sólo una vez por la entidad que pretende ser una Autoridad Certificadora, guardando
con mucho cuidado los archivos creados en los pasos siguientes. Esta entidad será la que posteriormente permite firmar
solicitudes y entregar certificados solicitados por terceras partes.
1.1 Ajustar el archivo de configuración de OpenSSL (/etc/pki/tls/openssl.cnf en Red Hat y derivados, o /etc/ssl/openssl.cnf en
Debian y derivados), ajustando las siguientes directivas debajo resaltadas:
...
...
dir = /root/sslCA
...
...
default_days = 3650
...
...
countryName_default = PE
stateOrProvinceName_default = Lima
localityName_default = Wahoo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 245
Source Linux
1.2 Crear los directorios -y ajustar sus permisos- donde se creará la CA y otros archivos de certificados:
# mkdir /root/sslCA
# chmod 700 /root/sslCA
# cd /root/sslCA
# mkdir certs private newcerts
1.3 Crear dos archivos, uno serial y otro index.txt, usados en la creación de certificados:
# openssl req -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem -config \
> /etc/pki/tls/openssl.cnf
En Debian y derivados:
# openssl req -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem -config \
> /etc/ssl/openssl.cnf
1.5 Tras la ejecución del comando openssl se debe completar una serie de preguntas como sigue:
Lo resaltado en negrita es lo que correspondería ingresar al usuario desde el teclado. El significado de los campos que
forman parte del certificado se describen debajo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 246
Source Linux
Organization Name El nombre legal exacto de la organización. No debe ser abreviado. Consultorianet SRL
Opcional para información adicional de la unidad de la
Organizational Unit Sistemas
organización.
Dado que éste es nuestro certificado raíz, nombrarlo de forma Consultorianet Certification
Common Name
similar al ejemplo de al lado. Authority
arengifo@consultorianet.co
Email Address La dirección e-mail de contacto a la CA
m
1.6 Verificar que se haya creado el certificado de la CA correctamente visualizando su contenido como sigue:
2.1 Crear una llave y solicitud de firma de certificado (CSR, Certificate Signing Request). Este paso debería ser ejecutado
por una tercera parte, que puede estar solicitando un certificado a nuestra CA previamente creada. A continuación
asumiremos que en el mismo host donde se creó la CA se creará también la solicitud:
En Debian y derivados:
2.2 Tras la ejecución del comando openssl se debe completar una serie de preguntas como sigue:
Lo resaltado en negrita es lo que correspondería ingresar al usuario desde el teclado. El significado de los campos que
forman parte del certificado se describen debajo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 247
Source Linux
La ciudad donde se ubica la organización. No puede ser
City or Locality Name Iquitos
abreviado.
Organization Name El nombre legal exacto de la organización. No debe ser abreviado. Hnos. Soto SRL
Opcional para información adicional de la unidad de la
Organizational Unit Gerencia
organización.
Debe corresponder al nombre de host (Ejm:
www.sotohnos.com.pe) o dirección IP que hará uso del certificado
Common Name www.sotohnos.com.pe
una vez expedido. Si se desea utilizar el certificado para varios
subdominios se puede especificar como *.sotohnos.com.pe
Email Address La dirección e-mail de contacto del administrador. info@sotohnos.com.pe
Opcional. Password que será asociado al certificado para posibles
Challenge Password -
usos futuros en revocaciones. Puede ser dejado en blanco
Opcional. Puede contener un nombre alternativo de la entidad
Company Name -
solicitante de certificados.
2.3 Verificar que se haya creado correctamente el CSR (solicitud de certificado) visualizando su contenido como sigue:
2.4 Una vez creado el CSR, éste ya podría ser enviado a la CA para su revisión y correspondiente firma a fin de recibir de
parte de ellos el certificado solicitado.
3.1 Este paso debe ser realizado por la CA firmando la solicitud de certificado enviada por una tercera parte y generando el
respectivo certificado que se les enviará de vuelta.
En Debian y derivados:
3.2 Tras la ejecución del comando openssl se debe confirmar dos preguntas como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 248
Source Linux
keyid:79:B2:8F:D4:A7:EB:A8:AA:1D:A4:06:08:8B:D6:58:0D:4A:65:91:3B
3.3 Verificar que se haya creado correctamente el certificado visualizando su contenido como sigue:
3.4 Ahora este certificado creado, apache-cert.pem, ya puede ser utilizado por algún servicio (por ejemplo servicio Web con
Apache) que atienda peticiones bajo el nombre de host www.sotohnos.com.pe
Importante:
• El proceso de creación de una CA, solicitudes y certificados desde línea de comandos según lo estudiado, puede resultar
algo tedioso para algunos usuarios.
Es por ello que de manera alterna se puede utilizar una herramienta gráfica tal como TinyCA, la que nos facilitará la creación
de Autoridades Certificadoras y certificados digitales.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 249
Source Linux
13.3. Servidor Web Apache
Introducción
Un servidor web es un programa que implementa el protocolo HTTP (hypertext transfer protocol). Este protocolo está diseñado para
transferir lo que llamamos hipertextos, páginas web o páginas HTML (hypertext markup language): textos complejos con enlaces,
figuras, formularios, botones y objetos incrustados como animaciones o reproductores de musica.
Sin embargo, el hecho de que HTTP y HTML estén íntimamente ligados no debe dar lugar a confundir ambos términos. HTML es un
lenguaje de programación y un formato de archivo y HTTP es un protocolo.
Cabe destacar el hecho de que la palabra servidor identifica tanto al programa como a la máquina en la que dicho programa se ejecuta.
Existe, por tanto, cierta ambigüedad en el término, aunque no será difícil diferenciar a cuál de los dos nos referimos en cada caso. En
este artículo nos referiremos siempre a la aplicación.
Un servidor web se encarga de mantenerse a la espera de peticiones HTTP llevada a cabo por un cliente HTTP que solemos conocer
como navegador. El navegador realiza una petición al servidor y éste le responde con el contenido que el cliente solicita. A modo de
ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste realiza una petición HTTP al servidor de dicha dirección. El servidor
responde al cliente enviando el código HTML de la página; el cliente, una vez recibido el código, lo interpreta y lo muestra en pantalla.
Como vemos con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y
la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo
ninguna interpretación de la misma.
Sobre el servicio web clásico podemos disponer de aplicaciones web. Éstas son fragmentos de código que se ejecutan cuando se
realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayoría de las ocasiones para realizar aplicaciones web. La
razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad adicional, como sí
ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador web básico
puede utilizar este tipo de aplicaciones.
Algunos conceptos relacionados con las aplicaciones web son:
• PHP
• ASP
• Perl
• CGI
• .NET
• JSP (Tecnología Java )
La fundación Apache
La fundación Apache tiene a su cargo el desarrollo y mantenimiento de una serie de proyectos Open Source cuyo sitio Web oficial es:
http://www.apache.org
Si Ud. aprecia con algo de calma el sitio Web apreciará que existen muchos proyectos Geronimo, Jakarta, SpamAssassin, Tomcat,
HTTP Server, entre otros más. Comúnmente se le suele conocer simplemente como Apache al servidor Web por excelencia para
sistemas Unix.
Actualmente se mantienen dos ramas de desarrollo del servidor Web Apache siendo estas la versión 1.3.x y la 2.x (para ser exactos en
realidad se mantienen ya 3 ramas: 1.3.x, 2.0.x y 2.2.x).
La diferencia entre las ramas 1.3.x y la 2.x radica en aspectos técnicos como el modelo de paralelismo que cambió de funcionar bajo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 250
Source Linux
múltiples procesos en 1.3.x (prefork) a un nuevo esquema multihebrado en 2.x (worker). Además se cambió también el mecanismo de
encadenamiento de los módulos por filtros que permite ordernar los mismos sabiendo cuál de ellos corre primero sin crear colisiones
posteriores.
Este documento asumirá que se trabaja con la rama 2.0.x del servidor Web Apache.
Instalación de Apache
El procedimiento de instalación de Apache es sencillo:
En Debian y derivados:
Arquitectura de Apache
Un cambio resaltante que se introdujo en Apache 2.0.x fue la introducción de los MPMs. Para enteder qué son los MPMs primero debe
entenderse un poco cómo trabajaba Apache en la versión 1.3.x.
En la rama 1.3.x la naturaleza del desarrollo de Apache lo caracterizaba porque el proceso padre se bifurcaba creando así varios
procesos hijos los mismos que se encargaban de atender las solicitudes de clientes. Así, se debían crear tantos procesos hijos como
solicitudes simultáneas se necesitasen atender. Esto tenía como desventaja un mal desempeño en plataformas que no estaban
centradas en proceso tal como es el caso de Windows, creándose así la idea de manejar la arquitectura de Apache a través de los
MPMs.
MPM se entiende como Multi-Processing Modules y son una serie de módulos que se encargarán de monitorear la creación o
eliminación de procesos hijos o hilos dependiendo del MPM usado. Los MPMs existentes son:
Estos son los MPMs más resaltantes para la plataforma Unix, sin embargo existen otros más como el MPM winnt para la plataforma
Windows, y algunos otros más que pueden ser especificados en el momento de la compilación: "./configure --help | less"
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 251
Source Linux
Directorio que contiene enlaces simbólicos a los archivos *.conf
y *.load del directorio /etc/apache2/mods-available de modo tal
- /etc/apache2/mod-enabled
que estos enlaces representen los módulos habilitados en la
configuración de Apache.
Directorio que contiene archivos de configuración disponibles
- /etc/apache2/sites-available
de Hosts Virtuales de Apache.
Directorio que contiene enlaces simbólicos a los archivos del
directorio /etc/apache2/sites-available de modo tal que estos
- /etc/apache2/sites-enabled
enlaces representen los Hosts Virtuales habilitados en la
configuración de Apache.
Enlace simbólico al directorio donde se almacenan los logs de
/etc/httpd/logs -
Apache.
Enlace simbólico al directorio donde se almacenan los módulos
/etc/httpd/modules -
de Apache.
Enlace simbólico al directorio donde se almacenan el archivo
/etc/httpd/run -
PID de Apache cuando está en ejecución.
/etc/httpd/conf/httpd.conf /etc/apache2/apache2.conf Archivo de configuración principal de Apache.
Archivo de configuraciones personalizadas de usuarios. Por
- /etc/apache2/httpd.conf
defecto vacío.
- /etc/apache2/ports.conf Archivo de configuración de los puertos de escucha de Apache.
El archivo de configuración principal de Apache suele dividirse en otros que contienen directivas específicas a ciertos propósitos como
sucede en Debian, SuSE u otras distribuciones.
Sin tomar en cuenta la separación en múltiples archivos, la configuración principal de Apache suele organizarse de la siguiente forma
dentro del archivo:
Directivas de configuración
general
Directivas de configuración de
hosts virtuales
Directivas de configuración de
hosts virtuales
...
...
...
Directivas de configuración de
hosts virtuales
Es así que nosotros en este documento empezaremos a detallar las directivas de configuración clasificadas en este esquema de modo
tal que pueda facilitarse la lectura y comprensión por parte del lector.
Es importante entender que cada directiva tendrá un contexto bajo el cual funciona. Los contextos existentes son:
Contexto de contenedor
Son aquellas directivas que están contenidas dentro de contenedores de similar sintaxis a etiquetas HTML. Existen los siguientes
contenedores:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 252
Source Linux
• <Directory ...> ... </Directory>
• <DirectoryMatch ...> ... </DirectoryMatch>
• <Files ...> ... </Files>
• <FilesMatch ...> ... </FilesMatch>
• <Location ...> ... </Location>
• <LocationMatch ...> ... </LocationMatch>
• <Limit ...> ... </Limit>
AccessFileName
Permite definir el nombre del archivo de configuración de ámbito de directorio cuyo valor por defecto es .htaccess. Apache
automáticamente verificará la existencia de un archivo con este nombre en cada directorio hacia el cual se dirija una consulta de
acceso por parte de los clientes.
De este modo si Apache debe servir un archivo index.html ubicado en /var/www/html/htdocs/ entonces automáticamente se realizará
la búsqueda del archivo .htaccess en los siguientes directorios en el orden mostrado:
1. /.htaccess
2. /srv/.htaccess
3. /var/www/html/.htaccess
4. /var/www/html/htdocs/.htaccess
Si se desea deshabilitar la verificación de este archivo por cada directorio recursivo entonces la siguiente configuración se lo
permitiría:
<Directory />
AllowOverrride None
</Directory>
AddDefaultCharset
Esta directiva permite definir el carácter por defecto de la cabecera Content-Type que envía Apache a los clientes.
Cuando su valor es On entonces por defecto se envía iso-8859-1 como el juego de caracteres a no ser que se especifique otro
valor distinto. Ejemplos:
AddDefaultCharset On
AddDefaultCharset On utf-8
DefaultType
Esta directiva permite definir un tipo de contenido por defecto, de modo que Apache utiliza un tipo MIME determinado cuando
recibe una solicitud de un documento de un tipo de archivo desconocido o cuyo tipo MIME no se pudo asociar con los disponibles
para el servidor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 253
Source Linux
Contexto : Todos
Si por ejemplo se decide almacenar un gran número de archivos de texto plano que carecen de extensión entonces puede crearse
un contenedor <Directory> y dentro de éste definir la directiva DefaultType como sigue:
DefaultType text/plain
DocumentRoot
Esta directiva define el directorio de mayor nivel para los archivos servidor por Apache.
Ejemplo:
DocumentRoot "/var/www/html/htdocs"
DirectoryIndex
Esta directiva especifica uno o más archivos que Apache intentará servir cuando los clientes solicitan un listado de directorio
poniendo el caracter "/" al final. Si no existe ninguno de los archivos indicados en esta directiva entonces Apache mostrará un
listado del contenido del directorio si se tiene Options +Indexes
Ejemplo:
ErrorDocument
Esta directiva permite personalizar los mensajes mostrados ante los diferentes códigos de error HTTP generados por Apache. Es
así que se pueda mostrar una página de mejor apariencia y más intuitiva cuando se intenta acceder a un documento que no existe
en lugar de mostrar el típico error 404 Not Found.
El primer ejemplo muestra un mensaje más amigable y la razón específica brindada por Apache contenida en %s. El segundo
ejemplo muestra al usuario una documento específico el cual ya tiene un contenido elaborado.
ErrorDocument 404 "Lo sentimos pero su solicitud no es valida. La razon fue: %s"
ErrorDocument 404 /var/www/html/errors/error-404.html
Alias
Esta directiva permite que Apache sirva documentos ubicados fuera del directorio especificado en DocumentRoot. Tener en
cuenta que si se indica el caracter "/" al final de la ruta_URL entonces se requerirá que el cliente también escriba el caracter "/"
al final de la URL con la que efectúa la solicitud.
Ejemplo:
AliasMatch
Esta directiva es equivalente a la directiva Alias pero permite el uso de expresiones regulares extendidas para indicar la URL
solicitada por el cliente.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 254
Source Linux
Sintaxis : Alias regex ruta_de_archivo|ruta_de_directorio
Defecto : Ninguno
Contexto : Configuración del servidor, Host Virtual
Ejemplo:
Redirect
Esta directiva permite redirigir al cliente a una URL distinta a la que intentó acceder inicialmente. La antigua URL está representada
por ruta_URL y no puede ser una ruta relativa, sino absoluta empezando con "/". La nueva URL debe ser absoluta especificando
el protocolo y nombre de host pero también se puede especificar como una ruta absoluta empezando con "/" en cuyo caso se
asumirá que el protocolo y nombre de host son los mismos que atienden la solicitud actual.
Si no se especifica el estado se asume por defecto el valor "temporary" (Estado HTTP 302).
permanent
Retorna el estado 301 indicando que el recurso se ha movido de manera permanente
temp
Retorna el estado 302 indicando que el recurso se ha movido de manera temporal. Valor por
defecto
seeother
Retorna el estado 303 indicando que el recurso se ha reemplazado
gone
Retorna el estado 410 indicando que el recurso se ha eliminado de manera permanente
Ejemplos:
RedirectMatch
Esta directiva es equivalente a Redirect con la única diferencia que pueden usarse expresiones regulares extendidas para
especificar la URL a la que el cliente intentaba acceder.
Ejemplos:
<IfDefine>
Esta directiva permite crear una configuración condicional basado en la la veracidad del parámetro evaluado. El parámetro que se
evalúa puede ser pasado a Apache en la línea de comandos con la opción -D al programa httpd.
Puede realizar una prueba invocando a Apache un parámetro con el comando "httpd -D prueba" y la siguiente configuración:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 255
Source Linux
<IfDefine prueba>
# Directivas de configuración que podrían aplicarse deben
# escribirse dentro de este contenedor
</IfDefine>
<IfModule>
Esta directiva permite crear una configuración condicional basado en el hecho de que el módulo indicado como parámetro al
contenedor esté actualmente cargado en Apache. Esto permite incluir directivas de configuración que dependen de módulos
específicos.
En el siguiente ejemplo se incluyen las directivas de configuración que trae el módulo mod_userdir solamente si éste está
cargado actualmente en Apache:
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
</IfModule>
Include
Esta directiva permite incluir directivas de configuración desde otro archivo externo las cuales serán incluidas inmediatamente
después del punto del archivo de configuración actual desde el que fue llamado.
En el primer ejemplo se llama a un archivo de configuración externo específico, mientras que en el segundo se hace una
invocación a todos aquellos de extensión .conf dentro de un directorio:
Include /etc/apache2/ports.conf
Include /etc/apache2/conf.d/*.conf
Options
Esta directiva permite controlar qué características particulares estarán habilitadas en un directorio determinado.
None
No aplica ninguna de las opciones
All
Aplica todas las opciones
ExecCGI
Permite la ejecución de scripts CGI
FollowSymLinks
Seguirá el destino de los enlaces simbólicos. Ignorada dentro de contenedores <Location>
SymLinksIfOwnerMatch
Se siguen enlaces simbólicos sólo si el destino del enlace y el enlace pertenecen al mismo
usuario
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 256
Source Linux
Includes
Permite el uso de Server-side Includes
IncludesNOEXEC
Permite el uso de Server-side Includes pero #exec cmd y #exec cgi no se habilitan
Indexes
Muestra un listado del directorio cuando no se encuentra el archivo de la directiva
DirectoryIndex
MultiViews
Permite los MultiViews que es la negociación de contenidos basado en lenguaje de documentos
Listen
Esta directiva define las direcciones y puertos en los que escuchará el servicio. El uso de esta directiva es obligatorio o de lo
contrario Apache se negará a arrancar.
Pueden indicarse múltiples directivas especificando distintas direcciones y/o puertos de escucha como en el siguiente ejemplo:
Listen 80
Listen 192.168.254.13:8080
ServerAdmin
Esta directiva permite definir una dirección de correo electrónico que aparecerá en muchos de los mensajes de error mostrador por
Apache.
Ejemplo:
ServerAdmin webmaster@consultorianet.com
ServerName
Esta directiva permite definir el nombre del host del servidor. Se recomienda usar un FQDN o nombre DNS completo dado que esto
repercutirá directamente en la configuración de Hosts Virtuales debido a que en la versión 1.1 del protocolo HTTP la cabecera
Host permitirá indicarle a Apache qué sitio Web servidor según el valor de esta directiva.
Ejemplo:
ServerName httpd.apache.org
ServerRoot
Esta directiva permite definir bajo qué directorio se encuentran los archivos y directorios que conforman la estructura de Apache.
Bajo esta ruta se buscarán los directorios bin, conf, htdocs, icons, cgi-bin y logs. Por lo general no se necesita cambiar
esta directiva del valor que ya se encuentra asignado.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 257
Source Linux
ServerRoot /etc/httpd
ServerSignature
Esta directiva permite mostrar o no un pie de página en cada mensaje de error y listado de directorios mostrado a los usuarios. Se
recomienda mantener en Off esta directiva a fin de no brindar información de más que pueda serle útil a un potencial atacante.
Ejemplo:
ServerSignature On
ServerTokens
Esta directiva permite definir los campos que tendrá el identificador que se muestra a los clientes cuando se informa del servidor en
uso en las cabeceras HTTP. Se recomienda brindar la menor cantidad de información posible sobre el servidor.
User
Esta directiva asigna el ID de usuario que utilizarán los hijos de Apache durante su ejecución para atender las solicitudes HTTP.
Ejemplo:
User apache
Group
Esta directiva asigna el ID de grupo que utilizarán los hijos de Apache durante su ejecución para atender las solicitudes HTTP.
Ejemplo:
ServerName httpd.apache.org
MaxClients
Esta directiva define la cantidad de conexiones simultáneas máximas que pueden atenderse.
Si se usa el MPM Prefork esta directiva resultará en limitar la cantidad máxima de procesos hijo que pueden crearse debido a que
cada proceso hijo es capaz de atender solamente una solicitud. El valor por defecto es 256 bajo este MPM.
Si se usa un MPM hebrado como worker o beos, entonces esta directiva limita la cantidad máxima de hebras que pueden estar
disponibles para servir clientes. Así, el valor por defecto de esta directiva para el MPM worker es 16 el cual multiplicado por el
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 258
Source Linux
valor de la directiva ThreadsPerChild (Cantidad de hilos por proceso hijo, por defecto en 25) define un máximo de 400 clientes
simultáneos como máximo.
Ejemplo:
MaxClients 15
ThreadsPerChild
Esta directiva define la cantidad de hebras o hilos creados por cada proceso hijo. Solamente tiene sentido para los MPM de
naturaleza hebrada como worker.
Ejemplo:
ThreadsPerChild 30
MaxRequestsPerChild
Esta directiva permite definir la cantidad máxima de solicitudes que un proceso hijo puete atender durante toda su existencia. Una
vez que atiende el número de solicitudes indicadas en esta directiva el proceso hijo se eliminará para luego crearse otro. Si el valor
especificado es 0 entonces el proceso hijo nunca morirá lo que signfica que podrá atender un número ilimitado de solicitudes
mientras se mantenga vivo. Se recomienda sin embargo asignar valores distintos de cero.
Ejemplo:
MaxRequestsPerChild 9000
MaxRequestsPerThread
Similar a MaxRequestsPerChild pero limitando el número máximo de solicitudes que puede atender cada hebra en un proceso
hijo. Si el número definido es 0 entonces la hebra nunca se elimina y atiende peticiones indefinidamente. Se recomienda sin
embargo asignar valores distintos de cero.
Ejemplo:
MaxRequestsPerThread 400
StartServers
Esta directiva define la cantidad de procesos hijos a crearse al iniciar Apache. Esto no significa que no puedan existir más o menos
procesos hijo que la cantidad indicada en esta directiva pues el número de dichos procesos es controlado de manera dinámica
según la carga a la que se encuentre expuesta el servidor en un instante determinado.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 259
Source Linux
StartServers 4
MaxSpareThreads
Esta directiva define la cantidad máxima de hebras en espera que pueden existir.
Si se usa el MPM worker, leader o threadpool el valor por defecto es 250, que contabilizará el total de hebras que sumen
todos los procesos hijo.
Si se usa el MPM perchild el valor por defecto es 10, y contabilizará el total de hebras que puede tener cada proceso hijo.
Sin importar el MPM usado cuando exista una cantidad de hebras en espera mayor al número definido en esta directiva entonces
se empezarán a eliminar tantas hebras como sean necesarias para llegar al límite deseado.
Ejemplo:
MaxSpareThreads 200
MinSpareThreads
Esta directiva define la cantidad mínima de hebras en espera que deben existir.
Si se usa el MPM worker, leader o threadpool el valor por defecto es 75, que contabilizará el total de hebras que sumen todos
los procesos hijo.
Si se usa el MPM perchild el valor por defecto es 5, y contabilizará el total de hebras que puede tener cada proceso hijo.
Sin importar el MPM usado cuando exista una cantidad de hebras en espera menor al número definido en esta directiva entonces
se empezarán a crear tantas hebras como sean necesarias para llegar al límite deseado.
Ejemplo:
MinSpareThreads 80
MaxSpareServers
Esta directiva determina el número máximo de procesos hijo en espera que pueden existir. Debe ajustarse esta directiva sólo en
sitios Web de muchas visitas.
Ejemplo:
MaxSpareServers 8
MinSpareServers
Esta directiva determina el número mínimo de procesos hijo en espera que deben existir. Debe ajustarse esta directiva sólo en
sitios Web de muchas visitas.
Ejemplo:
MinSpareServers 4
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 260
Source Linux
LogLevel
Esta directiva define el nivel de registro que se almacenará en los logs de error.
Emerg
Situación de extrema emergencia
Alert
Se requiere una acción inmediata
Crit
Errores críticos
Error
Condiciones de error
Warn
Mensajes de alerta
Notice
Mensajes de varios tipos
Info
Mensajes de información
Debug
Mensajes de depuración de errores
Ejemplo:
LogLevel warn
ErrorLog
La directiva ErrorLog determina el nombre del fichero en el cual el servidor almacenará los mensajes de error en caso de que
ocurra alguno. Si ruta_archivo no es absoluto, entonces se asume que es relativo al valor especificado en la directiva
ServerRoot.
Ejemplo:
ErrorLog /var/log/apache/error.log
Si el ruta_archivo empieza con un barra vertical "|" entonces se asume que es un comando para procesar el registro de
errores. Ejemplo:
ErrorLog "|/usr/local/bin/httpd_errors"
Usar syslog en lugar de un nombre de fichero permite almanecer los mesajes mediante el demonio syslogd si el sistema lo
soporta. Por defecto se usa la utilidad de syslog local7, pero puede cambiar esto usando syslog:facility donde facility es
cualquiera de los nombres normalmente documentados en syslog(1). Ejemplo:
ErrorLog syslog:user
CustomLog
Esta directiva permite guardar registros de las consultas de los clientes al servidor. Se requiere indicar un formato para el archivo
de logs y se puede hacer un registro condicional basado en la existencia de ciertas variables de entorno.
Similar a la directiva ErrorLog el registro puede enviarse a un archivo o hacia una pipe para ser procesado por otra aplicación.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 261
Source Linux
El formato puede ser especificado como una serie de caracteres de significado especial tales como %h, %l, %u, %t, %r, etc. Los
mismos que están detallados en la documentación de Apache. Sin embargo se puede optar por especificar un formato ya definido a
través de un nombre conocido como por ejemplo common
En el siguiente ejemplo la directiva LogFormat define un formato encerrado entre doble comillas (" ") y a éste le da un nombre, el
mismo que posteriormente es usado en CustomLog:
PidFile
Esta directiva define la ruta del archivo que contiene el PID del proceso principal de Apache.
Ejemplo:
PidFile /var/run/httpd.pid
La palabra KeepAlive hace referencia a la característica por la cual se pueden realizar varias transacciones a través de una única
conexión TCP reduciendo así la carga sobre el servidor. Sin esta característica el funcionamiento típico sería abrir y cerrar una
conexión TCP por cada solicitud HTTP, lo que puede disminuir el rendimiento.
Para sacar provecho de esta característica, KeepAlive debe ser soportada tanto por el cliente como por el servidor. Ya al día de
hoy todos los navegadores modernos lo soportan.
KeepAlive
Esta directiva permite activar o desactivar el soporte de KeepAlive en el servidor.
KeepAliveTimeout
Si la directiva KeepAlive está en On, entonces esta directiva permite definir el número de segundos máximos que Apache
esperará por una nueva transacción HTTP antes de cerrar la conexión. Una vez que se recibe una solicitud, se inicia el conteo de
segundos según el valor especificado en la directiva TimeOut.
Ejemplo:
KeepAliveTimeout 12
MaxKeepAliveRequests
Si la directiva KeepAlive está en On, entonces esta directiva definirá un límite máximo de transacciones HTTP que se permitirán
por conexión TCP. Si el valor para esta directiva es 0 entonces se permitirán infinitas transacciones.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 262
Source Linux
MaxKeepAliveRequests 150
TimeOut
Esta directiva define la cantidad máxima de segundos que Apache esperará por la recepción de datos antes de romper la conexión.
El tiempo definido en esta directiva se aplica a:
Ejemplo:
MaxKeepAliveRequests 150
AllowOverride
Esta directiva permite limitar qué directivas de las encontradas en un archivo de ámbito de directorio (.htaccess) pueden
sobreescribir los valores definidos en las directivas de configuración de ámbito general.
Si su valor se fija en None entonces Apache ya no busca la existencia de los archivos .htaccess en cada directorio recursivo por
cada solicitud de los clientes acelerando así el tiempo de respuesta del servidor.
AuthConfig
Permite usar directivas de autenticación
FileInfo
Permite usar directivas que controlan los tipos de documento
Indexes
Permite el uso de directivas que controlan el indexado de directorios
Limit
Permite el uso de directivas que controlan el acceso al host
Options
Permite usar directivas que controlan funcionalidades específicas de directorios
Ejemplo:
AuthType
Esta directiva selecciona el tipo de autenticación a usar para proteger un recurso servido por Apache. Los dos tipos de
autenticación incluidos en la distribución base de Apache son Basic y Digest.
Basic transmite el usuario y clave en texto plano pero está soportado por casi todos los navegadores, mientras que Digest es
más segura que Basic pero no todos los navegadores soportan correctamente este esquema de autenticación.
Esta directiva requiere ir acompañada de otras como AuthName, AuthUserFile y/o AuthGroupFile para que la autenticación
funcione correctamente.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 263
Source Linux
AuthType Basic
AuthName
Esta directiva el nombre del campo para un recurso protegido determinado. El valor de esta directiva será mostrado al cliente en el
momento que se autentique y el objetivo es informar al usuario sobre el tipo de recurso al que está a punto de acceder.
Ejemplo:
AuthUserFile
Esta directiva define la ruta de un archivo que contiene un listado de usuarios y contraseñas de los cuales Apache hará una
comparación al momento que los usuarios se autentiquen.
Este archivo de contraseñas ha de crearse con la herramienta htpasswd si se opta por el esquema de autenticación Basic, o con
la herramienta htdigest si se opta por el esquema Digest.
Ejemplo:
AuthUserFile "/etc/apache2/.htpasswd"
AuthGroupFile
Esta directiva define la ruta de un archivo que contiene un listado de los grupos de usuarios que se leerán para la autenticación.
El contenido del archivo debe tener la siguiente forma:
Ejemplo:
AuthGroupFile "/etc/apache2/.htgroups"
Require
Esta directiva define qué usuarios o grupos pueden acceder a un recurso protegido determinado. Se usa en conjunto con un
esquema de autenticación con las directivas AuthType, AuthUserFile y AuthName.
user
Define una lista de usuarios separados por espacios en blanco que pueden acceder al recurso
group
Define una lista de grupos separados por espacios en blanco que pueden acceder al recurso
valid-user
Permite que cualquier usuario autenticado acceda al recurso
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 264
Source Linux
Ejemplos:
Require valid-user
Require user achavez psoto ltorres
Require group alumnos docentes gerentes
Allow
Esta directiva permite el acceso a un recurso determinado basándose en la información de Host del cliente que genera la solicitud.
All
Permite el acceso a todos
env=variable_entorno
Se permite el acceso sólo si la variable 'env-variable' existe
Host
Permite el acceso solamente al host que coincida con alguna de las siguientes formas válidas:
El último de los ejemplos permitirá el acceso a los hosts cuya resolución inversa coincida de manera exacta o parte del dominio
netdomain.com. Es así que coincide con mail.netdomain.com y netdomain.com pero no con smtp.newnetdomain.com
Deny
Esta directiva deniega el acceso a un recurso determinado basándose en la información de Host del cliente que genera la solicitud.
Order
Esta directiva usada junto con Allow y Deny define un orden en el que las restricciones se aplicarán para permitir o denegar el
acceso a cierto recurso servido por Apache. La lógica es similar a las reglas de filtrado de iptables y su jerarquía con las políticas
por defecto aplicadas.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 265
Source Linux
Allow,Deny
Primero se evalúan todas las directivas Allow y se permite el acceso si alguna coincide. Se
deniega el acceso cuando haya coincidencia con alguna directiva Deny o si ninguna directiva
Allow genera coincidencia.
Deny,Allow
Primero se evalúan todas las directivas Deny y se deniega el acceso si alguna coincide. Se
permite el acceso cuando haya coincidencia con alguna directiva Allow o si ninguna directiva
Deny genera coincidencia.
En el siguiente ejemplo se permite el acceso solamente a los hosts de la red 192.168.0.0/24 y se deniega a todos los demás:
Order Allow,Deny
Allow from 192.168.0.0/24
Satisfy
Si se ha creado un esquema de autenticación con AuthType y Require para proteger un recurso y también se ha usado la
directiva Allow para limitar el acceso, entonces la directiva Satisfy permite qué requisitos de autenticación o autorización son
suficientes. Esta directiva es útil solamente si se protege un recurso por autenticación (AuthType) y por acceso (Allow).
Any
Permite el acceso si se cumple Allow o Require tienen éxito
All
Requiere que tanto Allow como Require tengan éxito
Ejemplo:
Satisfy Any
<Directory>
Esta directiva permite encerrar una serie de directivas aplicables solamente al directorio especificado incluido sus subdirectorios.
Estas directivas pueden solapar rutas de modo tal que se anule la herencia de directivas de un directorio padre. Nótese en el
siguiente ejemplo que se permite el indexado del directorio "/var/www/html/htdocs" pero no de "/var/www/html/htdocs/
downloads":
<Directory /var/www/html/htdocs>
Options +Indexes
</Directory>
<Directory /var/www/html/htdocs/downloads>
Options None
</Directory>
<Directory /var/www/*cgi*>
Options +ExecCGI
</Directory>
<Directory /var/www/htdocs/stats[0-9]>
Options +Indexes +FollowSymLinks
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 266
Source Linux
</Directory>
Las expresiones regulares extendidas pueden usarse también en la definición de un directorio anteponiendo el caracter ~ a la ruta
como sigue:
<Directory ~ /(var|srv)/w{3}/ht(ml|docs)>
Order Allow,Deny
Allow from 10.0.0.0/8 192.168.0.0/24
</Directory>
<DirectoryMatch>
Esta directiva es similar a <Directory> con la diferencia que el directorio se especifica como una expresión regular extendida sin
necesidad de anteponer el caracter ~
Ejemplo:
<Directory /var/www/html/htdocs/horde.*>
AllowOverride None
</DirectoryMatch>
<Files>
Esta directiva permite encerrar directivas aplicables a archivos de modo similar como <Directory> funciona con directorios.
También es posible usar comodines de shell (*, ?, [ ]) y expresiones regulares con el caracter ~ antepuesto.
Ejemplo:
<Files ~ "\.ht(acce|pa)ss.*">
Deny from all
</Files>
<FilesMatch>
Directiva similar a <Files> que acepta una expresión regular extendida sin necesidad de usar el caracter ~
Ejemplo:
<FilesMatch ~ "\.(doc|ppt|xls|odt|odp|ods)$">
Order Allow,Deny
Allow from 192.168.1.0/24
</FilesMatch>
<Location>
Esta directiva permite controlar el acceso basándose en una URL. Estos contenedores son leídos después de <Directory> y los
archivos .htaccess
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 267
Source Linux
<Location /admin>
AuthType Basic
AuthName "Zona restringida"
AuthUserFile "/etc/httpd/.htpasswd"
Require valid-user
</Location>
<Location ~ "/admin/stat.*">
Order Allow,Deny
Allow from 192.168.1.0/24
</Location>
<LocationMatch>
Esta directiva permite controlar el acceso basándose en una URL haciendo uso de expresiones regulares extendidas.
Ejemplo:
<LocationMatch "/downloads/nota.*">
Order Allow,Deny
Allow from 192.168.1.0/24
</LocationMatch>
NameVirtualHost
Esta directiva define las direcciones IP y puertos en los que Apache quedará a la escucha de conexiones para Hosts Virtuales
basados en nombre.
Si esta directiva no es usada se asume entonces que los Hosts Virtuales configurados estarán basados en direcciones IP y puerto.
Ejemplos:
NameVirtualHost *:80
NameVirtualHost 192.168.2.3:443
<VirtualHost>
Esta directiva define una configuración para el Host Virtual. Se pueden aplicar todas las directivas válidas para el contexto de Hosts
Virtuales ya estudiadas de modo tal que cuando Apache recibe la solicitud de un documento en un host virtual determinado se
usarán todas las directivas correspondientes a la sección <VirtualHost> respectiva.
La dirección y puerto especifica por dónde funcionará dicha configuración de Host Virtual en particular, debido a que Apache puede
atender por muchas direcciones y puertos las solicitudes de Hosts Virtuales pero no todas pertenecerle a una configuración
específica.
<VirtualHost 192.168.2.3:*>
DocumentRoot /var/www/html/htdocs/mysitioweb
ServerName www.myblogpersonal.com
</VirtualHost>
Puede tambien especificarse _default_ como un nombre especial de Host Virtual el cual coincidirá con cualquier dirección IP y
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 268
Source Linux
puerto que no esté explícitamente declarada en alguna directiva <VirtualHost>. En caso que no haya coincidencia con ninguna
IP:puerto referida por una configuración de Host Virtual e incluso no exista la configuración para _default_ Apache procederá a
servir la configuración del servidor principal la misma que consta de directivas especificadas fuera de directivas <VirtualHost>
<VirtualHost _default_>
DocumentRoot /var/www/html/htdocs/default
</VirtualHost>
ServerName
La directiva ServerName especifica el nombre de host y el puerto que usa el servidor para identificarse. Esto se usa cuando se
hace redirección de URLs. Por ejemplo, si el nombre de la maquina del servidor web es simple.example.com, pero el la
maquina también tiene el alias DNS www.example.com y quiere que el servidor web se identifique así, debe usar la siguiente
directiva:
Ejemplo:
ServerName www.apache.org
ServerAlias
Esta directiva define nombres alternativos para un Host. Usado en conjunto con ServerName
Ejemplo:
SSLEngine
Esta directiva habilita el soporte de SSL para el sitio Web ofrecido.
Ejemplos:
SSLEngine On
SSLCertificateFile
Esta directiva define la ruta al archivo de certificado (en formato codificado PEM) para el servidor.
Ejemplos:
SSLCertificateFile /etc/httpd/apache-cert.pem
SSLCertificateKeyFile
Esta directiva define la ruta al archivo de llave privada (en formato codificado PEM) para el servidor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 269
Source Linux
Ejemplos:
SSLCertificateKeyFile /etc/httpd/apache-key.pem
b) Para agregar más usuarios simplemente debe usarse el mismo procedimiento pero sin la opción -c:
c) Ahora se generará la configuración de Apache para permitir que los usuarios permitan navegar sobre el contenido del directorio e
incluso poder acceder a elementos fuera de la ruta permitida a través de enlaces simbólicos. También se redireccionará a los usuarios
que intenten acceder al recurso a través de una URL antigua (/downloads)la que ha sido reemplazado por otra nueva.
Considerar además que los usuarios de la LAN 192.168.1.0/24 siempre tendrán acceso al recurso mientras que los usuarios
provenientes de otras direcciones requerirán autenticarse primero.
# /etc/apache2/apache2.conf
DocumentRoot /var/www/html
RedirectMatch 301 ^/download.*$ /descargas
<Directory /var/www/html>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<Directory /var/www/html/descargas>
Options +Indexes +FollowSymLinks
AuthType Basic
AuthName "Zona reservada de descargas"
AuthUserFile "/etc/httpd/.htpasswd"
Require valid-user
Order Allow,Deny
Allow from 127.0.0.0/8 192.168.1.0/24
Satisfy Any
</Directory>
d) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
# service httpd restart
a) Primero se muestra la configuración general del servidor aplicando algunos ajustes de seguridad:
# /etc/httpd/conf/httpd.conf
DocumentRoot /var/www/html
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 270
Source Linux
DirectoryIndex index.html index.htm
ServerAdmin webmaster@newcompany.com
ServerName localhost
ServerSignature Off
ServerTokens Off
User apache
Group apache
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<Directory />
Options None
AllowOverride None
Order Allow,Deny
Deny from all
</Directory>
<Directory /var/www/html/htdocs>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<Directory /vhosts>
AllowOverride AuthConfig Options
</Directory>
<Directory /var/www/html/errors>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<FilesMatch "\.ht(acce|pa)ss.*$">
Deny from all
</FilesMatch>
NameVirtualHost *:80
<VirtualHost _default_>
DocumentRoot /vhosts/default
CustomLog /var/log/httpd/default-access.log common
<Directory /vhosts/default>
Options None
Allow from all
</Directory>
</VirtualHost>
Include /etc/httpd/conf/vhosts.d/*.conf
# /etc/httpd/conf/vhosts.d/vhost1.conf
<VirtualHost *>
ServerName www.cybermatrix.com.pe
ServerAlias cybermatrix.com.pe cybermatrix.com www.cybermatrix.com
ServerAdmin webmaster@cybermatrix.com.pe
DocumentRoot /vhosts/cybermatrix
DirectoryIndex index.php
ErrorDocument 404 /var/www/html/errors/error-404.html
ErrorDocument 403 /var/www/html/errors/error-403.html
LogLevel warn
ErrorLog /var/log/httpd/cybermatrix-error.log
CustomLog /var/log/httpd/cybermatrix-access.log common
<Directory /vhosts/cybermatrix>
Options +FollowSymLinks +Multiviews
Allow from all
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 271
Source Linux
</Directory>
</VirtualHost>
# /etc/httpd/conf/vhosts.d/vhost2.conf
<VirtualHost *>
ServerName www.newtechnologies.net
ServerAdmin webmaster@newtechnologies.net
DocumentRoot /vhosts/newtechnologies
DirectoryIndex index.php
AliasMatch ^/(webmail|correo|correoweb) /var/www/html/htdocs/horde
LogLevel error
ErrorLog /var/log/httpd/newtechnologies-error.log
CustomLog /var/log/httpd/newtechnologies-access.log common
<Directory /vhosts/newtechnologies>
Options +FollowSymLinks +Includes
Allow from all
</Directory>
</VirtualHost>
c) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
# service httpd restart
a) Dado que se deben crear dos Hosts Virtuales de sitios Web seguros (HTTPS), y debido a la naturaleza del protocolo SSL que no
permite crear hosts virtuales basados en nombre, desactivaremos la directiva NameVirtualHost y crearemos dos contenedores
<VirtualHost> como sigue:
#NameVirtualHost *:80
<VirtualHost 172.31.0.201:443>
ServerName www.consultorianet.com
DocumentRoot /var/www/html/www.consultorianet.com
ErrorLog /var/log/httpd/www.consultorianet.com-error.log
CustomLog /var/log/httpd/www.consultorianet.com-access.log combined
SSLEngine On
SSLCertificateFile /etc/httpd/apache-cert.pem
SSLCertificateKeyFile /etc/httpd/apache-key.pem
<Directory /var/www/html/www.consultorianet.com>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.0.203:443>
ServerName www.sotohnos.com.pe
DocumentRoot /var/www/html/www.sotohnos.com.pe
ErrorLog /var/log/httpd/www.sotohnos.com.pe-error.log
CustomLog /var/log/httpd/www.sotohnos.com.pe-access.log combined
SSLEngine On
SSLCertificateFile /etc/httpd/apache-cert.pem
SSLCertificateKeyFile /etc/httpd/apache-key.pem
<Directory /var/www/html/www.sotohnos.com.pe>
Options None
AllowOverride None
Order allow,deny
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 272
Source Linux
Allow from all
</Directory>
</VirtualHost>
Al desactivar NameVirtualHost entonces Apache interpreta las configuraciones de VirtualHost basadas en dirección IP y puerto
únicamente. Es así que asociamos la IP 172.31.0.201 a www.consultorianet.com y la IP 172.31.0.203 a www.sotohnos.com.pe
Sin embargo estamos utilizando el mismo certificado apache-cert.pem (anteriormente creado para www.sotohnos.com.pe) para ambos
dominios (lo que no es lo correcto pero para fines de prueba está bien).
b) Asegurarse de copiar los archivos apache-cert.pem y apache-key.pem al directorio /etc/httpd como sigue:
# cd /root/sslCA
# cp -v apache-cert.pem /etc/httpd/
# cp -v private/apache-key.pem /etc/httpd/
c) Utilizando ifconfig asegurarse que el host donde corre Apache tenga asignadas las direcciones IP 172.31.0.201 y 172.31.0.203:
# ifconfig
d) Creamos los directorios servidor por Apache para cada host virtual y dentro creamos también archivos index.html de prueba:
# mkdir /var/www/html/www.consultorianet.com
# mkdir /var/www/html/www.sotohnos.com.pe
# echo "<h1>www.consultorianet.com</h1>" > /var/www/html/www.consultorianet.com/index.html
# echo "<h1>www.sotohnos.com.pe</h1>" > /var/www/html/www.sotohnos.com.pe/index.html
e) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
# service httpd restart
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 273
Source Linux
Administración de Apache desde Webmin
Webmin es una herramienta de configuración de servicios para plataformas Linux y otros UNIX. A través de esta herramienta podemos
configurar y monitorear el servicio Web con Apache siguiendo estos pasos:
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
2. Dentro de Webmin acceder a 'Servers -> Apache Webserver' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 274
Source Linux
13.4. Reportes de tráfico Web
La capacidad de generar reportes de los servicios de red instalados en un servidor resultan ser un requerimiento muy común en la
mayoría de organizaciones, más aún si se tratan de servicios de amplio uso público, tal como es el caso de los servidores Web con
soporte de Hosts Virtuales.
Por ello, en esta sección revisaremos el proceso de instalación y configuración de una excelente herramienta de generación de
reportes llamada AWStats, la que nos podrá generar informes en formatos bastante amigables para el administrador.
Descarga e instalación
AWStats puede ser descargado desde su sitio Web oficial (http://awstats.sourceforge.net), como un archivo tarball, o podemos
simplificar la instalación desde repositorios.
Este paquete está incluido en los repositorios oficiales para Debian, pero para Red Hat / CentOS no sucede lo mismo aunque no
obstante existe el repositorio DAG que sí incluye este paquete.
En Red Hat / CentOS y derivados, procederemos a crear un archivo de repositorio /etc/yum.repos.d/dag.repo con un contenido como el
siguiente:
[dag]
name=dag
gpgcheck=0
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag/
enabled=0
Este procedimiento es el recomendado para agilizar el proceso de resolución de dependencias de software y configuración
predeterminada del paquete.
Dentro del directorio /etc/awstats debe existir un archivo de nombre awstats.model.conf (Red Hat / CentOS) o awstats.conf (en Debian) el
cual contiene un modelo de la configuración de AWStats.
Crearemos una copia a partir de éste con un nombre como awstats.www.consultorianet.com.conf:
# cd /etc/awstats
# cp awstats.model.conf awstats.www.consultorianet.com.conf
En Debian y derivados:
# cd /etc/awstats
# cp awstats.conf awstats.www.consultorianet.com.conf
Editaremos este archivo awstats.www.consultorianet.com.conf creado y modificaremos su contenido de acuerdo al texto debajo resaltado
en negrita :
...
...
LogFile="/var/log/httpd/www.consultorianet.com-access.log"
...
...
LogType=W
...
...
LogFormat=1
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 275
Source Linux
...
...
LogSeparator=" "
...
...
SiteDomain="www.consultorianet.com"
...
...
1. El paquete awstats instalado trajo consigo un archivo de configuración modelo para Apache ubicado en
/etc/httpd/conf.d/awstats.conf, del cual debemos modificar su contenido según el texto resaltado en negrita:
En Debian y derivados
1. El paquete awstats instalado trae consigo un archivo de configuración modelo para Apache ubicado en
/usr/share/doc/awstats/examples/apache.conf, del cual debemos crear una copia en /etc/apache2/conf.d/awstats.conf y modificar su
contenido según el texto resaltado en negrita:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 276
Source Linux
# This (hopefully) enables _all_ CGI scripts in the default directory
# Security concerns: Are you sure _all_ CGI scripts are safe?
# ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
Finalmente ya tenemos lista la configuración de AWStats para los logs del servidor FTP, sólo nos resta instruir a través de la línea de
comandos la generación de estadísticas recientes a partir del archivo /var/log/vsftpd.log configurado, haciendo uso del script awstats.pl
que viene con el paquete awstats como sigue:
En Debian y derivados:
El script awstats.pl genera las estadísticas por defecto en /var/www/awstats (en Red Hat / CentOS) o en /var/lib/awstats (en Debian), las
cuales son representadas por archivos de textos poco o nada entendibles.
Por ello la forma correcta de visualizar estas estadísticas generada es a través de la ejecución de un script CGI desde Apache
accediendo con un navegador a una URL como la siguiente:
http://172.31.0.201/awstats/awstats.pl?config=www.consultorianet.com
... donde se asume que el host donde se ejecuta el servidor FTP, Web y la herramienta AWStats, posee la IP 172.31.0.201.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
5. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de AWStats
rellenando con la URL de descarga (link obtenido desde la Web oficial de AWStats) el campo de nombre 'From ftp or http
URL' como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 277
Source Linux
6. Una vez instalado el módulo acceder a 'System -> AWStats Logfile Analyzer' y revisar las opciones de configuración del
módulo de AWStats a través de su interfaz gráfica amigable.
13.5. Laboratorio N° 13
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Crear una configuración de Apache para hospedar dos Hosts Virtuales correspondientes a los dominios www.estadia.com y
www.comunicaciones.net. Ambos deben atender peticiones en los puertos 80 y 443, para lo cual se reservan a cada uno de
los nombres de hosts las direcciones IP 172.31.10.20 y 172.31.10 30.
Sin embargo se requiere que para el dominio www.estadia.com se fuerce la redirección a una conexión segura (HTTPS) de
la URL http://ww.estadia.com/webmail/login.php cuando un cliente intente acceder a ella a través de una conexión insegura
(HTTPS).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 278
Source Linux
13.5.1. Solución al laboratorio N° 13
1. Crear una configuración de Apache para hospedar dos Hosts Virtuales correspondientes a los dominios www.estadia.com y
www.comunicaciones.net. Ambos deben atender peticiones en los puertos 80 y 443, para lo cual se reservan a cada uno de
los nombres de hosts las direcciones IP 172.31.10.20 y 172.31.10 30.
Sin embargo se requiere que para el dominio www.estadia.com se fuerce la redirección a una conexión segura (HTTPS) de
la URL http://ww.estadia.com/webmail/login.php cuando un cliente intente acceder a ella a través de una conexión insegura
(HTTPS).
+ Creamos una configuración de Hosts Virtuales en el puerto 80 para los dominios solicitados:
#NameVirtualHost
<VirtualHost 172.31.10.20:80>
ServerName www.estadia.com
DocumentRoot /var/www/html/www.estadia.com
ErrorLog /var/log/httpd/www.estadia.com-error.log
CustomLog /var/log/httpd/www.estadia.com-access.log combined
<Directory /var/www/html/www.estadia.com.pe>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.10.30:80>
ServerName www.comunicaciones.net
DocumentRoot /var/www/html/www.comunicaciones.net
ErrorLog /var/log/httpd/www.comunicaciones.net-error.log
CustomLog /var/log/httpd/www.comunicaciones.net-access.log combined
<Directory /var/www/html/www.comunicaciones.net>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
+ Creamos las configuraciones de Hosts Virtuales de conexiones seguras similares a los ya configurados, definiendo
archivos de certificados y llaves privadas que se asumen ya existen:
<VirtualHost 172.31.10.20:443>
ServerName www.estadia.com
DocumentRoot /var/www/html/www.estadia.com
ErrorLog /var/log/httpd/www.estadia.com-error.log
CustomLog /var/log/httpd/www.estadia.com-access.log combined
SSLEngine On
SSLCertificateFile /etc/httpd/estadia.com-cert.pem
SSLCertificateKeyFile /etc/httpd/estadia.com-key.pem
<Directory /var/www/html/www.estadia.com.pe>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.10.30:443>
ServerName www.comunicaciones.net
DocumentRoot /var/www/html/www.comunicaciones.net
ErrorLog /var/log/httpd/www.comunicaciones.net-error.log
CustomLog /var/log/httpd/www.comunicaciones.net-access.log combined
SSLEngine On
SSLCertificateFile /etc/httpd/comunicaciones.net-cert.pem
SSLCertificateKeyFile /etc/httpd/comunicaciones.net-key.pem
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 279
Source Linux
<Directory /var/www/html/www.comunicaciones.net>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
+ Haciendo uso del módulo de Apache mod_rewrite crearemos la regla de redirección en el Host Virtual de conexión
insegura (HTTP) a la URL /webmail/login.php como sigue:
<VirtualHost 172.31.10.20:80>
ServerName www.estadia.com
DocumentRoot /var/www/html/www.estadia.com
ErrorLog /var/log/httpd/www.estadia.com-error.log
CustomLog /var/log/httpd/www.estadia.com-access.log combined
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} \/webmail\/login\.php
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
...
...
...
</VirtualHost>
# httpd -t
# service httpd restart
+ Para realizar las pruebas podríamos crear la ruta de la URL a redireccionar, con un archivo PHP sencillo como debajo se
muestra:
# mkdir -p /var/www/html/www.estadia.com/webmail/login.php
<?php
phpinfo();
?>
Ahora bastaría con ingresar a la URL http://www.estadia.com/webmail/login.php y comprobar que se redireccione a la misma
URL bajo una conexión segura HTTPS.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 280
Source Linux
Unidad 14: Firewall seguro
14.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Adquirir los conceptos básicos relacionados a un firewall, netfilter, iptables y Shorewall como frontend.
✔ Realizar una configuración de firewall básico con Shorewall, para filtrar paquetes y realizar operaciones de NAT.
✔ Controlar el tráfico de usuarios con políticas de QoS.
✔ Implementar Shorewall para trabajar con dos o más Proveedores de Internet.
Esquema típico de firewall para proteger una red local conectada a Internet a través de un router. El firewall debe colocarse entre el
router (con un único cable) y la red local (conectado al switch o al hub de la LAN).
Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de
seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a Internet (como es el caso de un
servidor web, un servidor de correo, etc..), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo
que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona
desmilitarizada. El firewall tiene entonces tres entradas:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 281
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 282
Source Linux
En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor
sea accesible desde Internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta
estructura de DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único dispositivo con al
menos tres interfaces de red). Sería un esquema como este:
Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de Internet en las empresas, aunque ahí
también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto
último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel).
También, en empresas de hosting con muchos servidores alojados lo normal es encontrarnos uno o más firewalls ya sea filtrando
toda la instalación o parte de ella:
(1) Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y sólo se denegará lo que se
diga explícitamente.
(2) Política por defecto DENEGAR: todo está denegado, y sólo se permitirá pasar por el firewall a aquellos que se permita
explícitamente.
Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar
de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si
queremos proteger una máquina linux, podemos hacer un netstat -ln y saber que puertos están abiertos, poner reglas para proteger
esos puertos y ya está. ¿Para qué vamos a proteger un puerto que realmente nunca se va a abrir?
El único problema que podemos tener es que no controlemos que es lo que está abierto, o que en un momento dado se instale un
software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política
por defecto es ACEPTAR y no se protege explícitamente, nos la estamos jugando un poco.
En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un
auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro cómo
funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas
súper permisivas.
Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema. Uno
de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls.
Importante:
• El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace
con un paquete se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se
hace lo que dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete.
¿Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del firewall, puede que las siguientes no se
apliquen y no sirvan de nada.
Netfilter e iptables
Netfilter es un framework disponible en el núcleo Linux que permite interceptar y manipular paquetes de red. Dicho framework permite
realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter es también el nombre que recibe el proyecto que se
encarga de ofrecer herramientas libres para cortafuegos basados en Linux.
El componente más popular construido sobre Netfilter es iptables, una herramientas de cortafuegos que permite no solamente filtrar
paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4 o mantener registros de log. El proyecto ofrecía
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 284
Source Linux
compatibilidad hacia atrás con ipchains hasta hace relativamente poco, aunque hoy día dicho soporte ya ha sido retirado al
considerarse una herramienta obsoleta. El proyecto Netfilter no sólo ofrece componentes disponibles como módulos del núcleo sino
que también ofrece herramientas de espacio de usuario y librerias.
iptables es el nombre de la herramienta de espacio de usuario mediante la cual el administrador puede definir políticas de filtrado
del tráfico que circula por la red. El nombre iptables se utiliza frecuentemente de forma errónea para referirse a toda la infraestructura
ofrecida por el proyecto Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales como el
connection tracking system o sistema de seguimiento de conexiones, o queue, que permite encolar paquetes para que sean tratados
desde espacio de usuario. iptables es un software disponible en prácticamente todas las distribuciones de Linux actuales.
Modo de operación
iptables permite al administrador del sistema definir reglas acerca de qué hacer con los paquetes de red. Las reglas se agrupan
en cadenas: cada cadena es una lista ordenada de reglas. Las cadenas se agrupan en tablas: cada tabla está asociada con un tipo
diferente de procesamiento de paquetes.
Cada regla especifica qué paquetes la cumplen (match) y un destino que indica qué hacer con el paquete si éste cumple la regla.
Cada paquete de red que llega a una computadora o que se envía desde una computadora recorre por lo menos una cadena y
cada regla de esa cadena se comprueba con el paquete. Si la regla cumple con el datagrama, el recorrido se detiene y el destino
de la regla dicta lo que se debe hacer con el paquete. Si el paquete alcanza el fin de una cadena predefinida sin haberse
correspondido con ninguna regla de la cadena, la política de destino de la cadena dicta qué hacer con el paquete. Si el paquete
alcanza el fin de una cadena definida por el usuario sin haber cumplido ninguna regla de la cadena o si la cadena definida por el
usuario está vacía, el recorrido continúa en la cadena que hizo la llamada (lo que se denomina implicit target RETURN o RETORNO
de destino implícito). Solo las cadenas predefinidas tienen políticas.
En iptables, las reglas se agrupan en cadenas. Una cadena es un conjunto de reglas para paquetes IP, que determinan lo que se
debe hacer con ellos. Cada regla puede desechar el paquete de la cadena (cortocircuito), con lo cual otras cadenas no serán
consideradas. Una cadena puede contener un enlace a otra cadena: si el paquete pasa a través de esa cadena entera o si cumple
una regla de destino de retorno, va a continuar en la primera cadena. No hay un limite respecto de cuán anidadas pueden estar las
cadenas. Hay tres cadenas básicas (INPUT, OUTPUT y FORWARD: ENTRADA, SALIDA y REENVÍO) y el usuario puede crear tantas
como desee. Una regla puede ser simplemente un puntero a una cadena.
Las tablas
Hay tres tablas ya incorporadas, cada una de las cuales contiene ciertas cadenas predefinidas. Es posible crear nuevas tablas
mediante módulos de extensión. El administrador puede crear y eliminar cadenas definidas por usuarios dentro de cualquier
tabla. Inicialmente, todas las cadenas están vacías y tienen una política de destino que permite que todos los paquetes pasen
sin ser bloqueados o alterados.
A) filter table (Tabla de filtros) — Esta tabla es la responsable del filtrado (es decir, de bloquear o permitir que un paquete
continúe su camino). Todos los paquetes pasan a través de la tabla de filtros. Contiene las siguientes cadenas predefinidas y
cualquier paquete pasará por una de ellas:
• INPUT chain (Cadena de ENTRADA) — Todos los paquetes destinados a este sistema atraviesan esta cadena (y por
esto se la llama algunas veces LOCAL_INPUT o ENTRADA_LOCAL)
• OUTPUT chain (Cadena de SALIDA) — Todos los paquetes creados por este sistema atraviesan esta cadena (a la
que también se la conoce como LOCAL_OUTPUT o SALIDA_LOCAL)
• FORWARD chain (Cadena de REDIRECCIÓN) — Todos los paquetes que meramente pasan por este sistema (para
ser ruteados) recorren esta cadena
B) nat table (Tabla de traducción de direcciones de red) — Esta tabla es la responsable de configurar las reglas de reescritura
de direcciones o de puertos de los paquetes. El primer paquete en cualquier conexión pasa a través de esta tabla; los
veredictos determinan como van a reescribirse todos los paquetes de esa conexión. Contiene las siguientes cadenas
redefinidas:
• PREROUTING chain (Cadena de PRERUTEO) — Los paquetes entrantes pasan a través de esta cadena antes de
que se consulte la tabla de ruteo local, principalmente para DNAT (destination-NAT o traducción de direcciones de
red de destino)
• POSTROUTING chain (Cadena de POSRUTEO) — Los paquetes salientes pasan por esta cadena después de
haberse tomado la decisión del ruteo, principalmente para SNAT (source-NAT o traducción de direcciones de red de
origen)
• OUTPUT chain (Cadena de SALIDA) — Permite hacer un DNAT limitado en paquetes generados localmente
C) mangle table (Tabla de destrozo) — Esta tabla es la responsable de ajustar las opciones de los paquetes, como por ejemplo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 285
Source Linux
la calidad de servicio. Todos los paquetes pasan por esta tabla. Debido a que está diseñada para efectos avanzados, contiene
todas las cadenas predefinidas posibles:
• PREROUTING chain (Cadena de PRERUTEO) — Todos los paquetes que logran entrar a este sistema, antes de que
el ruteo decida si el paquete debe ser reenviado (cadena de REENVÍO) o si tiene destino local (cadena de
ENTRADA)
• INPUT chain (Cadena de ENTRADA) — Todos los paquetes destinados para este sistema pasan a través de esta
cadena
• FORWARD chain (Cadena de REDIRECCIÓN) — Todos los paquetes que meramente pasan por este sistema pasan a
través de esta cadena
• OUTPUT chain (Cadena de SALIDA) — Todos los paquetes creados en este sistema pasan a través de esta cadena
• POSTROUTING chain (Cadena de POSTRUTEO) — Todos los paquetes que abandonan este sistema pasan a través
de esta cadena
Además de las cadenas ya incorporadas, el usuario puede crear todas las cadenas definidas por el usuario que quiera dentro de
cada tabla, las cuales permiten agrupar las reglas en forma lógica.
Cada cadena contiene una lista de reglas. Cuando un paquete se envía a una cadena, se lo compara, en orden, contra cada regla
en la cadena. La regla especifica qué propiedades debe tener el paquete para que la regla lo matchee, como número de puerto o
dirección IP. Si la regla no coincidea, el procesamiento continúa con la regla siguiente. Si la regla, por el contrario, matchea el
paquete, las instrucciones de destino de las reglas se siguen (y cualquier otro procesamiento de la cadena normalmente se aborta).
Algunas propiedades de los paquetes solo pueden examinarse en ciertas cadenas (por ejemplo, la interfaz de red de salida no es
válida en la cadena de ENTRADA). Algunos destinos solo pueden usarse en ciertas cadenas y/o en ciertas tablas (por ejemplo, el
destino SNAT solo puede usarse en la cadena de POSRUTEO de la tabla de traducción de direcciones de red).
La siguiente figura ilustra el modo de operación de las tablas:
Los destinos
El destino de una regla puede ser el nombre de una cadena definida por el usuario o uno de los destinos ya incorporados ACCEPT,
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 286
Source Linux
DROP, QUEUE, o RETURN (aceptar, descartar, encolar o retornar, respectivamente). Cuando un destino es el nombre de una
cadena definida por el usuario, al paquete se lo dirige a esa cadena para que sea procesado (tal como ocurre con una llamada a
una subrutina en un lenguaje de programación). Si el paquete consigue atravesar la cadena definida por el usuario sin que ninguna
de las reglas de esa cadena actúe sobre él, el procesamiento del paquete continúa donde había quedado en la cadena actual.
Estos llamados entre cadenas se pueden anidar hasta cualquier nivel deseado.
Existen los siguientes destinos ya incorporados:
ACCEPT (aceptar)
Este destino hace que netfilter acepte el paquete. El significado de esto depende de cuál sea la cadena realizando esta
aceptación. De hecho, a un paquete que se lo acepta en la cadena de ENTRADA se le permite ser recibido por la terminal
(host), a un paquete que se lo acepta en la cadena de SALIDA se le permite abandonar la terminal y a un paquete que se lo
acepta en la cadena de REDIRECCIÓN se le permite ser ruteado a través de la terminal.
DROP (descartar)
Este destino hace que netfilter descarte el paquete sin ningún otro tipo de procesamiento. El paquete simplemente desaparece
sin indicación de que fue descartado al ser entregado a la terminal de envio o a una aplicación. Esto se le refleja al que envía, a
menudo, como un communication timeout (alcance del máximo tiempo de espera en la comunicación), lo que puede causar
confusión (aunque el descarte de paquetes entrantes no deseados se considera a veces una buena política de seguridad, pues
no da ni siquiera el indicio a un posible atacante de que la terminal existe).
QUEUE (encolar)
Este destino hace que el paquete sea enviado a una cola en el espacio de usuario. Una aplicación puede usar la biblioteca
libipq, también parte del proyecto netfilter/iptables, para alterar el paquete. Si no hay ninguna aplicación que lea la cola, este
destino es equivalente a DROP.
RETURN (retorno)
Hace que el paquete en cuestión deje de circular por la cadena en cuya regla se ejecutó el destino RETURN. Si dicha cadena
es una subcadena de otra, el paquete continuará por la cadena superior como si nada hubiera pasado. Si por el contrario la
cadena es una cadena principal (por ejemplo la cadena INPUT), al paquete se le aplicará la política por defecto de la cadena
en cuestión (ACCEPT, DROP o similar).
Hay muchos destinos de extensión disponibles. Algunos de los más comunes son:
REJECT (rechazo)
Este destino tiene el mismo efecto que 'DROP', salvo que envía un paquete de error a quien envió originalmente. Se usa
principalmente en las cadenas de ENTRADA y de REDIRECCIÓN de la tabla de filtrado. El tipo de paquete se puede controlar
a través del parámetro '--reject-with'. Un paquete de rechazo puede indicar explícitamente que la conexión ha sido filtrada (un
paquete ICMP filtrado administrativamente por conexión), aunque la mayoría de los usuarios prefieren que el paquete indique
simplemente que la computadora no acepta ese tipo de conexión (tal paquete será un paquete tcp-reset para conexiones TCP
denegadas, un icmp-port-unreachable para sesiones UDP denegadas o un icmp-protocol-unreachable para paquetes no TCP y
no UDP). Si el parámetro '--reject-with' no se especifica, el paquete de rechazo por defecto es siempre icmp-port-unreachable.
LOG (bitácora)
Este destino lleva un log o bitácora del paquete. Puede usarse en cualquier cadena en cualquier tabla, y muchas veces se usa
para debuggear (análisis de fallos, como ser la verificación de qué paquetes están siendo descartados).
ULOG
Este destino lleva un log o bitácora del paquete, pero no de la misma manera que el destino LOG. El destino LOG le envía
información al log del núcleo, pero ULOG hace multidifusión de los paquetes que matchean esta regla a través de un socket
netlink, de manera que programas del espacio de usuario puedan recibir este paquete conectándose al socket.
DNAT
Este destino hace que la dirección (y opcionalmente el puerto) de destino del paquete sean reescritos para traducción de
dirección de red. Mediante la opción '--to-destination' debe indicarse el destino a usar. Esto es válido solamente en las cadenas
de SALIDA y PRERUTEO dentro de la tabla de nat. Esta decisión se recuerda para todos los paquetes futuros que pertenecen
a la misma conexión y las respuestas tendrán su dirección y puerto de origen cambiados al original (es decir, la inversa de este
paquete).
SNAT
Este destino hace que la dirección (y opcionalmente el puerto) de origen del paquete sean reescritos para traducción de
dirección de red. Mediante la opción '--to-source' debe indicarse el origen a usar. Esto es válido solamente en la cadena de
POSRUTEO dentro de la tabla de nat y, como DNAT, se recuerda para todos los paquetes que pertenecen a la misma
conexión.
MASQUERADE
Esta es una forma especial, restringida de SNAT para direcciones IP dinámicas, como las que proveen la mayoría de los
proveedores de servicios de Internet (ISPs) para modems o línea de abonado digital (DSL). En vez de cambiar la regla de
SNAT cada vez que la dirección IP cambia, se calcula la dirección IP de origen a la cual hacer NAT fijándose en la dirección IP
de la interfaz de salida cuando un paquete matchea esta regla. Adicionalmente, recuerda cuales conexiones usan
MASQUERADE y si la dirección de la interfaz cambia (por ejemplo, por reconectarse al ISP), todas las conexiones que hacen
NAT a la dirección vieja se olvidan.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 287
Source Linux
Shorewall
Shoreline Firewall, Shorewall, es un Firewall Open Source para Linux construido sobre las bases de Netfilter e iptables, trabajando
en un nivel superior que abstrae la complejidad que puede implicar la sintaxis de iptables así como también el uso de otras
herramientas de red tales como iproute o tc.
La razón principal para el estudio de Shorewall en lugar de iptables puro, es la limpieza, orden y sencillez que caracterizan al primero
para configurar reglas de Firewall y otras tareas asociadas utilizando una interfaz de fácil comprensión a través de archivos de texto
plano.
Instalación de Shorewall
Shorewall puede ser descargado directamente desde su Website http://www.shorewall.net en formatos RPM para distribuciones como
Red Hat y derivados.
En cambio Debian ya incluye los paquetes de shorewall en su distribución pudiendo ser descargada desde los repositorios. Sin
embargo a la fecha que se escribe este documento, la versión estable Debian Lenny incluye la versión 4.0.x de Shorewall. La versión
reciente de Shorewall, la 4.4.5 puede ser encontrada en la distribución testing de Debian.
El material impartido sobre la configuración de Shorewall no representa mayores diferencias entre la 4.0.x y la 4.4.5, por lo que
simplemente asumiremos que se trabaja con cualquiera de esas dos ramas de versiones o superiores.
En Debian y derivados:
La configuración de Shorewall se basa en archivos individuales ubicados en /etc/shorewall de donde algunos de los que necesitaremos
generalmente son:
Archivo Descripción
/etc/shorewall/shorewall.conf Archivo de configuración global de Shorewall.
/etc/shorewall/zones Archivo de declaración de zonas.
/etc/shorewall/interfaces Archivo de declaración de interfaces de red asociadas a zonas.
/etc/shorewall/hosts Archivo de declaración de subredes y direcciones IP asociadas a zonas.
/etc/shorewall/policy Archivo de políticas por defecto.
/etc/shorewall/masq Archivo de reglas de enmascaramiento y SNAT.
/etc/shorewall/rules Archivo de reglas de filtrado y NAT.
/etc/shorewall/nat Archivo de reglas de NAT 1 a 1.
/etc/shorewall/providers Archivo de definición de Proveedores de Internet.
/etc/shorewall/tcclasses Archivo de clases HTB para QoS.
/etc/shorewall/tcdevices Archivo de declaración de interfaces de red para aplicar QoS.
/etc/shorewall/tcrules Archivo de reglas de marcado de paquetes.
Estos no son todos los archivos de configuración disponibles de Shorewall sino sólo los más comunes en los escenarios de
configuración que se han estudiar en este documento.
Debido a que son múltiples los archivos de configuración existentes, cada uno de ellos pudiendo ser conjugado con otros para
escenarios distintos, vamos a proceder con el estudio de configuraciones para casos genéricos que fácilmente podrían adaptarse para
otros entornos según el usuario lo necesite.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 288
Source Linux
El diagrama debajo mostrado corresponde al modelo de la configuración a seguir a continuación:
#ZONE TYPE
fw firewall
LAN ipv4
WAN ipv4
DMZ ipv4
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. El archivo sólo define qué zonas existen, mas no las asocia con ninguna interfaz de red aún.
3. Existe una zona implícita de nombre fw (o $FW como nombre alterno) y tipo firewall que hace referencia al mismo
host Linux que se comporta como Firewall.
4. Cualquiera de las otras zonas de red se define con un nombre en la primera columna (LAN, WAN o DMZ) y el tipo ipv4.
5. Por defecto los nombres de zonas no deberían ser mayores a 5 caracteres de longitud, pudiendo ser en mayúsculas o
minúsculas. Las palabras all, none, SOURCE y DEST están reservados por Shorewall y no deberían ser usados como
nombres de zonas.
Importante:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 289
Source Linux
Sobre este archivo es importante comprender que:
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
4. La segunda columna especifica el nombre de una interfaz de red (Ejm: eth0, eth1) existente en el sistema. No se admiten
alias de interfaces tales como eth0:0, eth2:1, etc.
5. La tercera columna permite especificar la dirección de broadcast asociada a la interfaz de red. Si la interfaz posee
múltiples direcciones IP, entonces se puede especificar en esta columna cada una de las direcciones de broadcast
separadas por coma.
Si se especifica la palabra especial detect entonces Shorewall automáticamente detectará la dirección o direcciones de
broadcast para la interfaz.
6. La cuarta columna permite especificar distintas opciones a través de palabras clave que las identifican. Algunas de estas
opciones son las siguientes:
• nosmurfs : Rechaza paquetes smurfs, dirigidos a una dirección de broadcast para producir flooding.
• routeback : Permite que el tráfico entrante por una interfaz pueda salir de vuelta por la misma.
• routefilter : Activa el Reverse Path Filtering en la interfaz, como medida anti-spoofing.
• tcpflags : Rechaza paquetes con una combinación ilegal de flags TCP.
• logmartians : Guarda un log de paquetes marcianos, aquellos imposibles de provenir de la interfaz de red.
Importante:
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. El archivo define la acción a tomar sobre una zona cuando ninguna regla del archivo /etc/shorewall/rules coincida.
3. La primera columna especifica el nombre de una zona origen (Ejm: all, fw, LAN, DMZ)
4. La segunda columna especifica el nombre de una zona destino (Ejm: all, WAN, LAN).
5. La tercera columna define la acción a tomar como política sobre esta zona. Puede definirsen acciones como ACCEPT,
DROP o REJECT.
6. La cuarta columna define el nivel de registro que se aplicará para el registro de la acción tomada de la política cuando se
envía al demonio syslog como log.
Importante:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 290
Source Linux
así que en este archivo se pueden controlar las conexiones permitidas desde Internet hacia nuestro host, las conexiones de la LAN
hacia Internet permitidas, la publicación de servicios en una DMZ a través de una operación DNAT (Destination NAT), o
redireccionar el tráfico saliente al puerto 80 hacia nuestro puerto local de un servidor proxy (transparente), entre otros.
El contenido de este archivo puede ser similar al debajo mostrado:
SECTION NEW
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. El archivo define las reglas de filtrado y NAT que se aplican a la comunicación entre las distintas zonas declaradas.
3. El orden de las reglas en este archivo tiene importancia, ya que la primera línea coincidente define la acción a aplicar
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 291
Source Linux
sobre una conexión.
4. Las reglas pueden ser definidas dentro del ámbito de conexiones con estado NEW, STABLISHED o RELATED de acuerdo
a la directiva SECTION como figura en la primera línea del archivo.
5. La primera columna especifica una acción a tomar tal como ACCEPT, DROP, REJECT, NONAT, DNAT, REDIRECT, LOG
acorde a:
6. La segunda columna define los hosts origen de la conexión hacia la cual se aplica la regla. Se puede especificar aquí una
zona previamente declarada, y seguida de dos puntos (:) una o más direcciones o rangos de direcciones.
7. La tercera columna define los hosts destino (servidores) de la conexión hacia la cual se aplica la regla. Se puede
especificar aquí una zona previamente declarada, y seguida de dos puntos (:) una o más direcciones o rangos de
direcciones.
8. La cuarta columna define el protocolo de la conexión. Puede ser: tcp, udp, icmp u otro definido en /etc/protocols
9. La quinta columna define el(los) puerto(s) o rango de puertos destino de la conexión cuando ésta es de tipo tcp o udp.
10. La sexta columna define el(los) puerto(s) o rango de puertos origen de la conexión cuando ésta es de tipo tcp o udp.
11. La séptima columna, válida sólo para las acciones DNAT y REDIRECT, permite definir la dirección IP original a la cual
estaba destinada la conexión antes de ser manipulada con DNAT o REDIRECT.
12. La octava columna permite definir un límite de las conexiones en intervalos de tiempo. Se especifica como
N/intervalo[:ráfaga] donde N es la cantidad de conexiones, intervalo es una expresión de tiempo como sec
(segundo), min (minuto), hour (hora) o day (día); mientras que ráfaga es la cantidad máxima de conexiones permitidas
antes que se alcance el intervalo de tiempo.
Importante:
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. El archivo define las reglas de enmascaramiento y SNAT que se aplican sobre los clientes que se comunican entre dos
zonas distintas del Firewall.
3. El orden de las reglas en este archivo tiene importancia, ya que la primera línea coincidente define la acción de
traducción o enmascaramiento a aplicar sobre una conexión.
4. La primera columna define la interfaz de red saliente a través de la cual se espera que salgan los paquetes a
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 292
Source Linux
enmascararse.
5. La segunda columna define las direcciones IP de los hosts origen que se desea enmascarar.
6. La tercera columna define la dirección IP con la que se enmascara a las conexiones salientes de los clientes. Esta
dirección IP debe estar asignada a la interfaz de red definida en la primera columna.
7. La cuarta columna define el protocolo de la conexión. Esto permite aplicar la regla de enmascaramiento cuando la
conexión coincida con cierto tipo de protocolo.
8. La quinta columna define uno o más puertos destino de la conexión. Al igual que en el protocolo, esto permite aplicar el
enmascaramiento a una conexión específica según el número de puerto(s).
Importante:
STARTUP_ENABLED=Yes
...
...
IP_FORWARDING=On
...
...
En el caso de Debian y derivados, puede ser también necesario que se habilite el inicio de Shorewall editando el archivo
/etc/default/shorewall como sigue:
startup=1
...
...
Al igual que con la mayoría de servicios estudiados, se requiere revisar la correcta sintaxis de los archivos de configuración para lo
cual ejecutaremos la siguiente orden:
# shorewall check
Lo anterior debería resumir de los chequeos hechos a las configuraciones e informar de cualquier error encontrado. Si no se
genera ninguna advertencia ni error, entonces se puede proceder a manipular el inicio, apagado o reinicio de Shorewall con los
siguientes comandos:
# shorewall start
# shorewall stop
# shorewall restart
Importante:
Configuración de NAT 1 a 1
La siguiente configuración tiene por objetivo crear reglas de NAT 1 a 1, asociando una o más direcciones IP externas de un Firewall a
uno o más hosts del segmento de la LAN. Se puede tomar como referencia la siguiente imagen:
OpenSourceCollege www.opensourcecollege.com
Linux for SysAdmins
Primer centro de capacitación Open
Página 293
Source Linux
Este escenario permite que los hosts del segmento IP 10.1.1.* aparenten pertenecer al segmento 130.252.100.*. Para ello asumiremos
que:
• La interfaz de red eth0 del Firewall es la que posee las direcciones IP externas..
• El host 10.1.1.2 aparentaría tener la IP 130.252.100.18.
• El host 10.1.1.3 aparentaría tener la IP 130.252.100.19.
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. Este archivo define la asociación de direcciones IP externas con direcciones IP internas de una LAN tanto para el tráfico
entrante como saliente.
3. La primera columna define una dirección IP externa asociada a la interfaz de red para configurarla en NAT 1 a 1. Esta
dirección IP no debe ser la primera asignada a la interfaz de red externa.
4. La segunda columna define la interfaz de red que posee las direcciones externas. Si la directiva ADD_IP_ALIASES tiene
el valor de Yes en el archivo /etc/shorewall/shorewall.conf entonces Shorewall asignará automáticamente a esta interfaz de
red la dirección IP externa, permitiendo también especificar luego de la interfaz y separado por dos puntos (:) el nombre
que tendrá el alias de la interfaz de red.
6. La cuarta columna si tiene el valor Yes entonces la regla de NAT 1 a 1 será efectiva desde cualquier host, es decir desde
cualquier interfaz de red. Si tiene el valor No entonces la regla NAT funcionará sólo desde la interfaz de red definida enl a
segunda columna.
7. La quinta columna si tiene el valor Yes entonces la regla de NAT será efectiva desde el mismo host del Firewall, de lo
contrario (valor No) sólo funcionará desde otros hosts distintos al Firewall.
8. Las reglas de NAT 1 a 1 sólo involucran las tareas de traducción mas no la permisividad de las conexiones. Esto quiere
decir que si por ejemplo alguno de estos hosts (10.1.1.3) ofreciese un servicio FTP, sería necesario de todos modos crear
una regla correspondiente en /etc/shorewall/rules como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 294
Source Linux
Importante:
# shorewall check
Si no se encontró ningún error en la configuración procedemos a aplicar los cambios reiniciando Shorewall:
# shorewall restart
/etc/shorewall/zones
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
/etc/shorewall/interfaces
#ZONE INTERFACE BROADCAST OPTIONS
WAN eth0 detect tcpflags,routefilter,nosmurfs
LAN eth1 detect tcpflags,routefilter,nosmurfs
/etc/shorewall/policy
#SOURCE DEST POLICY
fw all ACCEPT
all all DROP
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
ACCEPT WAN $FW icmp
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 295
Source Linux
ACCEPT LAN WAN udp 53,123
/etc/shorewall/masq
#INTERFACE SOURCE ADDRESS PROTO PORT(S)
eth0 192.168.0.0/24
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. Este archivo define las interfaces de red a aplicar QoS y las características de ancho de banda de cada una de ellas.
4. La primera columna define la interfaz de red. No se admiten alias de interfaces de red como eth0:0, eth1:2, etc.
5. La segunda columna define el ancho de banda máximo soportado por la interfaz para tráfico entrante. Esto no implica
que se controlará la velocidad del tráfico entrante en esta interfaz (no es posible hacerlo) sino sólo sirve para poder
rechazar paquetes que intenten ingresar a una tasa de transferencia mayor a la soportada por la interfaz.
Si no se desea rechazar ninguna conexión entrante sin importar su velocidad se puede colocar un valor 0 (cero) en esta
columna.
6. La tercera columna define el ancho de banda máximo soportado por la interfaz para tráfico saliente.
Importante:
• Las herramientas de traffic shaping en Linux no permiten por defecto controlar el tráfico entrante a una interfaz sino sólo
el saliente. Esto se debe a que las conexiones entrantes a una interfaz corresponden a tráfico que ya llegó y es muy
tarde ya para ejercer cualquier control de velocidad.
Esto significa que normalmente sólo podríamos controlar la velocidad del tráfico de "subida" mas no la de "bajada".
• Sin embargo para superar la anterior limitación del tráfico entrante, se puede utilizar dos interfaces de red, en la cual eth0
-conectada a Internet- será usada para limitar el tráfico saliente (de subida), y eth1 -conectada a la LAN- será usada para
limitar el tráfico saliente (simulando tráfico de bajada para los usuarios de la LAN). Sin embargo hay que considerar que
el tráfico saliente de eth1 no siempre corresponderá a tráfico reenviado de bajada de los usuarios de la LAN, sino que
también puede corresponder a tráfico generado por el mismo Firewall hacia los hosts de la LAN y en este caso no se
debería limitar la velocidad.
• Acorde a la información dada, el tráfico máximo de subida (200 kbps) se define como OUT-BANDWIDTH en la interfaz
eth0, pero el tráfico máximo de bajada (1 mbps) no se ha definido ni en eth0 ni eth1. Esto se debe a que eth1 debe
trabajar a su máxima velocidad (100 Mbps siendo una interfaz Fast Ethernet) para la comunicación entre el Firewall y la
LAN.
El tráfico saliente de eth1 que corresponda a las descargas de los usuarios se controlará en otro archivo.
• La documentación completa del archivo /etc/shorewall/tcdevices se puede encontrar en shorewall-tcdevices(5)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 296
Source Linux
#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
eth0 1 20*full/100 full 1 tcp-ack,tos-minimize-delay
eth0 2 20*full/100 full 2
eth0 3 50*full/100 full 3
eth0 4 10*full/100 full 4 default
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. Este archivo define las clases de control de ancho de banda, con sus prioridades, tasas de transferencia mínimas y
máximas así como otros atributos.
3. Se han de seguir las mismas convenciones que en el archivo /etc/shorewall/tcdevices sobre kbps, mbps, kbit y mbit.
4. La primera columna define la interfaz de red. No se admiten alias de interfaces de red como eth0:0, eth1:2, etc.
5. La segunda columna define la marca asociada a la clase; debe ser un valor entre 1 y 255. En el archivo
/etc/shorewall/tcrules se definen las marcas asociadas a ciertos paquetes que caerán dentro de esta clase si corresponde
con la misma marca.
6. La tercera columna define el ancho de banda mínimo que esta clase debería tener asegurada cuando el tráfico total se
incrementa. La suma de todos los valores de esta columna pertenecientes a una misma interfaz debe ser igual al valor de
la columna OUT-BANDWIDTH de la misma interfaz en el archivo /etc/shorewall/tcdevices.
7. La cuarta columna define el ancho de banda máximo que esta clase debería recibir cuando la línea se encuentra inactiva
o no utilizada por otras clases. Se puede usar valores especificados con sufijos kbps, kbit u otros, o se puede especificar
la palabra especial full que hará referencia al máximo de ancho de banda declarado para la interfaz de red en
/etc/shorewall/tcdevices (OUT-BANDWIDTH).
También es posible especificar valores porcentuales respecto a full con operadores matemáticos. Por ejemplo 20% de
full se expresaría como 20*full/100.
8. La quinta columna define la prioridad en la que se atiende a esta clase sobre otras. A menor valor numérico mayor será la
prioridad, siendo 1 la máxima posible.
9. La sexta columna define ciertas opciones disponibles para las clases, de acuerdo a lo debajo indicado:
• default : Convierte a la clase en la predeterminada o por defecto para aquellos paquetes que no han
sido clasificados por ninguna regla en /etc/shorewall/tcrules. Se debe definir sólo una clase con esta opción por cada
interfaz.
• tcp-ack : Clasifica en esta clase a los paquetes TCP ACK de tamaño menor o igual a 64 bytes. Si se
especifica esta opción entonces se ignorará la marca (segunda columna), es decir se incluye en esta clase al
paquete ACK (menor a 64 bytes) sin importar con qué marca haya podido ser clasificado anteriormente.
Se debe definir sólo una clase con esta opción por cada interfaz.
• tos-TOS : Clasifica en esta clase a los paquetes que tengan el campo TOS (Type of Service) igual a uno
de los aquí especificados con tos-TOS. TOS puede ser: minimize-delay, maximize-throughput, minimize-
cost o normal-service.
Se debe definir sólo una clase con esta opción por cada interfaz.
Importante:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 297
Source Linux
/etc/shorewall/tcrules el cual debería tener un contenido como el siguiente:
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. Este archivo define las clases de control de ancho de banda, con sus prioridades, tasas de transferencia mínimas y
máximas así como otros atributos.
3. Al contrario de lo que sucede en /etc/shorewall/rules las reglas en este archivo se continúan leyendo aún luego de una
coincidencia, de modo tal que la regla que se aplicará sobre un paquete será la última que coincida en la lectura vertical
(desde arriba hacia abajo).
4. La primera columna define la marca que se debe aplicar al paquete. Luego de los dos puntos (:) se puede especificar
una letra que identifica la cadena de netfilter en la cual se hará el marcado. Las letras posibles son F (FORWARD), P
(PREROUTING) y T (POSTROUTING). El marcar los paquetes en la cadena POSTROUTING permite aplicar la regla tanto a
paquetes originados en el mismo Firewall así como también aquellos que se reenvíen a través del Firewall.
5. La segunda columna define la dirección origen de la conexión. Puede ser un host o una dirección de red especificada con
su máscara de red.
6. La tercera columna define la dirección destino de la conexión. De igual sintaxis que la columna anterior.
7. La cuarta columna permite especificar el protocolo de la conexión. Puede ser tcp, udp, icmp u otro protocolo existente
en /etc/protocols.
8. La quinta columna define el puerto destino de la conexión. Válido sólo para protocolos tcp y udp.
9. La sexta columna define el puerto origen de la conexión. De igual sintaxis que la columna anterior.
Ahora con sólo analizar qué paquetes han sido marcados con qué números y comparándolos con la información definida en
/etc/shorewall/tcclasses se puede saber el ancho de banda que se reserva para las conexiones arriba descritas.
Importante:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 298
Source Linux
Ahora se requiere revisar la correcta sintaxis de los archivos de configuración para lo cual ejecutaremos la siguiente orden:
# shorewall check
Si no se encontró ningún error en la configuración procedemos a aplicar los cambios reiniciando Shorewall:
# shorewall restart
• eth0 está conectado al ISP1. La IP de eth0 es 206.124.146.176 y del router del ISP1 es 206.124.146.254.
• eth1 está conectado al ISP2. La IP de eth1 es 130.252.99.27 y del router del ISP1 es 130.252.99.254.
• eth2 está conectada a LAN. Su dirección IP no es relevante a esta configuración.
/etc/shorewall/zones
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
Se recomienda definir ambas interfaces conectadas a los proveedores ISP1 e ISP2 como miembros de la zona WAN:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 299
Source Linux
/etc/shorewall/interfaces
#ZONE INTERFACE BROADCAST OPTIONS
WAN eth0 detect tcpflags,routefilter,nosmurfs
WAN eth1 detect tcpflags,routefilter,nosmurfs
LAN eth2 detect tcpflags,routefilter,nosmurfs
Por seguridad se recomienda que cualquier posible tráfico que ingrese por uno de los proveedores y pretenda salir por el otro
(desde WAN hacia WAN) sea denegado:
/etc/shorewall/policy
#SOURCE DEST POLICY
fw all ACCEPT
WAN WAN DROP
all all DROP
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
ACCEPT WAN $FW icmp
/etc/shorewall/masq
#INTERFACE SOURCE ADDRESS PROTO PORT(S)
eth0 192.168.0.0/24
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. Este archivo define los distintos proveedores (enrutadores) existentes, dándoles a cada una un nombre, identificador
numérico propio y número de marca que clasificará los paquetes en cada uno de ellos.
3. La primera columna define un nombre del proveedor, el mismo que también será asignado como nombre a su respectiva
tabla de enrutamiento.
4. La segunda columna asigna un identificador numérico único al proveedor, asociado también a su respectiva tabla de
enrutamiento.
5. La tercera columna define un número de marca que deben tener los paquetes para ser enrutados por este proveedor.
6. La cuarta columna define el nombre de una tabla de enrutamiento existente en el sistema desde la cual se debe copiar
su contenido (sus rutas) para crear la tabla de rutas de este proveedor. Por lo general aquí se debería especificar el
nombre main que corresponde a la tabla de enrutamiento principal predeterminada del sistema.
8. La sexta columna define la dirección IP de la puerta de enlace que ofrece el proveedor (dirección del router).
9. La séptima columna define opciones de las cuales sólo track y balance deberían incluirse. La explicación de éstas se
muestra debajo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 300
Source Linux
• track : Las respuestas (salientes) de conexiones previas entrantes deben enrutarse por la misma interfaz que
ingresó. Se recomienda siempre incluir esta opción.
• balance : El tráfico saliente debe ser balanceado entre ambos proveedores. Se recomienda activar esta opción
incluso si algunos paquetes serán enrutados siempre por un mismo proveedor de acuerdo a las reglas de
clasificación en /etc/shorewall/tcrules.
10. La octava columna define las interfaces adicionales en las cuales se copiará la tabla de enrutamiento de este proveedor.
Se recomienda incluir aquí todas las interfaces de red del sistema excepto aquellas ya declaradas en este archivo.
Importante:
La sintaxis de este archivo ya se debe conocer por lo que se pasará a analizar el significado de esta configuración:
• Todo el tráfico proveniente de la red 192.168.0.0/24 (vía eth2) será enrutado por defecto por el ISP1.
• El host 192.168.0.3 será enrutado por el ISP2.
• Todo el tráfico originado por el mismo Firewall será enrutado por el proveedor ISP2.
• Sólo el tráfico SMTP saliente originado por el mismo Firewall se enrutará por el proveedor ISP1.
Aquí se especifica que la publicación (DNAT) del servicio Web (TCP 80) se hará sólo a través del proveedor ISP1, conectado vía
eth0.
# shorewall check
Si no se encontró ningún error en la configuración procedemos a aplicar los cambios reiniciando Shorewall:
# shorewall restart
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 301
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 302
Source Linux
Administración de Shorewall desde Webmin
Webmin es una herramienta de configuración de servicios para plataformas Linux y otros UNIX. A través de esta herramienta podemos
configurar y monitorear la configuración del Firewall con Shorewall siguiendo estos pasos:
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
5. Dentro de Webmin acceder a 'Servers -> Shoreline Firewall' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 303
Source Linux
14.3. Laboratorio N° 14
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Se tiene un Firewall con dos interfaces de red, eth0 y eth1. La primera está conectada a un router Cisco que provee una
línea simétrica de 1 Mbps (overbooking 1:1) y la segunda a un switch que alimenta a una red LAN 192.168.10.0/24. Además
en el Firewall está ejecutándose un servidor SSH, un servidor Proxy con Squid, un servidor DNS caché con BIND, un
servidor NTP y una instancia del servidor OpenVPN el mismo que ha creado una interfaz de red tun0 para la conexión de
túneles remotos.
Se requiere crear las reglas básicas de Firewall de modo que se cumplan los siguientes requisitos:
a) El Firewall debe atender sólo a las conexiones SSH y OpenVPN (puerto UDP 1194) desde Internet.
b) Se debe controlar las conexiones SSH entrantes a un límite de 5 conexiones por minuto como máximo, con una ráfaga
de 7 que invoque al bloqueo de los siguientes intentos de conexión.
c) Los usuarios de la LAN deben poder acceder a los servicios Proxy, DNS y NTP que ofrece el Firewall.
d) Sólo el host de la LAN con dirección MAC 00:24:81:35:2B:6E podrá conectarse por SSH al Firewall, y también tendrá
acceso libre a Internet (sin restricciones) a todos los puertos.
e) Cualquier consulta DNS hecha por los clientes a servidores externos debe ser interceptada por el Firewall y procesada
por el servidor DNS local que ahí corre como caché.
f) Los clientes de la LAN sólo podrán acceder hacia Internet para enviar paquetes ICMP y conexiones SMTP salientes.
g) Los clientes VPN sólo podrán comunicarse con el Firewall para enviar paquetes ICMP y sincronizar el tiempo vía NTP.
h) Se debe permitir acceso total (permitir todo el tráfico) entre los clientes remotos VPN y la red LAN.
i) Se ha de enmascarar a todos los clientes de la LAN con la primera dirección asignada a la interfaz eth0.
j) Redireccionar las conexiones HTTP salientes al proxy local (proxy transparente)
k) Se debe reservar el 10% del ancho de banda para paquetes TCP ACK (de subida), un 30% para tráfico SMTP saliente
(de subida), un 20% para conexiones SSH del exterior hacia el Firewall (de subida) y el resto ser asignado a libre
demanda. El tráfico de bajada no será controlado debido a que los usuarios sólo navegarán por la Web vía proxy el cual
ya implementará los controles de ancho de banda necesarios.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 304
Source Linux
14.3.1. Solución del laboratorio N° 14
1. Se tiene un Firewall con dos interfaces de red, eth0 y eth1. La primera está conectada a un router Cisco que provee una
línea simétrica de 1 Mbps (overbooking 1:1) y la segunda a un switch que alimenta a una red LAN 192.168.10.0/24. Además
en el Firewall está ejecutándose un servidor SSH, un servidor Proxy con Squid, un servidor DNS caché con BIND, un
servidor NTP y una instancia del servidor OpenVPN el mismo que ha creado una interfaz de red tun0 para la conexión de
túneles remotos.
Se requiere crear las reglas básicas de Firewall de modo que se cumplan los siguientes requisitos:
a) El Firewall debe atender sólo a las conexiones SSH y OpenVPN (puerto UDP 1194) desde Internet.
b) Se debe controlar las conexiones SSH entrantes a un límite de 5 conexiones por minuto como máximo, con una ráfaga
de 7 que invoque al bloqueo de los siguientes intentos de conexión.
c) Los usuarios de la LAN deben poder acceder a los servicios Proxy, DNS y NTP que ofrece el Firewall.
d) Sólo el host de la LAN con dirección MAC 00:24:81:35:2B:6E podrá conectarse por SSH al Firewall, y también tendrá
acceso libre a Internet (sin restricciones) a todos los puertos.
e) Cualquier consulta DNS hecha por los clientes a servidores externos debe ser interceptada por el Firewall y procesada
por el servidor DNS local que ahí corre como caché.
f) Los clientes de la LAN sólo podrán acceder hacia Internet para enviar paquetes ICMP y conexiones SMTP salientes.
g) Los clientes VPN sólo podrán comunicarse con el Firewall para enviar paquetes ICMP y sincronizar el tiempo vía NTP.
h) Se debe permitir acceso total (permitir todo el tráfico) entre los clientes remotos VPN y la red LAN.
i) Se ha de enmascarar a todos los clientes de la LAN con la primera dirección asignada a la interfaz eth0.
j) Redireccionar las conexiones HTTP salientes al proxy local (proxy transparente)
k) Se debe reservar el 10% del ancho de banda para paquetes TCP ACK (de subida), un 30% para tráfico SMTP saliente
(de subida), un 20% para conexiones SSH del exterior hacia el Firewall (de subida) y el resto ser asignado a libre
demanda. El tráfico de bajada no será controlado debido a que los usuarios sólo navegarán por la Web vía proxy el cual
ya implementará los controles de ancho de banda necesarios.
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 305
Source Linux
# PORT PORT(S) DEST LIMIT
# Permitir acceso al servicio OpenVPN desde Internet según requerimiento (a)
ACCEPT WAN $FW udp 1194
# Permitir acceso al servicio SSH desde Internet con límites según requerimiento (b)
ACCEPT WAN $FW tcp 22 - - 5/min:7
# Los clientes VPN acceden a los servicios NTP y envían paquetes al firewall únicamente
# según requerimiento (g)
ACCEPT VPN $FW icmp
ACCEPT VPN FW udp 53
# Los clientes de la LAN acceden hacia Internet con paquetes ICMP y SMTP según
# requerimiento (f)
ACCEPT LAN WAN icmp
ACCEPT LAN WAN tcp 25
# shorewall check
# shorewall restart
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 306
Source Linux
Unidad 15: Proxy de control de navegación Web
15.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
¿Qué es un proxy?
El término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más
habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo
se puede disponer de un único equipo conectado, esto es, una única dirección IP.
Se tiene que existen varios tipos de proxies según los protocolos que atienden, así hay proxies Web como Squid, proxies FTP
como Frox, proxies SIP como SER, entre otros.
El objetivo de esta parte del documento es estudiar el proxy Web Squid.
Aparte de la utilidad general de un proxy, proporciona una cache para las páginas web y los contenidos descargados, que es
compartida por todos los equipos de la red, con la consiguiente mejora en los tiempos de acceso para consultas coincidentes. Al
mismo tiempo libera la carga de los enlaces hacia Internet.
Funcionamiento:
1. El cliente realiza una petición (p.e. mediante un navegador web) de un recurso de Internet (una página web o cualquier
otro archivo) especificado por una URL.
2. Cuando el proxy caché recibe la petición, busca la URL resultante en su caché local. Si la encuentra, devuelve el
documento inmediatamente, si no es así, lo captura del servidor remoto, lo devuelve al que lo pidió y guarda una copia en
su caché para futuras peticiones.
El caché utiliza normalmente un algoritmo para determinar cuándo un documento está obsoleto y debe ser eliminado de la caché,
dependiendo de su antigüedad, tamaño e histórico de acceso. Dos de esos algoritmos básicos son el LRU (el usado menos
recientemente, en inglés "Least Recently Used") y el LFU (el usado menos frecuentemente, "Least Frequently Used").
Los proxies web también pueden filtrar el contenido de las páginas Web servidas. Algunas aplicaciones que intentan bloquear
contenido Web ofensivo están implementadas como proxies Web. Otros tipos de proxy cambian el formato de las páginas web para
un propósito o una audiencia específicos, para, por ejemplo, mostrar una página en un teléfono móvil o una PDA. Algunos
operadores de red también tienen proxies para interceptar virus y otros contenidos hostiles servidos por páginas Web remotas.
Proxies transparentes
Muchas organizaciones (incluyendo empresas, colegios y familias) usan los proxies para reforzar las políticas de uso de la red o
para proporcionar seguridad y servicios de caché. Normalmente, un proxy Web o NAT no es transparente a la aplicación cliente:
debe ser configurada para usar el proxy, manualmente. Por lo tanto, el usuario puede evadir el proxy cambiando simplemente la
configuración.
Un proxy transparente combina un servidor proxy con NAT de manera que las conexiones son enrutadas dentro del proxy sin
configuración por parte del cliente, y habitualmente sin que el propio cliente conozca de su existencia. Este es el tipo de proxy que
utilizan los proveedores de servicios de internet (ISP). En España, la compañía más expandida en cuanto a ADSL se refiere, ISP
Telefónica, dejó de utilizar proxy transparente con sus clientes a partir de Febrero de 2006.
Ventajas:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 307
Source Linux
• Control: Sólo el intermediario hace el trabajo real, por tanto se pueden limitar y restringir los derechos de los usuarios, y
dar permisos sólo al proxy.
• Anonimato: Si todos los usuarios se identifican como uno sólo, es difícil que el recurso accedido pueda diferenciarlos.
Pero esto puede ser malo, por ejemplo cuando hay que hacer necesariamente la identificación.
• Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y no a Internet directamente. Por lo tanto,
aligera el tráfico en la red y descarga los servidores destino, a los que llegan menos peticiones.
• Velocidad en Tiempo de respuesta: El servidor Proxy crea un caché que evita transferencias idénticas de la información
entre servidores durante un tiempo (configurado por el administrador) así que el usuario recibe una respuesta más
rápida.
• Demanda a Usuarios: Puede cubrir a un gran número de usuarios, para solicitar, a través de él, los contenidos Web.
• Filtrado de contenidos: El servidor proxy puede hacer un filtrado de páginas o contenidos basándose en criterios de
restricción establecidos por el administrador dependiendo valores y características de lo que no se permite, creando una
restricción cuando sea necesario.
• Modificación de contenidos: Basándose en la misma función del filtrado, y llamado Privoxy, tiene el objetivo de proteger la
privacidad en Internet, puede ser configurado para bloquear direcciones y Cookies por expresiones regulares y modifica
en la petición el contenido.
Desventajas:
• Abuso: Al estar dispuesto a recibir peticiones de muchos usuarios y responderlas, es posible que haga algún trabajo que
no toque. Por tanto, ha de controlar quién tiene acceso y quién no a sus servicios, cosa que normalmente es muy difícil.
• Carga: Un proxy ha de hacer el trabajo de muchos usuarios.
• Intromisión: Es un paso más entre origen y destino, y algunos usuarios pueden no querer pasar por el proxy. Y menos si
hace de caché y guarda copias de los datos.
• Incoherencia: Si hace de caché, es posible que se equivoque y dé una respuesta antigua cuando hay una más reciente
en el recurso de destino.
• Irregularidad: El hecho de que el proxy represente a más de un usuario da problemas en muchos escenarios, en concreto
los que presuponen una comunicación directa entre 1 emisor y 1 receptor (como TCP/IP).
• Las páginas mostradas pueden no estar actualizadas si éstas han sido modificadas desde la última carga que realizó el
proxy caché.
Un diseñador de páginas web puede indicar en el contenido de su web que los navegadores no hagan una caché de sus
páginas, pero este método no funciona habitualmente para un proxy.
• El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, impide realizar operaciones
avanzadas a través de algunos puertos o protocolos.
• Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas
personas.
Características:
Instalación de Squid
El procedimiento de instalación de Squid es sencillo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 308
Source Linux
En Debian y derivados:
Configuración de Squid
Squid centraliza su configuración en un único archivo de texto plano el cual es /etc/squid/squid.conf. La sintaxis de todo el archivo es
bastante simple y se ajusta al siguiente formato:
Además al igual que en muchos ficheros de configuración se tiene que el caracter # sirve para dar inicio a un comentario y todo el texto
que venga a continuación a su derecha será simplemente ignorado por el programa Squid.
A continuación detallaremos una serie de directivas de configuración de Squid que son por lo general algunas de las más comunes e
importantes.
http_port
Permite especificar las direcciones de escucha del servicio por las diferentes interfaces existentes en el sistema. La opción
transparent le da soporte a Squid para aceptar conexiones de proxy transparente.
Ejemplos:
cache_dir
Define cual es el directorio para almacenamiento de objetos de caché. Este directorio usa un tipo de almacenamiento que puede
ser ufs (mayormente usado), aufs (usado con Async I/O).
El tamaño es la capacidad máxima de objetos de caché que pueden almacenarse expresado en Mbytes en el directorio
especificado. Ndir1 y Ndir2 definen la cantidad de directorios de primer y segundo nivel respectivamente que se crean en el
directorio de la caché.
Ejemplo:
cache_access_log
Ruta del archivo de registro de consultas de los clientes conteniendo todas las páginas visitadas.
Ejemplo:
cache_access_log /var/log/squid/access.log
cache_log
Ruta de archivo de registro del desempeño y comportamiento de la caché y en general del servicio Squid.
Ejemplo:
cache_log /var/log/squid/cache.log
cache_store_log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 309
Source Linux
Ruta del archivo de registro de los objetos guardados y removidos de la caché.
Ejemplo:
cache_store_log /var/log/squid/store.log
cache_swap_log
Ruta del archivo que contiene los metadatos de objetos guardados en el disco. Este archivo es usado para reconstruir la caché en
el arranque de Squid.
Ejemplo:
cache_swap_log /var/log/squid/swap.log
useragent_log
Ruta del archivo de registro del campo User-Agent para todas las peticiones HTTP. Ejemplo:
Ejemplo:
useragent_log /var/log/squid/useragent.log
log_mime_hdrs
Registrar los tipos MIME en cada petición HTTP.
Ejemplo:
log_mimre_hdrs off
pid_filename
Ruta del archivo que contiene el PID de Squid en ejecución.
Ejemplo:
pid_filename /var/run/squid.pid
mime_table
Ruta del archivo de los tipos MIME reconocidos.
Ejemplo:
mime_table /etc/squid/mime.conf
no_cache
Permite que ciertos objetos que coincidan con una ACL sean o no sean almacenados en la caché (allow o deny).
En el siguiente ejemplo se define una ACL de nombre "QUERY" la cual coincide con URLs que terminen con las extensiones .php,
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 310
Source Linux
.asp o contengan "?" siendo típicos de sitios dinámicos. Así se evita que se almacene sitios dinámicos en la caché:
cache_mem
Cantidad de memoria que se usa para objetos en transito de la caché. Se recomienda un aproximado de la tercera parte de la
cantidad total de RAM del sistema.
Ejemplo:
cache_mem 78 MB
cache_swap_low
cache_swap_high
Marca inferior y superior de la cantidad de espacio en uso de la caché que determina cuando deben eliminarse objetos de la caché
con mayor o menor intensidad; todo esto a fin de no llegar al límite de la capacidad máxima de almacenamiento provocando la falla
en el servicio Squid.
El siguiente ejemplo intentará mantener el directorio de la caché en un uso entre 90% y 95% de modo que cuando esté más cerca
al límite inferior la eliminación de objetos será algo moderada mientras que cuando esté más cerca al límite superior la eliminación
de objetos se hará más agresiva a fin de mantenerse dentro de los límites establecidos:
cache_swap_low 90
cache_swap_high 95
cache_effective_user
cache_effective_group
Usuario y grupo bajo el cual se ejecuta el servicio Squid.
Ejemplo:
cache_effective_user squid
cache_effective_group squid
cache_mgr
Dirección e-mail del administrador del servidor proxy. Esta dirección figurará en los mensajes de error generados por Squid
mostrados a los clientes.
Ejemplo:
cache_mgr soporte@consultorianet.com
visible_hostname
Nombre FQDN que identifica al servidor proxy. Este valor será mostrado como pie de página en cada uno de los mensajes de error
generados por Squid mostrados a los clientes.
Ejemplo:
visible_hostname proxy.consultorianet.com
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 311
Source Linux
ftp_passive
Activar o desactivar el comportamiento pasivo en las conexiones FTP.
Ejemplo:
ftp_passive on
ftp_user
Dirección e-mail a ser validada por los servidores FTP con los cuales se establecen conexiones anónimas.
Ejemplo:
ftp_user soporte@consultorianet.com
dns_nameservers
Especifica una lista de servidores DNS a usar para la resolución de nombres en lugar de los que están especificados en el archivo
"/etc/resolv.conf".
Ejemplo:
auth_param
Define los parámetros para varios esquemas de autenticación soportados por Squid. Los esquemas de autenticación soportados
son basic, digest y ntlm.
Los parámetros pueden ser distintos dependiendo del esquema de autenticación usado, pero los del esquema basic son:
program comando
Especifica el programa externo para realizar la autenticación. En la distribución original obtenida del tarball de squid dentro del
directorio 'helpers' se encuentran varios directorios con el código fuente de los programas disponibles para ser usados
categorizados según el esquema elegido.
children N°
La cantidad de instancias del programa a iniciar para la autenticación.
realm texto
Especifica un texto mostrado al cliente en el momento al que éste se le pide autenticarse.
casesensitive on|off
Indica si los nombres de usuario son sensibles a mayúsculas o no.
credentialsttl TTL
Especifica por cuánto tiempo Squid cree que las credenciales de un usuario son válidas luego de haberse autenticado. Esto se
refleja en cuán seguido Squid pedirá al usuario volver a autenticarse.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 312
Source Linux
logfile_rotate
Especifica la cantidad de logs antiguos que se han de mantener en cada rotación de los logs cuando se invoque a "squid -k
rotate". En cada rotación un archivo de log se renombra a su similar de extensión ".0", y el anterior de extensión ".0" pasa a
ser ahora de extensión ".1", éste último pasa a ser ".2" en extensión y así sucesivamente hasta la cantidad de veces
especificada en esta directiva.
Ejemplo:
logfile_rotate 2
error_directory
Ruta del directorio que contiene los mensajes de error en distintos idiomas mostrados por Squid a los clientes. Estos directorios por
defecto suelen ubicarse en "/usr/share/squid/errors".
Ejemplo:
error_directory /usr/share/squid/errors/Spanish
forwarded_for
Activar o desactivar el uso de la cabecera X-Forwarded-For para las peticiones de los clientes conteniendo la dirección IP de
origen o del cliente. Esta directiva con su valor en off evita que servicios Web en Internet como http://checkip.dyndns.org, http://
www.cual-es-mi-ip.net o http://www.myip.dk muestren la dirección IP privada del cliente en lugar de mostrar la dirección IP
pública enmascarada a través de la cual se conectan.
Ejemplo:
forwarded_for off
redirect_program
Especifica la ruta de un programa y sus respectivos parámetros al que Squid cederá el control en cada consulta de los clientes para
realizar operaciones de filtrado.
redirect_children
Número de instancias del programa de redirección que se van a iniciar.
Ejemplo:
redirect_children 8
acl
Define un Access Control List (Lista de control de acceso) con un nombre determinado y de un tipo especificado el cual puede
aceptar una serie de parámetros. Estos parámetros pueden ser especificados al lado derecho a continuación del tipo de la ACL o
bien pueden ser especificados como la ruta de un archivo (encerrado entre doble comillas) que contiene dichos parámetros.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 313
Source Linux
src dirección[/máscara]
Consulta la dirección IP del cliente. Ejemplos:
dst dirección[/máscara]
Consulta la dirección IP destino de la consulta. Ejemplos:
srcdomain nombre_dominio
Consulta el nombre de host o dominio del cliente. Ejemplos:
dstdomain nombre_dominio
Consulta el nombre de host o dominio destino de la consulta. Ejemplos:
• S – Sunday
• M – Monday
• T – Tuesday
• W – Wednesday
• H – Thursday
• F – Friday
• A – Saturday
port puertos
Consulta el puerto al que el cliente realiza la conexión. Ejemplos:
method métodos
Hace referencia al método usado por el cliente para hacer sus peticiones. Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 314
Source Linux
acl metodospermitidos method GET POST HEAD
acl metodosprohibidos method TRACE
proxy_auth usuarios
Coincide con uno o más usuarios los cuales son autenticados por una aplicación externa definida en auth_param. Si se usa la
palabra REQUIRED en lugar de una lista de usuarios entonces coincide con cualquier usuario válido autenticado.
arp mac
Coincide con la dirección MAC del cliente que solicita las conexiones. Ejemplo:
http_access
Permite o deniega el acceso a una ACL previamente definida. Si no existen líneas de acceso entonces la acción por defecto es la
denegación. Si existen varias líneas de acceso pero ninguna causa genera coincidencias entonces la acción a tomar es el opuesto
a lo expresado en la última línea de acceso. Es decir si la última línea era allow entonces la acción por defecto final será deny, y
si la última era deny entonces la acción por defecto será allow.
Tener en cuenta también que todas las directivas http_access funcionan en jerarquía trayendo como consecuencia que si una de
estas directivas genera una coincidencia entonces se ejecuta su acción determinada y ya no se analizán otras líneas más abajo,
por lo tanto las líneas más restrictivas deben estar colocadas al inicio y las más permisivas hacia el final.
Ejemplo:
En el ejemplo de arriba a todos los usuarios se les deniega el acceso a otros puertos que no sean los definidos en la ACL
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 315
Source Linux
Safe_ports, luego los gerentes tienen todo el acceso libre hacia Internet y al resto de usuarios que coinciden con la ACL lan se
les da libre acceso primero denegandole el chat con MSN (ACL msn)y contenidos pornográficos (ACL porn). Finalmente a
cualquier usuario que no esté definido sobre ninguna de las ACL (all = 0.0.0.0) se le denegará el acceso por completo.
http_reply_access
Similar a http_access pero los accesos están aplicados ya no a las consultas de los clientes sino a las respuestas enviadas por
parte del servidor remoto ante previas peticiones de los clientes. Esto es más útil para controlar el tráfico de audio y video online
dada que su naturaleza es como una respuesta del servidor hacia el cliente que no podría ser controlado con http_access.
Ejemplo:
1) Permitir gerencia
2) Denegar messenger
3) Permitir correos !horario-oficina
4) Permitir contabilidad paginas-contables
5) Permitir red
6) Denegar Todos
De lo anterior se asume que 'gerencia', 'messenger', 'correos', 'horario-oficina', 'contabilidad', 'paginas-contables' y 'Todos' son
ACLs previamente definidas.
Analizaremos estas reglas de manera jerárquica para deducir lo siguiente:
(a) Los usuarios del grupo gerencia tienen acceso total sin ninguna restricción.
(b) A todos los demás usuarios (excepto gerencia) se les deniega el acceso al MSN (ACL 'messenger')
(c) A todos los demás usuarios se les permite el acceso a correos gratuitos tipo Hotmail, Yahoo, etc (ACL 'correos') sólo
fuera del horario de oficina (Negación de ACL 'horario-oficina').
(d) A los usuarios del área de contabilidad (ACL 'contabilidad') se les permitirá navegar sólo por páginas Web relacionadas a
su interés (ACL 'paginas-contables'). Además también del acceso a correos gratuitos según la regla anterior.
(e) A todos los usuarios de la organización (ACL 'red') se les permite libre acceso excepto a recursos afectos por
restricciones de reglas anteriores.
(f) Finalmente por defecto se deniega el acceso a cualquier otro usuario no definido en ningún grupo de usuarios (ACL
Todos). Esto es por una medida de seguridad imprescindible.
Analice la correcta interpretación de estas reglas de ejemplo con sumo cuidado para que sepa entenderlas y sobre todo crear sus
propias reglas acorde a sus necesidades.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 316
Source Linux
técnico de Proxy, los Delay Pools afectan los cache misses, no los cache hits.
Existen tres clases de Delay Pool lo que nos permite tener cierta flexibilidad en su uso. Antes de hablar sobre ellas imagine que un
Delay Pool, especialmente uno de la clase 1, es como un tanque de agua el cual tiene un tubo de entrada y otro de salida. El tubo de
entrada debido a su diámetro y a la apertura de la llave de paso solo permite que el agua entre a una tasa fija. El tubo de salida debido
a su gran diámetro no tiene estas limitaciones y puede vaciar el tanque inmediatamente si la llave de paso se abre lo suficiente.
Finalmente, el tanque siempre almacena una cantidad máxima de agua. Una vez hecho esto asocie:
1. El diámetro del tubo de entrada representa el ancho de banda disponible en total. Usted puede abrir la llave tanto como
pueda pero la cantidad máxima de agua que sale no sobrepasa un tope máximo.
2. La apertura de la llave de paso de entrada representa el canal destinado para uso del Proxy/Delay Pool respectivo. Esta es la
tasa [de llenado] del Delay Pool.
3. La cantidad máxima de agua que almacena el tanque es el tamaño (size) del Delay Pool. Esta es la parte menos
comprendida: el size del Delay Pool permite ráfagas (burst) de descarga mientras el Delay Pool se vacía. Cuando el Delay
Pool queda con un tamaño de cero solo es posible descargar a la rata definida (de nuevo imagine un caso de uso intensivo
del agua del tanque y después de un tiempo piense qué sucede).
4. La apertura de la llave de salida representa su demanda de canal. Entre más abre la llave, más agua intenta obtener. Entre
más archivos trate de traer desde Internet, más canal consume.
Ya con esto usted está en total capacidad de usar Delay Pools clase 1. En Squid 2.x existen tres clases de Delay Pool.
Clase 1:
El Delay Pool clase 1 define una única estructura de control (en nuestra abstracción un único tanque). Este limita el uso del canal de
manera global sin importar cómo lo usan los clientes internamente o cómo esta definida lógicamente la LAN. En el inglés técnico se
habla de la definición de un único aggregate bucket. Esta es la opción indicada si usted desea limitar el ancho de banda que usa Squid,
sin importar cómo lo emplean los usuarios.
Clase 2:
Este es un Delay clase 1 con 256 Delay Pools clase 1 subordinados a éste. En inglés técnico se trata de 1 aggregate bucket y 256
individual buckets. En nuestra abstracción un tanque principal y 256 tanques secundarios alimentados por el tanque principal. Con este
Delay Pool es posible controlar el canal que usan 256 clientes.
¿Cómo se asigna el canal a cada cliente? Squid asume que su LAN es una LAN clase C y usa los últimos 8 bits del número IP del
cliente para identificarlo y manejarlo en su individual bucket correspondiente. En la práctica sólo se pueden controlar 253 clientes
descontando la dirección de red, la dirección de broadcast y la dirección del proxy. Note que aquí se empiezan a enredar las cosas: es
muy diferente hablar de un cliente, un host y un usuario. Squid puede tener 230 clientes en una red de 600 hosts (equipos) y unos 700
usuarios. Jamás confunda estos conceptos aunque pueden ser equivalentes dependiendo de la situación.
Clase 3:
Este es un Delay Pool clase 1 con 256 Delay Pools clase 2 subordinados a éste. En ingles técnico se trata de 1 aggregate bucket, 256
network buckets, y 65,536 individual buckets. Está orientado para manejar la asignación de ancho de banda en redes clase B. Los bits
17 a 24 del número IP identifican la red y los bits 17 a 32 el cliente.
delay_pools
Define la cantidad de Delay Pools a usar.
delay_pools 3
delay_class
Permite especificar la clase de Delay Pool. El ID es el orden de la Delay Pool y la clase puede ser 1, 2 ó 3.
Ejemplo:
delay_class 1 3
delay_class 2 1
delay_class 3 2
Del ejemplo se tiene que el Delay Pool 1 es de clase 3, el Delay Pool 2 de clase 1 y el Delay Pool 3 de clase 2. Los Delay Pools no
tienen nombre, se identifican con un número que empieza en 1 y termina en N°.
delay_parameters
Los parámetros de cada Delay Pool se definen por medio de esta directiva. Los valores de RATE y SIZE son dados en Bytes. Por
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 317
Source Linux
ende no olvide hacer la conversión respectiva de Kbits como le venden el canal a Bytes. SIZE es dos o tres veces el valor de
RATE.
Ejemplos:
Un Delay clase 3 con 600Kb/s (76800B/s) en total para navegación, con un tamaño para ráfagas (burst) globales de 1800Kb
(230400Bytes). Para cada subred se asigna un canal máximo de 334.3Kb/s un tamaño para ráfagas de 781.2Kb (100000Bytes)
con un ancho de banda para cada host de 78.1Kb/s (10000B/s) con la posibilidad de ráfagas de descargas de 546.8Kb
(70000Bytes). Note que los valores para cada subred y host exceden los límites de canal disponible si hay más de 4 clientes
navegando en una subred o dos subredes demandan todo el canal asignado. En este caso se produce una condición de
competencia y el primero que solicita el canal es el que lo obtiene. Es de suponer que esta asignación es para una organización
con usuarios que navegan poco y requieren un buen desempeño al momento de solicitar un archivo. Este es un buen ejemplo de
cómo se puede jugar con los parámetros del Delay Pool teniendo en cuenta las costumbres de navegación de la organización.
delay_parameters 1 76800/230400
Un Delay clase 1. Se usan máximo 600Kb/s de ancho de banda con ráfagas de descarga de 1800Kb. Solo se limita el ancho de
banda que usa en total sin importar cómo se distribuye el canal entre los clientes, lo cual da la posibilidad a condiciones de
competencia por el ancho de banda en todo momento.
Un Delay clase 2. Define que se usarán máximo 2.6Mb/s para navegación con ráfagas de 7.8Mb para una asignación de canal a
máximo 256 clientes de 78.1Kb/s con ráfagas de descarga de 195.3Kb (esto es, pueden descargar 195.3Kb a todo lo que de el
canal si tienen el individual bucket lleno). Este montaje es para una organización cuyos usuarios demandan una gran cantidad de
canal. Aquí el peor caso se presenta cuando hay 34 clientes demandando todo el canal asignado de forma continua.
En los Delay Pools clase 2 y clase 3 es posible deshabilitar los buckets que no se desea utilizar colocando -1/-1 en el bucket
correspondiente.
delay_access
Definen por medio de ACLs cuáles peticiones pasan por el Delay y cuáles no.
Ejemplo:
# /etc/init.d/squid start
Es normal cometer errores y la forma de enterarnos qué hicimos mal es darle una mirada al archivo de log cache.log de Squid como
sigue:
# tail -f /var/log/squid/cache.log
En el ejemplo anterior podríamos apreciar si Squid no pudo iniciarse por un error de sintaxis en su configuración, vez por un problema
de permisos, quizás por falta de espacio en disco o cualquiera que sea la causa del problema.
Desde el momento en que Squid ya inicia su funcionamiento sin problemas es posible también que cometamos errores en el orden y
jerarquía de las ACLs de modo tal que un usuario pueda tener acceso a un recurso al que supuestamente habíamos restringido. La
mejor forma de monitorear esto es ver de manera continua el archivo de log access.log de Squid:
# tail -f /var/log/squid/access.log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 318
Source Linux
Si ya logramos darnos cuenta de nuestro error respecto a la configuración de las ACLs entonces como se espera editaremos el archivo
/etc/squid/squid.conf y luego tendríamos que decirle a Squid que haga efectivo dichos cambios. ¿Reiniciamos Squid? Es una opción pero
no la más eficiente, en su lugar debería ejecutarse el comando squid -k reconfigure. Veamos qué nos ofrece el comando squid:
-k check
Verifica si Squid está en ejecución
-k parse
Realiza un chequeo en la sintaxis de configuración de Squid
-k reconfigure
Hace efectivo los cambios hechos en la configuración de manera inmediata
-k rotate
Realiza una rotación de todos los archivos de log de Squid
-k shutdown
Instruye a Squid a terminar de manera normal luego de unos segundos al cerrar sus conexiones
-k kill
Detiene Squid de manera inmediata y abrupta sin esperar a cerrar conexión alguna de los clientes
-z
Crea la estructura de directorios para la caché de Squid según el valor de cache_dir
Para que Squid pueda iniciarse normalmente es necesario que la estructura de directorios de la caché esté correctamente creada, por
lo tanto será necesario ejecutar squid -z si el directorio especificado en la directiva cache_dir se encuentra vacío.
Es común que la caché de Squid nos resulte problemática cuando por alguna razón deseamos ver la versión actualizada de un sitio
Web y Squid aún nos sigue mostrando una versión antigua del mismo. Como alternativa válida podríamos crear una ACL para decirle a
Squid que no guarde en caché su contenido con la directiva no_cache.
Sin embargo la mejor opción es forzar a Squid a cargar refrescar la caché de una URL específica como sigue a continuación:
# squidclient -r http://www.newdomains.com
Como último recurso al lector le podría interesar borrar toda la caché del proxy en un momento determinado pero en realidad no existe
un comando específico para ello. En cambio se debe proceder como sigue:
# squid -k shutdown && rm -rf /var/cache/squid/* && squid -z && /etc/init.d/squid start
La única observación sobre la secuencia de comandos de arriba es que se asume que el directorio de la caché de Squid es
/var/cache/squid pudiendo ser una ruta distinta en realidad para el caso de cada sistema operativo.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 319
Source Linux
4. Conectarse a Webmin con credenciales de administración vía la siguiente URL: http://hostname:10000
5. Dentro de Webmin acceder a 'Servers -> Squid Proxy Server' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 320
Source Linux
15.3. Reporte de tráfico de usuarios
Introducción
SARG es una herramienta que permite crear reportes sobre la navegación que realizaron los usuarios a través de un proxy Squid. Para
eso esta herramienta necesita leer el archivo de log de Squid /var/log/squid/access.log y de acuerdo a un archivo de configuración
procesará su contenido para generar estadísticas en formato HTML de fácil comprensión los cuales pueden ser publicados en algún
servidor Web.
Por defecto SARG tras ser compilado se instala debajo del directorio /usr/local, ubicando así el binario en /usr/local/bin/sarg y su archivo
de configuración principal en /usr/local/etc/sarg.conf.
En Debian y derivados, SARG ya está incluido en los repositorios oficiales por lo que la instalación del paquete binario de este software
se haría como sigue:
Configuración de SARG
El archivo de configuración es sarg.conf y suele ser ubicado en distintos directorios dependiendo del método de instalación, pudiendo
ser común /usr/local/etc/sarg.conf, /etc/sarg/sarg.conf o /etc/squid/sarg.conf.
Sin importar cual sea su ubicación editaremos este archivo debemos tener en cuenta que su contenido predeterminado por lo general
ya viene listo para usarse sin requerir ninguna modificación. Sin embargo puede ser importante ajustar algunos parámetros como los
siguientes:
Todas las directivas de este archivo de configuración vienen documentadas cada una con sus comentarios, lo que facilita el estudio y
comprensión de todos los parámetros de configuración de SARG.
Una vez que se terminó de editar la configuración se puede invocar ya a SARG y luego analizar los archivos generados en
/var/www/html/squid-reports:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 321
Source Linux
# sarg -zx -c /usr/local/etc/sarg.conf
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 322
Source Linux
Administración de SARG desde Webmin
Webmin es una herramienta de configuración de servicios para plataformas Linux y otros UNIX. A través de esta herramienta podemos
configurar y monitorear el reporteador de tráfico de Squid con SARG siguiendo estos pasos:
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
6. Dentro de Webmin acceder a 'Servers -> Squid Report Generator' y dentro revisar las opciones de configuración de esta
herramienta.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 323
Source Linux
15.4. Laboratorio N° 15
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Implementar una configuración de proxy con Squid que cumpla con los siguientes requisitos:
• Los usuarios mencionados son cuentas de un dominio Active Directory con el cual el servidor Linux debe integrarse.
• La configuración de integración con Active Directory se asume ya lista. Esto implica que la configuración de Winbind,
PAM y otros servicios ya han sido completados completamente y los comandos wbinfo -u y getent passwd retornan
ya la lista completa de usuarios de Linux y del dominio Active Directory.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 324
Source Linux
15.4.1. Solución al laboratorio N° 15
1. Implementar una configuración de proxy con Squid que cumpla con los siguientes requisitos:
• Los usuarios mencionados son cuentas de un dominio Active Directory con el cual el servidor Linux debe integrarse.
• La configuración de integración con Active Directory se asume ya lista. Esto implica que la configuración de Winbind,
PAM y otros servicios ya han sido completados completamente y los comandos wbinfo -u y getent passwd retornan
ya la lista completa de usuarios de Linux y del dominio Active Directory.
+ Iniciando sobre una configuración predeterminada de /etc/squid/squid.conf editaremos este archivo para cumplir cada uno de
los requisitos.
El primero de ellos (requerimiento (a))concerniente al soporte de proxy transparente se hace configurando como sigue la
siguiente directiva:
...
...
+ Según el requerimiento (b), (c) y (d) y las consideraciones de integración con Active Directory, creamos los grupos gerencia
y empleados con sus respectivos miembros:
...
...
auth_param basic program /usr/lib/squid/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param basic children 5
auth_param basic realm Squid Proxy Server
auth_param basic credentialsttl 2 hours
...
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 325
Source Linux
El archivo /etc/squid/webchat.txt al cual se hace referencia en una ACL tendría un contenido como:
.ebuddy.com
.elchat.com
.e-messenger.net
.emessenger.net
.express.instan-t.com
.icq.com
.iloveim.com
.imo.im
.imvu.com
.interlatin.com
.koolim.com
.latinchat.com
.meebo.com
.messengerfx.com
.messenger.yahoo.com
.msn2go.com
.msn2go.com.br
.msn2go.nl
.pager.yahoo.com
.photobucket.com
.pixparty.com
.secretosdelmsn.com
.webmessenger.com
.webmessenger.msn.com
.webmessenger.msn.es
.webmessenger.passport.uni.cc
.imhaha.com
.shttp.msg.yahoo.com
.chatenabled.mail.google.com
.talkgadget.google.com
.pager.yahoo.com
.shttp.msg.yahoo.com
.update.messenger.yahoo.com
El archivo /etc/squid/multimedia-tipos.txt al cual se hace referencia en una ACL tendría un contenido como:
application/vnd.ms.wms-hdr.asfv1
application/vnd.koan
application/x-mms-framed
audio/x-pn-realaudio
audio/mid
audio/mpeg.*
video/flv
video/x-flv
video/x-ms-asf
video/x-ms-asf
video/x-ms-wma
video/x-ms-wmv
video/x-msvideo
video/x-shockwave-flash
El archivo /etc/squid/multimedia-descargas.txt al cual se hace referencia en una ACL tendría un contenido como:
# Muchas de estas extensiones suelen ser utilizadas por sitios Web como Bateriafina,
# Fulltono, entre otros.
\.abc\>
\.asf\>
\.avi\>
\.bat\>
\.m1v\>
\.m3u\>
\.mca\>
\.med\>
\.mid\>
\.midi\>
\.mov\>
\.mp2\>
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 326
Source Linux
\.mp2v\>
\.mp3\>
\.mpa\>
\.mpe\>
\.mpeg\>
\.mpg\>
\.msi\>
\.ogg\>
\.pps\>
\.skm\>
\.snd\>
\.wma\>
\.wvx\>
...
...
# Acceso a Internet excepto Chat y Multimedia para empleados según requerimiento (f)
http_access allow empleados !msn1 !msn2 !msn3 !webchat !multimedia-descargas
...
...
+ Luego de guardar los cambios, verificamos la sintaxis, refrescamos los cambios en el servicio Squid en ejecución y
analizamos los logs para depuración tras las pruebas a realizar por parte de los clientes:
# squid -k parse
# squid -k reconfigure
# tail -f /var/log/squid/access.log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 327
Source Linux
Unidad 16: Túneles VPN
16.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
Autenticación y autorización
¿Quién está del otro lado? Usuario/equipo y qué nivel de acceso debe tener
Integridad
La garantía de que los datos enviados no han sido alterados. Para ello se utiliza un metodo de comparación (Hash).Los
algoritmos comunes de comparacion son Message Digest(MD) y Secure Hash Algorithm (SHA).
Confidencialidad
Dado que los datos viajan a través de un medio potencialmente hostil como Internet, los mismos son susceptibles de
intercepción, por lo que es fundamental el cifrado de los mismos. De este modo, la información no debe poder ser
interpretada por nadie más que los destinatarios de la misma.Se hace uso de algoritmos de cifrado como Data Encryption
Standard (DES),Triple DES(3DES) y Advanced Encryption Standard (AES).
No repudio
Es decir un mensaje tiene que ir firmado, y el que lo firma no puede negar que el mensaje lo envió él.
Requerimientos Básicos
Identificación de Usuario
Las VPN's (Redes Virtuales Privadas) deben verificar la identidad de los usuarios y restringir su acceso a aquellos que no
se encuentren autorizados.
Codificación de Datos
Los datos que se van a transmitir a través de la red pública (Internet), antes deben ser cifrados, para que así no puedan
ser leídos. Esta tarea se realiza con algoritmos de cifrado como DES o 3DES.
Administración de claves
Las VPN's deben actualizar las claves de cifrado para los usuarios.
Tipos de VPN
Básicamente existen tres arquitecturas de conexión VPN:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 328
Source Linux
conservan sus viejos modems. Existen excelentes equipos en el mercado.
Tunneling
Internet se construyó desde un principio como un medio inseguro. Muchos de los protocolos utilizados hoy en día para transferir
datos de una máquina a otra a través de la red carecen de algún tipo de cifrado o medio de seguridad que evite que nuestras
comunicaciones puedan ser interceptadas y espiadas. HTTP, FTP, POP3 y otros muchos protocolos ampliamente usados, utilizan
comunicaciones que viajan en claro a través de la red. Esto supone un grave problema, en todas aquellas situaciones en las que
queremos transferir entre máquinas información sensible, como pueda ser una cuenta de usuario (nombre de usuario y
contraseña), y no tengamos un control absoluto sobre la red, a fin de evitar que alguien pueda interceptar nuestra comunicación
por medio de la técnica del hombre en el medio (man in the middle), como es el caso de la Red de redes.
¿Qué es el tunneling?
El problema de los protocolos que envían sus datos en claro, es decir, sin cifrarlos, es que cualquier persona que tenga acceso
físico a la red en la que se sitúan nuestras máquinas puede ver dichos datos. Es tan simple como utilizar un sniffer, que
básicamente, es una herramienta que pone nuestra tarjeta de red en modo promiscuo (modo en el que las tarjetas de red operan
aceptando todos los paquetes que circulan por la red a la que se conectan, sean o no para esa tarjeta). De este modo, alguien que
conecte su máquina a una red y arranque un sniffer recibirá y podrá analizar por tanto todos los paquetes que circulen por dicha
red. Si alguno de esos paquetes pertenece a un protocolo que envía sus comunicaciones en claro, y contiene información sensible,
dicha información se verá comprometida. Si por el contrario, ciframos nuestras comunicaciones con un sistema que permita
entenderse sólo a las dos máquinas que queremos sean partícipes de la comunicación, cualquiera que intercepte desde una
tercera máquina nuestros paquetes, no podrá hacer nada con ellos, al no poder descifrar los datos. Una forma de evitar el
problema que nos atañe, sin dejar por ello de utilizar todos aquellos protocolos que carezcan de medios de cifrado, es usar una útil
técnica llamada tunneling. Básicamente, esta técnica consiste en abrir conexiones entre dos máquinas por medio de un protocolo
seguro, como puede ser SSH (Secure SHell), a través de las cuales realizaremos las transferencias inseguras, que pasarán de
este modo a ser seguras. De esta analogía viene el nombre de la técnica, siendo la conexión segura (en este caso de ssh) el túnel
por el cual enviamos nuestros datos para que nadie más aparte de los interlocutores que se sitúan a cada extremo del túnel, pueda
ver dichos datos. Ni que decir tiene, que este tipo de técnica requiere de forma imprescindible que tengamos una cuenta de acceso
seguro en la máquina con la que nos queremos comunicar.
Coste
La principal motivación del uso y difusión de esta tecnología es la reducción de los costos de comunicaciones directos, tanto en
líneas dial-up como en vínculos WAN dedicados. Los costos se reducen drásticamente en estos casos:
• En el caso de accesos remotos, llamadas locales a los ISP (Internet Service Provider) en vez de llamadas de larga
distancia a los servidores de acceso remoto de la organización. O también mediante servicios de banda ancha.
• En el caso de conexiones punto a punto, utilizando servicios de banda ancha para acceder a Internet, y desde Internet
llegar al servidor VPN de la organización. Todo esto a un costo sensiblemente inferior al de los vínculos WAN dedicados.
Ancho de banda
Podemos encontrar otra motivación en el deseo de mejorar el ancho de banda utilizado en conexiones dial-up. Las conexiones
VPN de banda ancha mejoran notablemente la capacidad del vínculo, pero los costos son más altos.
Implementaciones
Todas las opciones disponibles en la actualidad caen en tres categorías básicas: soluciones de hardware, soluciones basadas en
cortafuegos y aplicaciones VPN por software.
El protocolo estándar de hecho es el IPSEC, pero también tenemos PPTP, L2F, L2TP, SSL/TLS, SSH, etc. Cada uno con sus ventajas y
desventajas en cuanto a seguridad, facilidad, mantenimiento y tipos de clientes soportados.
Actualmente hay una línea de productos en crecimiento relacionada con el protocolo SSL/TLS, que intenta hacer más amigable la
configuración y operación de estas soluciones.
• Las soluciones de hardware casi siempre ofrecen mayor rendimiento y facilidad de configuración, aunque no tienen la
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 329
Source Linux
flexibilidad de las versiones por software. Dentro de esta familia tenemos a los productos de Nortel, Cisco, Linksys,
Netscreen, Symantec, Nokia, US Robotics, D-link etc.
• En el caso basado en cortafuegos, se obtiene un nivel de seguridad alto por la protección que brinda el cortafuegos, pero se
pierde en rendimiento. Muchas veces se ofrece hardware adicional para procesar la carga VPN. Por ejemplo: Checkpoint
NG, Cisco Pix.
• Las aplicaciones VPN por software son las más configurables y son ideales cuando surgen problemas de interoperatividad en
los modelos anteriores. Obviamente el rendimiento es menor y la configuración más delicada, porque se suma el sistema
operativo y la seguridad del equipo en general. Aquí tenemos por ejemplo a las soluciones nativas de Windows, Linux y los
Unix en general. Por ejemplo productos de código abierto (Open Source) como OpenSSH, OpenVPN y FreeS/Wan.
Ventajas
Tipos de Conexión
Instalación de OpenVPN
OpenVPN puede por lo general puede ser instalado desde los repositorios de software que provee la distribución Linux usada.
En Red Hat / CentOS y derivados, se requiere que se tenga configurado el repositorio DAG (http://dag.wieers.com) y proceder como
sigue:
En Debian y derivados, OpenVPN ya está incluido en los repositorios oficiales por lo que la instalación debe ser directa como sigue:
Modo de funcionamiento
OpenVPN posee dos modos de funcionamiento: Enrutado y Puente, a los cuales los conoceremos como modo Routing y modo
Ethernet Bridging.
Puede entenderse un poco las diferencias entre ambos modos de funcionamiento con la siguiente comparativa:
• El tráfico broadcast a través de la VPN: esto permite el correcto funcionamiento de software que depende del tráfico
broadcast en redes LAN tal como la navegación a través de redes Microsoft conocido comúnmente como network
browsing.
• No es necesario configurar reglas de enrutamiento.
• Funciona con cualquier protocolo sobre Ethernet incluyendo IPv4, IPv6, Netware IPX, AppleTalk, etc.
• La configuración de road warriors es relativamente más sencilla.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 330
Source Linux
Ventajas del modo Routing:
• Eficiencia y escalabilidad.
• Permite mejor afinamiento del MTU para mejorar la eficiencia.
• Los clientes deben usar un servidor WINS para pemitir la resolución de nombres NetBIOS entre ordenadores que estén a
ambos extremos de los túneles VPN.
• Deben configurarse reglas de enrutamiento en cada subred.
• Software que dependa del tráfico broadcast no será capaz de encontrar a los hosts al otro lado de los túneles VPN.
• Funciona solamente con IPv4 en general, e IPv6 en casos donde los drivers TUN en ambos extremos de los túneles
soporten dicho protocolo de manera explícita.
Este documento cubre sólo la configuración de OpenVPN en modo Routing, el cual es uno de los modos más comunes para
configurar VPNs.
Numeración de redes
La IANA ha reservado los siguientes tres bloques de direcciones IP para ser usadas en redes privadas:
Mientras que las direcciones de estos bloques deberían normalmente ser usadas en las configuraciones de VPNs es importante
seleccionar direcciones que minimicen las posibilidades de conflictos con los rangos usados en las redes privadas. Los conflictos
que deben ser evitados son:
• Conflictos de diferentes sitios en la VPN usando la misma numeración de red que la LAN.
• Conexiones de acceso remoto desde sitios que usen la misma numeración de red que las subredes usadas por la VPN.
Por ejemplo suponga que Ud. usa la red 192.168.1.0/24 para su red LAN. Luego imagine que intenta conectarse a través de VPN
desde un cybercafé que está usando las mismas direcciones de 192.168.1.0/24 para su red Wi-Fi. Con esta situación se presentará
un conflicto porque un ordenador de su red privada no sabrá si 192.168.1.1 es el gateway de la red Wi-Fi del cybercafé o se trata
acaso de la IP asignada al servidor VPN.
La mejor solución para evitar estos conflictos es procurar no numerar sus redes con direcciones contenidas en el rango 10.0.0.0/24
ó 192.168.1.0/24.
Configuración de OpenVPN
✔ Un certificado (conocido también como llave pública) y llave privada separado para cada cliente y el servidor.
✔ Un Certificado Autoridad maestro (CA, Certificate Authority) y su respectiva llave privada usada para firmar cada certificado
usado por los clientes y el servidor.
OpenVPN soporta autenticación bidireccional basada en certificados; es decir el cliente debe autenticarse al certificado del servidor y el
servidor debe autenticare al certificado del cliente, antes que una confianza mutua pueda ser establecida.
Tanto el servidor como el cliente se autenticarán el uno al otro primero verificando que el certificado presentado ha sido firmado por el
CA, y luego evaluando información en las cabeceras del certificado tal como el Common Name o el tipo del certificado (cliente o
servidor).
Este modelo de seguridad tiene un número de funcionalidades deseables desde la perspectiva VPN:
• El servidor solamente necesita su propio par certificado/llave. No necesita conocer los certificados individuales de cada
cliente que se va a conectar a él.
• El servidor solamente aceptará clientes cuyos certificados han sido firmados por el Certificado Autoridad maestro, CA (el cual
ahora generaremos). Y debido a que el servidor no necesita acceder a la llave privada del CA para verificar los certificados de
clientes es posible entonces que dicha llave privada pueda residir en otra máquina por razones de seguridad incluso sin
conexión a red.
• Si una llave privada es comprometida, puede ser deshabilitada simplemente agregando su certificado correspondiente a una
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 331
Source Linux
lista de revocación de certificados, CRL (Certificate Revocation List). El CRL permite que los ciertos certificados
comprometidos previamente seleccionados sean simplemente rechazados ante cualquier intento de conexión.
Una vez dentro del directorio easy-rsa encontraremos un archivo de nombre vars el cual debemos editar y modificar algunos
valores como los que se aprecian a continuación:
export KEY_SIZE=1024
export KEY_COUNTRY=PE
export KEY_PROVINCE=LI
export KEY_CITY=Lima
export KEY_ORG="Consultorianet"
export KEY_EMAIL="soporte@consultorianet.com"
Si se observa con cuidado el contenido del archivo se puede comprender que se definen variables las cuales deben ser cargadas
para ser usadas posteriormente en la construcción del certificado pudiendo tener valores a gusto y criterio del administrador pero
recordando que ninguno de ellos debe ser dejado en blanco.
Entonces se procede a cargar las variables del archivo recién editado:
# source vars
Ahora se procederá a ejecutar el script clean-all dentro del mismo directorio. Este script se encargará de eliminar el directorio
$KEY_DIR si éste ya existiese y sino lo eliminará con todo su contenido actual para crearlo nuevamente.
Así que ejecutamos:
# ./clean-all
Si todo hasta ahora se ha ejecutado correctamente deberíamos poder constatar la existencia de un directorio con el nombre de la
variable KEY_DIR (Probar: echo $KEY_DIR).
Ahora es cuando ya se procederá a crear el CA ejecutando el script build-ca y nos hará algunas preguntas de las cuales algunas ya
tendrán los valores precargados del archivo de configuración vars previamente editado y pueden aceptarse como respuesta
presionando Enter, y otras opciones aún por rellenar con los valores apropiados como sigue:
# ./build-ca
Generating a 1024 bit RSA private key
.......++++++
..++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PE]:[Enter]
State or Province Name (full name) [LI]:[Enter]
Locality Name (eg, city) [Lima]:[Enter]
Organization Name (eg, company) [Consultorianet]:[Enter]
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server's hostname) []:www.consultorianet.com
Email Address [soporte@consultorianet.com]:[Enter]
Luego de esto puede verificarse dentro del directorio $KEY_DIR la existencia de los archivos ca.crt (el CA) y ca.key (la llave privada
del CA). Hasta este punto ya se ha creado correctamente el CA con su respectiva llave privada la misma que debe ser mantenida
en la más absoluta privacidad por razones de seguridad obvias.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 332
Source Linux
un canal inseguro, y de manera anónima (no autenticada).
Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión. Siendo
no autenticado, sin embargo provee las bases para varios protocolos autenticados.
Por lo tanto es necesario generar un archivo que contenga los parámetros correspondientes del protocolo desde el mismo
directorio de trabajo usado anteriormente para la generación de la CA.
Para ello debe ejecutarse el script build-dh como sigue:
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.....+........................................+.........................
+...................................................+........................+.....
+................................................................................................
............................................+...................
+..........................................................................................
+........+.....
+................................................................................................
.........+..................................................+...+.......
+..................................................................+......
+..........................
+................................................................................................
.......................+..........
+................................................................................................
....+...+.............................................................................
+.....................................................................................+.....
+..........................................+....................++*++*++*
Si todo ha funcionado correctamente debería haberse creado el archivo dh1024.pem (u otro número distinto de 1024 dependiendo
del valor de KEY_SIZE en el archivo vars).
# ./build-key-server vpn-server
Generating a 1024 bit RSA private key
....................................++++++
.++++++
writing new private key to 'vpn-server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PE]:[Enter]
State or Province Name (full name) [LI]:[Enter]
Locality Name (eg, city) [Lima]:[Enter]
Organization Name (eg, company) [Soporte Linux]:[Enter]
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server's hostname) []:vpn-server
Email Address [soporte@consultorianet.com]:[Enter]
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 333
Source Linux
Sign the certificate? [y/n]:y
Es indispensable que el valor del Common Name en la creación del certificado sea el mismo que el pasado como parámetro al
script.
Si todo ha funcionado como debe ser se habrán creado un par de archivos de extensión .crt y .key dentro del directorio $KEY_DIR
con el nombre especificado como parámetro al script, resultando en nuestro ejemplo vpn-server.crt y vpn-server.key
Observaciones:
Hasta este punto ya se ha creado el CA, el certificado del servidor y el archivo de parámetros Diffie Hellman pero debe
considerarse que este proceso debe ser ejecutado solamente una única vez, por ello hay que ser cuidadosos de no
ejecutar nuevamente el script clean-all si antes no se ha hecho un respaldo del contenido del directorio $KEY_DIR.
Si se desean generar certificados para los clientes en un futuro hay que considerar que deben cargarse las variables de
entorno desde el archivo vars usando el comando source.
# ./build-req-pass cliente0
Generating a 1024 bit RSA private key
..........++++++
..................................................................++++++
writing new private key to 'cliente0.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PE]:[Enter]
State or Province Name (full name) [LI]:[Enter]
Locality Name (eg, city) [Lima]:[Enter]
Organization Name (eg, company) [Soporte Linux]:[Enter]
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server's hostname) []:cliente0
Email Address [soporte@consultorianet.com]:[Enter]
Recordar que también el valor del Common Name debe ser el mismo que se pasó como parámetro al script. Si todo ha funcionado
como se espera entonces se debe haber creado un archivo de extensión .key y otro de extensión .csr dentro del directorio
$KEY_DIR con el nombre especificado para el cliente, mas no ninguno de extensión .crt todavía.
Es ahora cuando ya se puede proceder a firmar la solicitud de certificado del cliente ejecutando el script sign-req pasándole como
parámetro el nombre anteriormente dado al cliente. Veamos como sería según nuestra solicitud de cliente antes creada:
# ./sign-req cliente0
Using configuration from /root/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'PE'
stateOrProvinceName :PRINTABLE:'LI'
localityName :PRINTABLE:'Lima'
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 334
Source Linux
organizationName :PRINTABLE:'Soporte Linux'
organizationalUnitName:PRINTABLE:'sistemas'
commonName :PRINTABLE:'cliente0'
emailAddress :IA5STRING:'soporte@consultorianet.com'
Certificate is to be certified until Aug 18 22:35:26 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
Con esto ya deberíamos ahora sí tener un archivo de extensión .crt con el nombre del cliente dentro del directorio $KEY_DIR.
Es así que se concluye el proceso de creación de certificados y llaves para los clientes y/o el servidor. A continuación se procederá a
entrar ya en detalle de la sintaxis y directivas de los archivos de configuración de OpenVPN.
Observaciones:
OpenVPN no tiene una configuración centralizada en un único archivo como sí sucede con Squid por ejemplo. En cambio
OpenVPN mantiene uno o más archivos de configuración independientes para cada instancia del servicio que puede
comportarse como cliente o como servidor dependiendo directamente de la naturaleza de sus directivas de configuración
dentro del archivo.
La manera de lanzar una instancia de OpenVPN con un archivo de configuración específico es como sigue:
Donde ARCHIVO es la ruta absoluta a un archivo de texto plano que contiene las directivas de configuración.
Si bien es esta una manera correcta de hacer las cosas no es la más cómoda debido a que ahora ya todas las distribuciones
Linux cuentan con un script de administración del servicio OpenVPN dentro del directorio /etc/init.d el cual por defecto tratará
de levantar tantas instancias del servicio como archivos de extensión .conf encuentre dentro de /etc/openvpn.
Las directivas de configuración de OpenVPN tienen una sintaxis sencilla como se muestra a continuación:
directiva VALOR
Como en muchos otros ficheros de configuración las líneas que contengan el símbolo # serán tratadas como comentarios e
ignoradas por OpenVPN como directivas de configuración así como también las líneas en blanco.
dev
Directiva que especifica el tipo y/o nombre del dispositivo usado para establecer las conexiones entre los túneles VPN. OpenVPN
en modo Routing usa los dispositivos TUN mientras que en modo Bridging usa los dispositivos TAP.
Puede indicarse simplemente un valor como tun o adicionarle un número al final para definir de manera explícita el orden del
dispositivo que usará dicha instancia de configuración.
Dos instancias de OpenVPN no pueden tener el mismo nombre de dispositivo (como por ejemplo ambas usando tun1), sino cada
una un dispositivo diferente tal como tun1 y tun2.
Si a cada instancia se le configura simplemente tun como nombre de dispositivo entonces OpenVPN asignará automáticamente
un número libre según los que se encuentren disponibles en el momento de la inicialización de cada instancia a fin de evitar
conflictos.
Ejemplo:
dev tun
port
Puerto de escucha del servicio OpenVPN. Por defecto es 1194 en la versión 2.0 del software pero puede tener cualquier otro valor
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 335
Source Linux
distinto.
Ejemplo:
port 1194
proto
Naturaleza del protocolo a usar para las conexiones. Por defecto es UDP si no se especifica lo contrario. Sin embargo OpenVPN
fue diseñado para trabajar óptimamente sobre UDP pero el soporte para TCP existe para aquellas situaciones en las que por
razones diversas UDP no sea posible usarlo.
En modo TCP el servicio es menos eficiente y requerirá que la directiva contenga tcp-server o tcp-client como valor
dependiendo si se trata de una configuración para servidor o cliente respectivamente.
Ejemplo:
proto udp
user/group
Usuario y grupo bajo el cual correrá el servicio OpenVPN. Por defecto se inician con los privilegios de root para tener acceso de
lectura a ciertos archivos protegidos y también tener acceso de escritura a directorios del sistema; sin embargo una vez
completadas las labores que requieren estos privilegios durante la inicialización entonces automáticamente se degradarán hasta un
usuario/grupo corriente del sistema especificado en esta directiva.
Ejemplo:
user nobody
group nogroup
comp-lzo
Habilita la compresión del tráfico que pasa por el túnel.
Sintaxis: comp-lzo
verb
Nivel de registro en los logs. Puede tomar los siguientes valores:
Ejemplo:
verb 3
log/log-append
Ruta al archivo de registro del funcionamiento de OpenVPN. Ambas opciones son excluyentes pues mientras que la primera
directiva reescribirá un archivo de log ya existente en cada inicio del servicio OpenVPN, la segunda directiva escribirá al final de un
archivo de log ya existente. Si el archivo de log no existe en ambos casos lo creará antes de escribir en él.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 336
Source Linux
Ejemplos excluyentes:
log /var/log/openvpn/vpn-server.log
log-append /var/log/openvpn/vpn-server.log
ping
Los firewalls basados en estado pueden bloquear las conexiones VPN si no detectan tráfico durante un lapso de tiempo. Por eso
esta directiva en momentos de inactividad mantendrá un refresco de la conexión cada cierta cantidad de segundos según se
especifique en su valor.
Ejemplo:
ping 15
ping-restart
Enviar la señal SIGUSR1 para reiniciar el servicio si no se ha recibido respuesta luego de una cantidad de segundos desde el
último ping. En modo servidor no se reinicia todo el servicio entero de OpenVPN sino solamente la instancia específica del cliente
con el cual se perdió la conexión.
Ejemplo:
ping-restart 60
persist-tun
Esta directiva evita cerrar y volver a abrir los dispositivos TUN/TAP, o volver a ejecutar los scripts de las directivas up/down al
recibir la señal SIGUSR1 o luego de un reinicio de la directiva ping-restart.
Sintaxis: persist-tun
persist-key
Esta directiva evita volver a leer los archivos de llaves luego de recibir una señal SIGUSR1 o luego de un reinicio de la directiva
ping-restart. Opción útil si se cambian los privilegios del servicio con la directiva user/group y dicho usuario/grupo no tiene
los permisos suficientes de leer el archivo de llaves que en un principio fue leído con privilegios de root. El servicio no puede ser
reiniciado con SIGUSR1 y a la vez retomar privilegios de root.
Sintaxis: persist-key
cipher
Algoritmo usado para la encriptación de tráfico. El comando openvpn --show-ciphers muestra un listado de los algoritmos
disponibles.
cipher BF-CFC
ping-timer-rem
La verificación de conexiones activas de las dos directivas anteriores no tendría sentido si el servicio se inicia en modo servidor y
no existe ningún cliente iniciando conexiones. Para no gastar esfuerzos en reconexiones persistentes con clientes que aún no
existen es que debe incluirse esta directiva.
Sintaxis: ping-timer-rem
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 337
Source Linux
* Directiva no válida para conexiones en modo cliente.
tls-server
Asigna el papel de servidor a la instancia OpenVPN para las sesiones SSL/TLS.
Sintaxis: tls-server
dh
Define la ruta al archivo que contiene los parámetros Diffie Hellman.
Sintaxis: dh ruta_archivo
Ejemplo:
dh /etc/openvpn/keys/dh1024.pem
ca
Define la ruta del certificado maestro CA.
Sintaxis: ca ruta_archivo
Ejemplo:
ca /etc/openvpn/keys/ca.crt
cert
Define la ruta del certificado usado por el servidor.
Ejemplo:
cert /etc/openvpn/keys/vpn-server.crt
key
Define la ruta de la llave privada correspondiente al certificado usado por el servidor.
Ejemplo:
key /etc/openvpn/keys/vpn-server.key
server
Configura el servicio OpenVPN en modo servidor y configura una subred para brindar direcciones IP virtuales a los extremos de los
túneles clientes. El servidor tomará por defecto la primera dirección disponible en el rango definido en la directiva y los clientes
tomarán el resto de direcciones restantes.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 338
Source Linux
push
Envía algunas opciones de configuración de OpenVPN al cliente que se conecte de modo que éste modifique la forma de
funcionamiento respecto a parámetros de red. Una opción bastante común a usar es --route que permite decirle a los clientes
qué ruta agregar a su tabla de enrutamiento para poder llegar a la LAN detrás del servidor VPN. Otras opciones posibles que se
pueden usar en esta directiva esta documentadas en openvpn(8).
En el ejemplo se tiene que la red 192.168.3.0/24 es la que está detrás del servidor OpenVPN y se le indica al cliente que agregue
la ruta correspondiente a su tabla de enrutamiento:
ifconfig-pool-persist
Ruta a un archivo en el cual se mantendrá un pool de las direcciones IP virtuales asociadas a cada cliente para restaurarles las
mismas direcciones a los clientes en caso de que OpenVPN sea reiniciado.
Ejemplo:
ifconfig-pool-persist /etc/openvpn/ipp.txt
plugin
Ruta a un archivo en al cual OpenVPN invocará cada vez que un usuario remoto intente autenticarse con un usuario y password
para así autorizar la conexión dependiendo del éxito de la validación de credenciales.
Ejemplo:
plugin /usr/lib/openvpn/openvpn-auth-pam.so
Ahora pasamos a resumir nuestra configuración en un archivo modelo como el siguiente al cual se le han removido los
comentarios:
# /etc/openvpn/vpn-server.conf
dev tun
port 1194
proto udp
server 10.255.255.0 255.255.255.0
push "route 192.168.3.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpn-server.crt
key /etc/openvpn/keys/vpn-server.key
cipher BF-CBC
tls-server
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
ping-timer-rem
persist-tun
persist-key
verb 3
log-append /var/log/openvpn/vpn-server.log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 339
Source Linux
Configuración en modo cliente
OpenVPN en modo cliente requiere la definición de algunas directivas que ya han sido estudiadas en una configuración en modo
servidor, restándole algunas y agregándole otras tantas.
Por lo tanto se procede a continuación a detallar las directivas antes no estudiadas y al final se presentará a modo de resumen una
configuración modelo de OpenVPN cliente donde podrá apreciarse qué directivas ya no están presentes respecto a la configuración
anterior.
remote
Esta directiva permite especificar el servidor y puerto al que OpenVPN se conectará. Si no se especifica el puerto se asumirá el
1194.
Ejemplo:
pull
Esta directiva le dice a la instancia OpenVPN cliente que debe solicitar la entrega de parámetros de configuración por parte del
servidor en el otro extremo del túnel. De no usar esta directiva entonces no podrán agregarse automáticamente las rutas en el
sistema que permitirán encaminar paquetes hacia la red LAN detrás del servidor OpenVPN al cual se acaba de conectar.
Sintaxis: pull
tls-client
Asigna el papel de cliente a la instancia OpenVPN para las sesiones SSL/TLS.
Sintaxis: tls-client
cert/key
Estas directivas fueron ya estudiadas anteriormente pero se les menciona nuevamente para recalcar que ahora deben apuntar al
certificado del cliente firmado anteriormente por el CA y su llave privada respectiva.
Ejemplo:
cert /etc/openvpn/keys/cliente0.crt
key /etc/openvpn/keys/cliente0.key
auth-user-pass
Estas directiva instruye a OpenVPN a solicitar credenciales de autenticación al usuario que se conecta para validar así la conexión
con el servidor.
Sintaxis: auth-user-pass
Ejemplo:
auth-user-pass
Ahora pasamos a resumir nuestra configuración en un archivo modelo como el siguiente al cual se le han removido los
comentarios:
# /etc/openvpn/cliente0.conf
dev tun
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 340
Source Linux
port 1194
proto udp
remote 190.41.41.92 1194
pull
tls-client
cert /etc/openvpn/keys/cliente0.crt
key /etc/openvpn/keys/cliente0.key
cipher BF-CBC
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
persist-tun
persist-key
verb 3
log-append /var/log/openvpn/cliente0.log
Asumiendo que el cliente que se ha de conectar se conectará desde una plataforma Windows, el archivo de configuración debería
ser creado dentro del directorio C:\Archivos de programa\OpenVPN\config con una extensión .ovpn con un contenido muy similar como
el siguiente:
dev tun
port 1194
proto udp
remote 190.41.41.92 1194
pull
tls-client
cert cliente0.crt
key cliente0.key
cipher BF-CBC
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
persist-tun
persist-key
verb 3
Observación:
• En una configuración de OpenVPN sobre plataforma Windows, la directiva log-append o log no deben ser utilizadas ya que
ésta son válidas solamente para plataformas Linux.
• Las directivas cert y key no especifican rutas absolutas de los archivos cliente0.crt y/o cliente0.key por lo que por defecto
OpenVPN asumirá que están ubicados en el mismo directorio que el archivo de configuración, es decir dentro de C:\Archivos
de programa\OpenVPN\config.
• Es recomendable que el archivo de configuración de OpenVPN para Windows sea creado dentro de esta misma plataforma
usando algún programa como notepad.exe o si se crea desde Linux se tenga en cuenta realizar la conversión de los saltos
de línea usando el comando unix2dos. Esto es debido a que el salto de línea usado en UNIX/Linux es el caracter LF y en
DOS/Windows es CR+LF.
Hasta aquí se cubre algunas de las directivas básicas más comunes para conseguir una correcta configuración de OpenVPN como
cliente y servidor usando certificados digitales. Sin embargo muchas otras opciones que pueden ser de interés para el lector pueden
ser encontradas en openvpn(8).
Se da por entendido que cada archivo de configuración debe ser instalado en diferentes ordenadores de modo tal que se lleve a la
práctica la relación cliente/servidor entre puntos remotos.
Arranque de OpenVPN
Una vez concluida la elaboración correcta de los archivos de configuración de OpenVPN debe iniciarse éste a través del script
correspondiente que se encuentre en /etc/init.d.
Dependiendo de la distribución Linux con la que se trabaje las siguientes podrían ser alternativas válidas para arrancar, detener y
reiniciar el servicio OpenVPN:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 341
Source Linux
En Red Hat / CentOS y derivados:
En Debian y derivados:
# tail -f /var/log/openvpn/vpn-server.log
# tail -f /var/log/openvpn/cliente0.log
¿Aún desea comprobar que todo camina correctamente? Entonces déle una mirada a sus interfaces de red: si todo funciona como
debe ser entonces debe haberse creado una interfaz de red adicional con el nombre tun0, tun1, tun2 o cualquier otra similar que
antes no existía en su sistema:
Fíjese como ya se ha creado tun0 el cual posee la primera dirección IP virtual dentro del rango definido en nuestros ejemplos
(10.255.255.0/24) lo cual nos lleva a pensar que se trata de un listado de las interfaces de red de un host corriendo OpenVPN en modo
servidor.
¿Las cosas todavía van mal? Puede ser que algo no anda aún bien en la conexión, tal vez la sesión SSL/TLS no se ha establecido
correctamente y se aprecian errores en los logs que nunca tienen fin.
Desde la perspectiva de un host corriendo OpenVPN en modo cliente la forma más directa de comprobar que la conexión con el otro
extremo del túnel (el servidor) se ha establecido sin problemas es probando la conectividad con lP virtual del servidor, la cual siempre
es conocida.
Así se tiene que para nuestros ejemplos debemos comprobar la conectividad con 10.255.255.1 (la primera dirección IP del rango
configurando en la directiva server) con la herramienta ping:
# ping 10.255.255.1
PING 10.255.255.1 (10.255.255.1) 56(84) bytes of data.
64 bytes from 10.255.255.1: icmp_seq=1 ttl=128 time=0.719 ms
64 bytes from 10.255.255.1: icmp_seq=2 ttl=128 time=0.721 ms
64 bytes from 10.255.255.1: icmp_seq=3 ttl=128 time=0.726 ms
Si no se tiene respuesta entonces definitivamente algo no está bien. Hay consejos importantes a tener en cuenta que pueden ayudar a
llegar más rápido a la solución del problema y estos son:
✔ Asegurarse que el cliente está usando la configuración correcta del servidor y puerto al cual se intenta conectar.
✔ Si el servidor OpenVPN está corriendo como un host más en una LAN detrás de un firewall entonces es necesario
asegurarse que dicho firewall está haciendo la operación de NAT correcta que le permita reenviar las conexiones UDP al
puerto respectivo del servidor OpenVPN.
✔ Asegurarse también que no existan reglas de firewall que impidan el ingreso de conexiones UDP al puerto de escucha del
servidor OpenVPN.
✔ Tener cuidado con la hora y fecha de los sistemas operativos de modo tal que estén correctamente asignados. Si se generan
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 342
Source Linux
los certificados en un host que tiene una hora y fecha atrasada entonces al querer hacer uso de ellos en un servidor o cliente
que sí posean la hora correcta sucederá que la negociación SSL/TLS fallará debido a la desincronización de fecha y hora,
donde se pretenderá validar un certificado en una fecha futura ficticia.
✔ Si las conexiones las aprecia muy lentas o simplemente nunca llegan a establecerse pruebe cambiando los algoritmos de
cifrado en la directiva cipher. Por lo general BF-CBC no suele dar ningún problema en la mayoría de casos.
En Debian y derivados:
# dpkg -i webmin_VERSION_all.deb
# apt-get install -f
En Debian y derivados:
6. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de OpenVPN
dando clic en el botón 'From uploaded file' y eligiendo al ruta donde se guardó el módulo de Webmin descargado
previamente.
8. Una vez instalado el módulo acceder a 'Servers -> OpenVPN + CA' y revisar las opciones de configuración del módulo de
OpenVPN a través de su interfaz gráfica amigable.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 343
Source Linux
16.3. Laboratorio N° 16
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Implementar un servidor VPN con OpenVPN en la cual se pida a los usuarios autenticarse con un usuario y password, los
mismos que deben ser validados desde un controlador de dominios Active Directory.
Crear la configuración de servidor y cliente necesaria para llevar a cabo esta configuración de manera exitosa.
• Los usuarios mencionados son cuentas de un dominio Active Directory con el cual el servidor Linux debe integrarse.
• La configuración de integración con Active Directory se asume ya lista. Esto implica que la configuración de Winbind,
PAM y otros servicios ya han sido completados completamente y los comandos wbinfo -u y getent passwd retornan
ya la lista completa de usuarios de Linux y del dominio Active Directory.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 344
Source Linux
16.3.1. Solución del laboratorio N° 16
1. Implementar un servidor VPN con OpenVPN en la cual se pida a los usuarios autenticarse con un usuario y password, los
mismos que deben ser validados desde un controlador de dominios Active Directory.
Crear la configuración de servidor y cliente necesaria para llevar a cabo esta configuración de manera exitosa.
• Los usuarios mencionados son cuentas de un dominio Active Directory con el cual el servidor Linux debe integrarse.
• La configuración de integración con Active Directory se asume ya lista. Esto implica que la configuración de Winbind,
PAM y otros servicios ya han sido completados completamente y los comandos wbinfo -u y getent passwd retornan
ya la lista completa de usuarios de Linux y del dominio Active Directory.
Configuración de servidor:
+ En un equipo corriendo un sistema operativo Linux, crear un archivo de configuración /etc/openvpn/server.conf con un
contenido como el siguiente:
dev tun0
port 1194
proto udp
server 10.30.25.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpnserver.crt
key /etc/openvpn/keys/vpnserver.key
cipher BF-CBC
tls-server
user nobody
group nogroup
comp-lzo
keepalive 15 60
ping-timer-rem
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
status /etc/openvpn/openvpn-status.log
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn
+ Ubicamos el directorio easy-rsa (Ejm: /usr/share/doc/openvpn/easy-rsa) y copiamos su contenido al directorio /etc/openvpn para
desde ahí empezar a crear la CA, certificados de servidor y cliente:
# cd /usr/share/doc/openvpn
# cp -r easy-rsa /etc/openvpn
+ Creamos la CA:
# cd /etc/openvpn/easy-rsa
# chmod +x build-* clean-all sign-req
# source vars
# ./clean-all
# ./build-ca
# ./build-dh
# ./build-req vpnserver
# ./build-req clientevpn1
# ./sign-req vpnserver
# ./sign-req clientevpn1
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 345
Source Linux
+ Creamos el directorio de llaves que usará el servidor OpenVPN y copiamos dentro todos los archivos de certificados
necesarios recién creados:
# mkdir /etc/openvpn/keys
# cd /etc/openvpn/easy-rsa/keys
# cp -v ca.crt dh1024.pem vpnserver.crt vpnserver.key /etc/openvpn/keys
# chmod 600 /etc/openvpn/keys/*.key
+ Iniciamos OpenVPN y verificamos los logs en busca de algún posible error que hayamos cometido:
Si todo está bien, entonces ya tendremos creada una interfaz de red tun0 con una dirección IP 10.30.25.1 y el puerto
UDP 1194 en estado de escucha, lo que se puede verificar como sigue:
# ifconfig
# ifconfig tun0
# netstat -unlp
+ De acuerdo a la directiva plugin del archivo /etc/openvpn/server.conf se tiene que la palabra 'openvpn' especificada a la
derecha de la ruta del archivo /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so especifica el nombre de la aplicación que será
usada para identificarse ante los módulos PAM del sistema.
De este modo entonces será necesario crear el archivo /etc/pam.d/openvpn que contenga la configuración de autenticación
contra Winbind realizada en capítulos anteriores.
El contenido del archivo /etc/pam.d/openvpn debería tener el siguiente contenido:
Las directivas resaltada en negrita corresponden a las modificaciones hechas para integrar la autenticación contra
Winbind, mientras que las otras directivas restantes corresponden a las predeterminadas que trae el archivo de
configuración /etc/pam.d/system-auth (en RedHat / CentOS y derivados).
Configuración de cliente:
+ Los archivos ca.crt, clientevpn1.crt y clientevpn1.key previamente creados serán enviados por algún medio seguro al usuario
encargado de realizar la conexión cliente de OpenVPN a nuestro servidor.
+ En un equipo corriendo un sistema operativo Windows con OpenVPN instalado, crear un archivo de configuración
C:\Archivos de programa\OpenVPN\config\cliente.ovpn con un contenido como el siguiente:
dev tun
proto udp
remote vpn.miservidor.com
resolv-retry infinite
nobind
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 346
Source Linux
persist-key
persist-tun
pull
tls-client
ca ca.crt
cert clientevpn1.crt
key clientevpn1.key
cipher BF-CBC
comp-lzo
verb 3
ping 15
ping-restart 60
auth-user-pass
+ Proceder a iniciar OpenVPN en Windows con la configuración arriba creada y verificar cómo es que se pide al usuario
autenticarse. Ingresar un usuario y password válido del dominio Active Directory para comprobar luego cómo se establece la
conexión correctamente.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 347
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 348
Source Linux
Unidad 17: Servidor de mensajería instantánea
17.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Es abierto -- el protocolo de Jabber es gratuito, abierto, público y comprensible. Además, existen múltiples implementaciones
de código abierto para Servidores Jabber (consulta la lista de servidores públicos) como numerosos clientes y librerías de
desarrollo.
✔ Es extensible -- usando el potencial del lenguaje XML, cualquiera puede extender el protocolo de Jabber para una
funcionalidad personalizada. Claro que para mantener la interoperatibilidad, las extensiones comunes son controladas por la
Jabber Software Foundation.
✔ Es descentralizado -- cualquiera puede montar su propio servidor de Jabber, además está libre de patentes y no depende
de ninguna empresa de modo que se puede usar ahora y siempre con total libertad.
✔ Es seguro -- Cualquier servidor de Jabber puede ser aislado de la red pública Jabber, cualquier implementación del servidor
usa SSL para las comunicaciones cliente-servidor y numerosos clientes soportan PGP-GPG para encriptar las
comunicaciones de cliente a cliente. Además, está en desarrollo una seguridad más robusta gracias al uso de SASL y
contraseñas de sesión.
Jabber puede crear confusión en un principio respecto a otros sistemas de mensajería instantánea porque habitualmente, en otros IM,
se identifica el cliente con el protocolo. En el caso de Jabber esto no es así: existe un protocolo y cada uno de los clientes es una
implementación.
La red Jabber
Al nivel más básico, si dos contactos tienen cuentas creadas en el mismo servidor, podrán hablar entre ellos. Aquí se puede ver a dos
usuarios que se conectan a sus cuentas del servidor 'jabberes.org', y hablan entre ellos directamente:
Existe una gran red de servidores Jabber interconectados entre sí, a la vez que independientes los unos de los otros. La mayoría de
estos servidores son privados, en el sentido de que son mantenidos por personas o asociaciones particulares, aunque de acceso
público, por lo que cualquier usuario puede usar sus servicios sin ninguna restricción.
Así, usuarios de distintos servidores conectados a la red Jabber pueden hablar entre ellos sin ningún problema, ya que cada usuario
está conectado a su servidor, y los servidores de estos usuarios se intercambian los mensajes:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 349
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 350
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 351
Source Linux
Podemos elegir entre muchos servidores, cada uno de ellos suele ofrecer diferentes servicios al usuario, y en nuestras manos está
escoger el servidor que más nos guste o convenga. Al fin y al cabo, independientemente del servidor que escojamos para acceder a la
red de Jabber, podremos conversar con contactos de otros servidores y añadirlos a nuestra lista de contactos.
En este gráfico se muestra a ocho usuarios Jabber, cada uno conectado al servidor que prefirió, incluso hay uno que está conectado a
dos servidores simultáneamente. Todos ellos pueden hablar entre sí, ya que sus servidores están integrados en la red Jabber:
En Jabber la dirección de cada usuario dependerá del servidor en el que tenga la cuenta, siguiendo el esquema siguiente:
nombre_de_usuario@nombre_de_servidor.
Por ejemplo, si nos conectamos a Jabber a través del servidor jabberes.org, nuestra cuenta será:
nombre_usuario@jabberes.org
Este mismo usuario puede crearse más cuentas en el mismo o en otros servidores, en cuyo caso sus direcciones serán del estilo:
nombre_usuario_de_incognito@jabber.org
nombre_usuario@jabberes.org
nombre_usuario@gmail.com
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 352
Source Linux
Clientes Jabber
La naturaleza abierta de este protocolo Jabber facilitan la creación de múltiples clientes los cuales pueden tener más o mejores
funcionalidades para el usuario final. Algunos de los clientes Jabber más comunes son:
• Coccinella
• Jabbim
• Jeti
• Pidgin
• Psi
• qutIM
• saje
• SIP Communicator
• Spark
• Tkabber
• Tlen
Existen muchos más clientes Jabber disponibles, pero los arriba mostrados son multiplataforma (Linux, Windows y MacOS).
Servidores Jabber
De manera similar a los clientes Jabber, existe una variedad de software de servidor de los cuales algunos se mencionan debajo:
• Citadel
• CommuniGate Pro
• djabberd
• ejabberd
• IceWarp
• iChat Server
• Indafon
• in.jabberd
• Isode M-Link
• jabberd 1.x
• jabberd 2.x
• Jabber XCP
• Jerry Messenger
• Kwickserver
• Openfire
• OpenIM
• Prosody
• psyced
• SoapBox Server
• Sun Java System Instant Messaging
• synapse
• Tigase
• Vysper
• Wokkel
En este documento nos centraremos en la administración y configuración de Openfire como servidor Jabber.
Instalación de Openfire
Openfire debe ser instalado desde su sitio Web oficial http://www.igniterealtime.org en la versión RPM o DEB según el sistema
operativo que utilicemos.
En Red Hat / CentOS y derivados procederíamos a instalar directamente el paquete RPM como sigue:
Esta diferencia se debe a que el paquete de Openfire en formato RPM ya trae incluido el Java JRE, pero no la versión en formato DEB,
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 353
Source Linux
por lo que se tuvo que instalar aparte en un sistema Debian.
Configuración de Openfire
Openfire posee una excelente administración Web fácil de entender y de configurar. En este apartado configuraremos Openfire
utilizando MySQL como backend para el almacenamiento de información de usuarios.
Por ello procederemos con los siguientes pasos:
En Debian y derivados:
# cd /opt/openfire/resources/database
# cat openfire_mysql.sql | mysql openfire
Una vez que se inicia el Openfire se habilita el puerto 9090 para la administración Web, a la cual nos conectaremos con un
navegador a una URL similar a http://localhost:9090 y una vez dentro seguiremos los pasos debajo descritos:
• Dominio: Un dominio que utilicemos para nuestro servidor Jabber. Ejm: consultorianet.com
• Puerto de la Consola de Administración: Dejar por defecto en 9090.
• Puerto de la Consola de Administración Segura: Dejar por defecto en 9091
• Conexión Estándar: Utiliza un motor de base de datos externo como MySQL, PostgreSQL, Oracle u otros.
• Base de datos interna: Utiliza una base de datos interna de Openfire. Recomendado para instalaciones pequeñas.
Elegir por defecto Conexión Estándard y luego dar clic en el botón Continuar.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 354
Source Linux
• Clase del Driver JDBC: Dejar por defecto en 'com.mysql.jdbc.Driver'
• URL de la Base de Datos: Completar con 'jdbc:mysql://localhost:3306/openfire'
• Nombre de usuario: Completar con 'openfire'.
• Contraseña: Completar con 'secret' (según el password asignado en la setencia SQL GRANT)
• Minimum Connections: Dejar por defecto en 5.
• Maximum Connections: Dejar por defecto en 25.
• Por defecto: Almacena las cuentas de usuario en la base de datos de Openfire (MySQL)
• Servidor de Directorio: Permite integrar las cuentas de usuario desde un servidor OpenLDAP o Active Directory.
• Integración con Clearspace: Permite integrar los usuarios desde una instalación de Clearspace.
Elegir por defecto Por Defecto y luego dar clic en el botón Continuar.
• Email del Administrador: La dirección e-mail de contacto del administrador. Ejm: admin@consultorianet.com
• Nueva Contraseña: Asignar un password seguro.
• Confirme la Contraseña: Repetir el mismo password.
... y luego conectarse a la consola de Openfire vía la URL http://localhost:9090 con las credenciales siguientes:
Usuario : admin
Password : **** (el asignado en el paso 2.6)
Terminado el asistente de configuración ya se puede utilizar las opciones de administración que ofrece Openfire a través de su interfaz
Web.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 355
Source Linux
17.3. Laboratorio N° 17
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Implementar un servidor Openfire que integre las cuentas de usuario desde un dominio Active Directory.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 356
Source Linux
17.3.1. Solución del laboratorio N° 17
1. Implementar un servidor Openfire que integre las cuentas de usuario desde un dominio Active Directory.
+ Instalar y configurar MySQL. Luego instalar y configurar Openfire de acuerdo a lo estudiado hasta el paso 2.4.
+ En la sección de configuración 'Seteos de Perfil' elegir la opción 'Servidor de Directorio (LDAP)', dando clic luego en
Continuar.
+ En la sección 'Seteos de Perfil: Seteos de Conexión' rellenar los campos del formulario como sigue:
+ En la sección 'Seteos de Perfil: Mapeos de Usuarios' todos los campos dejarlos por defecto con sus valores
predeterminados a menos que se tenga una razón específica para cambiar alguno de ellos.
Luego dar clic en Salvar & Continuar.
+ En la sección 'Seteos de Perfil: Mapeos de Grupos' todos los campos dejarlos por defecto con sus valores
predeterminados a menos que se tenga una razón específica para cambiar alguno de ellos.
Luego dar clic en Salvar & Continuar.
+ En la sección 'Cuenta del Administrador' agregar el nombre de usuario 'administrador' o algún otro que tenga los mismos
privilegios de administración en el Active Directory..
Luego dar clic en Salvar & Continuar.
+ Proceder a reiniciar Openfire y conectarse a la consola de administración usando las credenciales de uno de los
administradores agregados en el paso anterior.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 357
Source Linux
Unidad 18: Servicio de directorios LDAP
18.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
¿Qué es un directorio?
Es una colección que almacena información sobre objetos que están organizados y relacionados entre sí de alguna forma.
Según el proceso
• Directorio cliente: quien efectúa la solicitud
• Servidor de directorio: procesos de búsqueda de información en el directorio.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 358
Source Linux
Los servicios de directorio
Un servicio de directorio es la fuente de la información del directorio y los servicios que hacen que la información este disponible a
los usuarios. Un servicio de directorio proporciona los medios para organizar y simplificar el acceso a los recursos de un sistema de
computadoras de red. Un servicio de directorio identifica a los usuarios y a los recursos de manera única sobre una red y
proporciona una manera de organizar y acceder a otros usuarios y recursos.
Funciones para las que se puede utilizar un servicio de directorio:
✔ Identificación y autenticación.
✔ Seguridad para los objetos.
✔ Replicar un directorio.
✔ Dividir un directorio.
• Objetos
• Atributos
• Clases
• Unidades de organización
• Dominios
• Árboles
El protocolo LDAP
¿Qué es LDAP?
LDAP, Lightweight Directory Access Protocol, Protocolo de Acceso Ligero a Directorios, es un protocolo de tipo cliente/servidor para
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 359
Source Linux
acceder a un servicio de directorio. Este se encuentra condensado en el estándar de Internet, el RFC 1777.
Entre sus características están:
El árbol también se puede organizar basándose en los nombres de dominio de Internet. Este tipo de nombramiento se está
volviendo muy popular, ya que permite localizar un servicio de directorio haciendo uso de los DNS. La siguiente figura muestra un
ejemplo de un directorio LDAP que hace uso de los nombres basados en dominios.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 360
Source Linux
Fig. 2: Árbol del directorio LDAP (nombramiento de Internet)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 361
Source Linux
integridad.
LDAPv2 es histórico. Muchas implementaciones de LDAPv2 incluyendo slapd no se adaptan a las especificaciones técnicas de
LDAPv2, la interoperabilidad entre las distintas implementaciones de LDAPv2 es muy limitada. Como LDAPv2 difiere
significativamente de LDAPv3, la interactuación entre ambas versiones puede ser un poco problemática. LDAPv2 ha de evitarse,
por lo que en la implementación de OpenLDAP viene deshabilitado por defecto.
LDIF
LDAP Interchange Format (LDIF), es un formato de archivo estándar usado para almacenar configuraciones de información LDAP y
contenido de directorios. En su forma más básica un archivo LDIF es:
Los archivos LDIF por lo general son usados para importar nuevos datos al directorio LDAP o hacer cambios en él. Los datos en un
archivo LDIF deben obedecer las reglas de los esquemas del directorio LDAP. Puede imaginarse a un esquema como una definición de
datos para el directorio. Cada ítem que es agregado o modificado en el directorio es verficado contra los esquemas en busca de
errores y comprobación de la sintaxis correcta. Si un ítem del archivo LDIF no corresponde con las reglas de un esquema se produce
una violación de esquema.
El siguiente es un ejemplo válido de contenido de un archivo LDIF que representa las entradas de los dos primeros niveles del árbol
mostrado en la imagen de abajo.
dn: dc=plainjoe,dc=org
objectClass: domain
dc: plainjoe
dn: ou=devices,dc=plainjoe,dc=org
objectClass: organizationalUnit
ou: devices
dn: ou=people,dc=plainjoe,dc=org
objectClass: organizationalUnit
ou: people
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 362
Source Linux
Atributos y esquemas
¿Qué es un atributo?
Los tipos de atributo y sus reglas de sintaxis asociadas son similares a las declaraciones de variables y tipos de dato en muchos
lenguajes de programación. Los atributos son usados para contener valores. Las variables en los programas realizan una función
similar: almacenar información.
Cuando una variable es declarada en un programa, es definida de un cierto tipo de dato. Este tipo de dato especifica qué tipo de
información puede ser almacenado en la variable, a lo largo de otras tantas reglas, tal como comparar el valor de la variable con el
dato almacenado en otra variable del mismo tipo. Por ejemplo declarar una variable entera de 16-bit y luego asignarle 1,000,000
como valor no tendría sentido (el valor máximo representado por una variable de ese tipo es 32,767). El tipo de dato de 16-bit
determina qué datos pueden ser almacenados. El tipo de dato también determina qué valores de que tipo pueden ser comparados.
¿Es 3 < 5? Sí, desde luego que sí. ¿Cómo se sabe? Pues porque existe una serie de reglas para comparar enteros con otros
enteros. La sintaxis de atributos LDAP realizan funciones similares como los tipos de dato en el ejemplo mencionado.
A diferencia de las variables sin embargo, los atributos LDAP pueden tener múltiples valores. La mayoría de lenguajes de
programación obligan a usar una semántica de "almacenar y reemplazar" en las variables, así cuando se asigna un valor a una
variable el valor antiguo es reemplazado. Como se verá más adelante esto no es cierto en LDAP, dado que se puede asignar un
nuevo valor a un atributo como adicional de los valores ya existentes. A continuación se muestra unas líneas LDIF de ejemplo para
la entrada ou=devices,dc=plainjoe,dc=org que demuestra cómo un atributo puede tener múltiples valores:
dn: ou=devices,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: devices
telephoneNumber: +1 256 555-5446
telephoneNumber: +1 256 555-5447
description: Container for all network enabled
devices existing within the plainjoe.org domain
En el ejemplo se aprecia dos valores para el atributo telephoneNumber. En la vida real es común este caso para una entidad que
es accesible por más de un número telefónico.
Sin embargo hay que ser cuidadosos con el hecho que algunos atributos permiten sólo un único valor a la vez. Esto dependerá
directamente de la definición del atributo en el esquema del servidor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 363
Source Linux
Todas las entradas en un directorio LDAP deben tener un atributo objectClass, y este atributo debe tener al menos un valor
(aunque es posible y necesario a veces que tenga múltiples valores). Cada valor de objectClass actúa como una plantilla para
los datos que serán almacenados en la entrada. Permite definir una serie de atributos que deben obligatoriamente estar presentes
en la entrada así como también una serie de atributos opcionales que pueden o no estar presentes.
Regresando al ejemplo anterior la entrada ou=devices,dc=plainjoe,dc=org se tiene:
dn: ou=devices,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: devices
telephoneNumber: +1 256 555-5446
telephoneNumber: +1 256 555-5447
description: Container for all network enabled
devices existing within the plainjoe.org domain
En este caso el valor del atributo objectClass es organizationalUnit. La definición de esquema de la imagen que se
muestra debajo permitirá comprender mejor esto:
i. Un objectClass posee un OID, tal como los tipos de atributos, sintaxis de codificación y reglas de comparación. La
palabra MUST denota una serie de atributos que deben estar presentes en cualquier instancia de este objeto. En este
caso el "estar presente" significa que el atributo debe tener al menos un valor.
ii. La palabra MAY define una serie de atributos cuya presencia es opcional dentro de una instancia del objeto.
iii. La palabra SUP especifica que el objeto padre del cual este objeto se ha derivado. Un objeto derivado posee todos los
requerimientos de tipo de atributo de su padre. Los atributos pueden ser derivados de otros atributos también, también
heredarán la sintaxis y reglas de comparación de su padre, aunque el último puede ser sobreescrito por el nuevo
atributo. Los objetos LDAP no soportan herencia múltiple, ellos tienen simplemente un único padre así como sucede con
los objetos de Java.
Tipos de objectClass
Tres tipos de definición de objectClass pueden ser usados en los servicios de directorio LDAP:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 364
Source Linux
con el modelo de datos LDAP, una vez que un objeto estructural de una entrada ha sido ingresado, no puede ser cambiado sin
eliminar y volver a crear la entrada completa.
dn: dc=plainjoe,dc=org
objectclass: domain
dc: plainjoe
Como antes ya estudiamos, existe el nombramiento basado en la ubicación geográfica y el nombramiento basado en nombres
DNS, siendo este último el recomendado.
Para soportar una asociación entre los nombres DNS y un espacio de nombres de un directorio LDAP, el RFC 2247 define dos
objetos para almacenar componentes mostrados en la figura:
dcObject es una clase auxiliar que sirve para complementar una entrada que contiene información organizacional (Ejm:
organizationalUnit). La clase dcObject actúa como un contenedor independiente para la información organizacional y el
componente de nombre de dominio (Ejm: el atributo dc). La clase de objeto organizationalUnit y los objetos de dominio
poseen atributos comunes.
Generar un DN (Nombre distinguido) LDAP para representar un nombre de dominio DNS es un proceso simple. Un DN vacío se
usa como punto de partida. Un RDN dc=domain es agregado como componente al DNS de cada porción del dominio. Por
ejemplo, el nombre de dominio plainjoe.org se asocia con el contexto de nombramiento dc=plainjoe,dc=org
¿Y donde está dc=org? Como veíamos dc=plainjoe,dc=org es el contexto de nombramiento del directorio. Si la entrada raíz
de nuestro directorio fuese dc=org con una entrada hijo como dc=plainjoe,dc=org entonces el contexto de nombramiento
sería dc=org. Esto tendría como consecuencia que nuestro servidor empiece a responder de manera innecesaria a consultas cuyo
DN termine en dc=org, aún si el servidor solamente contenga información debajo de dc=plainjoe,dc=org
Es así que que el diseño de un espacio de nombres es similar a una jerarquía DNS. Los servidores DNS para el dominio
plainjoe.org no necesitan atender consultas del dominio .org, dado que aquellas consultas deben ser redireccionadas a un servidor
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 365
Source Linux
que en realidad sí contenga dicha información.
Atributos comunes
Estos son una serie de los atributos más comunes que usaremos:
account
Tipo: Estructural
Padre: top
Atributos obligatorios: uid
Atributos opcionales: description, seeAlso, localityName, organizationName, organizationalUnitName,
host
dcObject
Tipo: Auxiliar
Padre: top
Atributos obligatorios: dc
Atributos opcionales: (ninguno)
inetOrgPerson
Tipo: Estructural
Padre: organizationalPerson
Atributos obligatorios: (ninguno)
Atributos opcionales: audio, businessCategory, carLicense, departmentNumber, displayName,
employeeNumber, employeeType, givenName, homePhone, homePostalAddress, initials, jpegPhoto,
labeledURI, mail, manager, mobile, o, pager, photo, roomNumber, secretary, uid, userCertificate,
x500uniqueIdentifier, preferredLanguage, userSMIMECertificate, userPKCS12
organizationalPerson
Tipo: Estructural
Padre: person
Atributos obligatorios: (ninguno)
Atributos opcionales: title, x121Address, registeredAddress, destinationIndicator,
preferredDeliveryMethod, telexNumber, teletexTerminalIdentifier, telephoneNumber,
internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode,
postalAddress, physicalDeliveryOfficeName, ou, st, l
organizationalUnit
Tipo: Estructural
Padre: top
Atributos obligatorios: ou
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 366
Source Linux
Atributos opcionales: userPassword, searchGuide, seeAlso, businessCategory, x121Address,
registeredAddress, destinationIndicator, preferredDeliveryMethod, telexNumber,
teletexTerminalIdentifier, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber,
street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, st, l, description
person
Tipo: Estructural
Padre: top
Atributos obligatorios: cn, sn
Atributos opcionales: userPassword, telephoneNumber, seeAlso, description
posixAccount
Tipo: Auxiliar
Padre: top
Atributos obligatorios: cn, uid, uidNumber, gidNumber, homeDirectory
Atributos opcionales: userPassword, loginShell, gecos, description
posixGroup
Tipo: Estructural
Padre: top
Atributos obligatorios: cn, gidNumber
Atributos opcionales: userPassword, memberUid, description
shadowAccount
Tipo: Auxiliar
Padre: top
Atributos obligatorios: uid
Atributos opcionales: userPassword, shadowLastChange, shadowMin, shadowMax, shadowWarning,
shadowInactive, shadowExpire, shadowFlag, description
Esquemas comunes
Estas son una serie de esquemas más comunes que usaremos:
Autenticación en LDAP
¿Por qué se necesita autenticación en un directorio LDAP? Recuerde que LDAP es un protocolo basado en mensajes orientado a
la conexión. El proceso de autenticación es usado para establecer los privilegios de usuario para cada sesión. Todas las
búsquedas, consultas, etc, son controladas según el nivel de autorización del usuario autenticado.
La siguiente figura describe la clase de objeto person y nos brindará una idea de qué atributos están disponibles para la entrada
cn=gerald carter en entrada de ejemplo más abajo. En general necesitaremos definir un atributo userPassword para futuras
tareas de autenticación LDAP.
Hemos agregado un atributo userPassword. Este atributo almacena una reprentación de las credenciales necesarias para
autenticar a un usuario. El prefijo (en este caso {MD5}) describe cómo la credencial es codificada. El valor en este caso es
simplemente la codificación Base 64 del hash MD5 sobre la palabra "secret" (sin comillas).
Existen una serie de algoritmos de encriptación y algunos de los más comunes usados en LDAP son:
{CRYPT}
El hash de la clave debe ser generado usando la función local del sistema crypt( ), el cual es normalmente incluido en las
librerías del lenguaje C.
{MD5}
El hash de la clave es una codificación Base64 del digest MD5 sobre la contraseña del usuario.
Durante el proceso de autenticación en cualquier servicio (FTP, SSH, SMTP, POP, IMAP, etc) es común que el cliente brinde un
nombre de usuario y la respectiva contraseña. En LDAP la autenticación se lleva a cabo a través de un DN brindada por el cliente
que será interpretado como nombre de usuario (Ejm: cn=gerald carter,ou=people,dc=plainjoe,dc=org), y la contraseña
respectiva será leída del atributo userPassword de dicha entrada.
Filtros LDAP
Los filtros LDAP son una serie de patrones que tienen por objetivo limitar y especificar el alcance de las búsqueda dentro un directorio
LDAP. En su forma comúnmente usada un filtro LDAP tiene la siguiente sintaxis:
El atributo es el nombre actual del tipo de atributo. El filtro_Operador es uno de los siguientes:
Si solamente tratamos con comparaciones de cadenas entonces puede ser que sólo se necesite el operador =.
El valor puede ser absoluto como 326-3872 (para un telephoneNumber por ejemplo) o un patrón usando el caracter * como
comodín. Por ejemplo (cn=*carter) buscaría todas las entradas cuyo atributo cn termina en "carter".
Puede combinarse filtros simples usando operadores lógicos como estos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 368
Source Linux
& : AND lógico
| : OR lógico
! : NOT lógico
Los filtros LDAP usan una notación prefija para unir condiciones. Por lo tanto para buscar usuarios con un apellido (sn) como "smith" o
"jones" podría construirse el siguiente filtro:
(|(sn=smith)(sn=jones))
Para buscar personas con un apellido como "smith" o "jones" y un nombre que empiece con "John", la búsqueda sería como sigue:
(&(|(sn=smith)(sn=jones))(cn=john*))
Instalación de OpenLDAP
OpenLDAP puede ser instalado directamente desde los repositorios de las distribuciones Linux como sigue:
En Debian y derivados:
Observación:
• En Debian la instalación del paquete slapd (el servidor LDAP, OpenLDAP) nos consultará cuál es la contraseña que
deseamos asignar al administrador rootdn por defecto.
Configuración de OpenLDAP
El paquete OpenLDAP incluye herramientas clientes, servidores y librerías. La siguiente tabla muestra una descripción breve de la
función que cumple cada uno de los componentes dentro del paquete LDAP:
Nombre Descripción
libexec/slapd El servidor LDAP
libexec/slurpd El servidor de replicación LDAP
bin/ldapadd
bin/ldapmodify Herramientas de línea de comandos para agregar, modificar y eliminar entradas en un servidor LDAP. Estos
bin/ldapdelete comandos soportan LDAPv2 y LDAPv3.
bin/ldapmodrdn
bin/ldapsearch Herramientas de línea de comandos para buscar dentro de un servidor LDAP o realizar alguna operación de
bin/ldapcompare comparación en un atributo específico contenido en una entrada.
Una herramienta para cambiar el atributo password en las entradas LDAP. Es equivalente al comando
bin/ldappasswd
passwd del sistema.
sbin/ldapadd
sbin/ldapcat Herramientas para manipular la data almacenada del backend local usada por el demonio slapd.
sbin/ldapindex
sbin/slappasswd Una herramienta sencilla que sirve para generar hashes para las contraseñas de uso posterior en slapd.conf
Observaciones:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 369
Source Linux
Las líneas en blanco y aquellas que empiecen con el caracter # son ignoradas.
Los parámetros y sus valores asociados son separados por espacios en blanco (espacios y/o tabulaciones).
Una línea que contenga un espacio en blanco en la primera columna se considerará una continuación de la anterior. No se
requiere usar el caracter \ para continuar líneas más abajo.
El archivo de configuración slapd.conf suele separar su contenido en dos partes. La primera de ellas contiene todas las directivas
asociadas al funcionamiento general del servidor (por ejemplo el nivel de registro enviado a los logs). La segunda parte contiene las
directivas asociadas a la definición de los backends usados por el demonio slapd.
# /etc/openldap/slapd.conf
# Seccion global
#######################################################
# Base de datos #1 - Berkeley DB
database bdb
#######################################################
# Base de datos #2 - Berkeley DB
database bdb
## Y asi sucesivamente...
include
Esta directiva es la que permite incluir otros archivos dentro de slapd.conf, usualmente usado para especificar qué archivos de
esquema deben ser soportados por el servidor. Por defecto los archivos de esquema suelen ser ubicados en el directorio
/etc/openldap luego de la instalación.
El primer paso en configurar el servidor LDAP es decidir qué archivos de esquema el directorio debe soportar. No es una tarea fácil
responder a esta pregunta en unas pocas líneas.
OpenLDAP incluye algunos archivos de esquema populares para ser usados con discreción por el administrador. Las necesidades
de las aplicaciones que usarán el directorio determinarán qué esquema usar. Todas las definiciones de tipos de atributos y clases
de objeto requeridos por un servidor LDAP básico son incluidas en el archivo core.schema. Algunos de los tipos de atributos son:
• Atributos para almacenar la fecha y hora dela última modificación en una entrada
• Atributos para representar nombre, ubicación, etc.
• Objetos para representar una organización o persona
• Objetos para representar nombres de dominio DNS
• Entre otros...
Existen archivos de esquema incluidos con la instalación OpenLDAP como los siguientes:
corba.schema
Un esquema para almacenar objetos Corba en un directorio LDAP, como es descrito en el RFC 2714.
core.schema
El esquema más importante requerido por OpenLDAP. Este esquema define atributos básicos de
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 370
Source Linux
LDAPv3 y objetos descritos en los RFCs 2251-2256.
cosine.schema
Un esquema para soportar directorios piloto COSINE y X.500. Basado en el RFC 1274.
inetorgperson.schema
El esquema que define la clase de objeto inetOrgPerson y sus atributos asociados definidos en el
RFC 2798. Este objeto es frecuentemente usado para almacenar información de contacto de
personas.
java.schema
Un esquema definido en el RFC 2713 para almacenar distintos tipos de objeto de Java.
misc.schema
Un esquema que define un grupo pequeño de objetos y atributos misceláneos. Actualmente, este
archivo contiene el esquema necesario para implementar un sistema de correo basado en LDAP y
Sendmail 8.10+
nis.schema
Un esquema que define atributos y objetos necesarios para usar LDAP con Network Information
Service (NIS) tal como es descrito en el RFC 2307
openldap.schema
Objetos misceláneos usados por el proyecto OpenLDAP. Provisto por propósitos informativos
solamente.
Ejemplo:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
Las aplicaciones clientes que deseamos soportar pueden requerir archivos de esquema adicionales a core.schema. Es necesario
asegurarse de las dependencias entre archivos de esquema. Las dependencias son normalmente descritas al inicio del archivo.
Por ejemplo, muchas aplicaciones requieren que se incluya la clase de objeto inetOrgPerson, el cual es frecuentemente usado
para almacenar información de contacto. En el inicio del archivo inetorgperson.schema puede encontrarse una línea donde se indica
que también debe incluirse el archivo cosine.schema.
loglevel
Esta directiva define el nivel de registro a almacenarse durante el funcionamiento de OpenLDAP. Toma como valor un número de la
tabla mostrada debajo, y pueden sumarse varios de aquellos números para obtener un registro equivalente a todas sus categorías
correspondientes juntas. Los registros por defecto son enviados a syslog usando la facilidad LOG_LOCAL4.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 371
Source Linux
1024 Comunicación con backends de shell
2048 Imprime información de depuración sobre el procesamiento de entradas
En el siguiente ejemplo se registrará información sobre el procesamiento de ACLs, los filtros de búsqueda y la administración de
conexiones (128 + 32 + 8):
loglevel 168
pidfile
Esta directiva define la ruta del archivo que contendrá el PID del demonio slapd.
Ejemplo:
pidfile /var/run/slapd.pid
argsfile
Esta directiva define la ruta del archivo que contendrá los parámetros de línea de comandos usados comúnmente por el demonio
slapd.
Ejemplo:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
require
Esta directiva define ciertas exigencias por parte del cliente al momento de conectarse al servidor LDAP.
En el siguiente ejemplo se obliga a que los clientes se autentiquen (authc) antes de hacer cualquier operación, y lo hagan con la
versión 3 del protocolo LDAP (LDAPv3):
Directivas de backends
Luego de la sección global del archivo slapd.conf vendrán una o más secciones de las bases de datos, cada una de ellas constituida
de varias directivas las cuales se pasan a estudiar a continuación.
database
Una sección de base de datos empieza con la directiva database y continúa hasta la próxima ocurrencia de dicha directiva o
hasta el final del archivo. Esta directiva recibe como parámetro el backend que puede ser bdb o ldbm
Ejemplo:
database bdb
suffix
Esta directiva permite definir el sufijo raíz del directorio que se servirá.
Sintaxis: suffix DN
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 372
Source Linux
suffix "dc=newdomains,dc=com"
rootdn
Esta directiva define un DN que representará el acceso de un usuario con todos los privilegios sobre el directorio servido, similar a
lo que sería root en un sistema UNIX. Este DN está autorizado a hacer todo, dado que las ACLs no le afectarán en absoluto.
Sintaxis: rootdn DN
Ejemplo:
rootdn "cn=Manager,dc=newdomains,dc=com"
rootpw
Esta directiva define la contraseña correspondiente para el DN definido en rootdn. El valor para esta contraseña debe ser
generada por la herramienta slappasswd.
En el primer ejemplo se usa una contraseña en texto plano y en el segundo el hash correspondiente a la misma clave pero
generada por el algoritmo SSHA:
rootpw clave123
rootpw {SSHA}3fsj+79Ta+G0Ehn789MJ3IYccmPajerT
lastmod
Esta directiva indica a OpenLDAP que debe mantener actualizados los atributos operacionales tales como modifiersName,
modifyTimestamp, creatorsName y createTimestamp para todas las entradas de core.schema. El comportamiento normal
es mantener actualizadas todas estos atributos dado que en el caso de deshabilitarlo no se podrá hacer uso de la caché por cliente
debido a que no se puede saber cuándo fue modificada por última vez una entrada.
Ejemplo:
lastmod on
readonly
Esta directiva instuye a OpenLDAP para que la base de datos quede protegida de cualquier operación de modificación incluso por
el mismo rootdn.
Ejemplo:
readonly off
directory
Esta directiva define la ruta del directorio de la base de datos. Los archivos dentro de este directorio deberían ser de propiedad del
usuario bajo el cual es ejecutado slapd.
Ejemplo:
directory /var/lib/ldap
mode
Esta directiva define los permisos UNIX que deben tener los archivos de la base de datos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 373
Source Linux
Ejemplo:
mode 0600
index
Esta directiva define los atributos en los que OpenLDAP debe mantener índices los mismos que son usados para optimizar las
búsquedas.
approx (approximate)
Indexa la información por una coincidencia aproximada o fonética del valor de un atributo
eq (equality)
Indexa la información necesaria para ejecutar una coincidencia exacta del valor de un atributo
pres (presence)
Indexa la información necesaria para determinar si un atributo tiene un valor o no. Si un
atributo no posee un valor entonces el atributo no está presente en la entrada del directorio
sub (substring)
Indexa la información necesaria para ejecutar una coincidencia simple de subcadena del valor de
los atributos
Ejemplo:
index objectClass eq
index cn,sn pres,eq
cachesize
Esta directiva define el número de entradas que deberían ser almacenadas en memoria caché. Por defecto se almacena 1,000
entradas en caché, pero si el número de entradas es menor a esta cantidad no es necesario modificar el valor de esta directiva.
En el siguiente ejemplo se tiene un directorio de aproximadamente 1,000,000 entradas para el cual vendría bien un valor de
100,000:
cachesize 100000
*
Coincide con cualquier usuario conectado incluso bajo conexiones anónimas
self
Representa el DN del usuario actualmente conectado, asumiendo que ha sido autenticado
exitosamente por un proceso de autenticación previo
anonymous
Conexiones anónimas no autenticadas
users
Conexiones de usuarios autenticados
Expresión regular
Coincide con un DN bajo una expresión regular
La siguiente tabla resume los varios privilegios de acceso que puede obtener un usuario. Los privilegios más altos implican tener
todas las capacidades de los privilegios anteriores. Por ejemplo tener el acceso search implicará que tiene acceso auth y
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 374
Source Linux
compare
Finalmente la definición de "¿A qué?" se tiene acceso define la entrada y sus atributos a los cuales la ACL debería aplicarse. Está
compuesta de 3 partes de las cuales todas son opcionales:
dn.estilo=patrón
exact
Sinónimo de base. Indica una entrada cuya DN es exactamente igual a la expresada en patrón.
Se usa este estilo por defecto si se omite
one
Sinónimo de onelevel. Indica todas las entradas ubicadas inmediatamente debajo de la
entrada expresada en patrón
sub
Sinónimo de subtree. Indica todas las entradas existentes en el árbol de la entrada
expresada en patrón
children
Indica todas las entradas subordinadas a la entrada expresada en patrón
regex
Indica una entrada según la expresión regular representada en patrón
3) Una lista de atributos separados por coma (",") expresados como attrs=LISTA-ATRIBUTOS. Si no se especifica esta parte
entonces la ACL se aplica a todos los atributos de la entrada.
Si ninguna de estas 3 partes es especificada entonces un simple asterisco ("*") es usado en reemplazo para hacer referencia a
todo. De esta manera se define la siguiente directiva para slapd.conf:
access
Esta directiva define una ACL sobre "A qué" debe darse "Cuánto acceso" y "A quién". Es importante tener en cuenta que las ACLs
son jerárquicas, esto significa que importa mucho el orden vertical en el que deben ser declaradas en el archivo slapd.conf.
En el siguiente ejemplo se protege el atributo userPassword de modo que solamente el usuario administrador con DN
cn=admin,dc=newdomains,dc=com tenga permiso de escritura, los usuarios anónimos tengan sólo acceso a autenticarse, los
usuarios autenticados propietarios de su entrada puedan modificar tal atributo y al resto se le deniega todo el acceso. Además el
directorio entero se protege de ser leído por quienes no se hayan autenticado exitosamente:
access to dn.base=""
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 375
Source Linux
by * read
access to attrs=userPassword
by dn="cn=admin,dc=newdomains,dc=com" write
by anonymous auth
by self write
by * none
access to *
by dn="cn=admin,dc=newdomains,dc=com" write
by users read
by * none
dn: dc=newdomains,dc=com
objectClass: dcObject
objectClass: organization
dc: newdomains
o: New Domains Technologies Inc.
Luego de guardar los cambios en el archivo ~/base.ldif se debe proceder a usar la herramienta slapadd para ingresar el contenido
al directorio siempre y cuando el demonio slapd esté detenido.
La forma básica de uso de esta herramienta es como sigue:
slapadd [opciones]
Opciones:
-b SUFIJO : Define el sufijo del directorio bajo el cual se agregarán las entradas
-c : Continúa agregando las entradas aún si en alguna de ellas encontrase algún error
-l : Especifica la ruta del archivo LDIF del cual agregar las entradas
-v : Modo verboso
2. Volcado de contenido
Una vez que el directorio ya se encuentra en funcionamiento es posible poder volcar su contenido -originalmente almacenado en el
backend respectivo- hacia una salida de texto con formato LDIF. Esto es posible con la herramienta slapcat cuya forma de uso es
la siguiente:
slapcat [opciones]
Opciones:
-b SUFIJO : Define el sufijo del directorio debajo del cual se mostrará su contenido
-a FILTRO : Solamente muestra las entradas que coincidan con el filtro especificado
-s DN : Permite mostrar el contenido del directorio que se encuentre sólo debajo de la DN especificada
-c : Continúa mostrando las entradas aún si sucediese algún error
-l : Especifica la ruta de un archivo al cual enviar el contenido del directorio en formato LDIF
-v : Modo verboso
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 376
Source Linux
En el siguiente ejemplo de hace un volcado del directorio cuyo sufijo es dc=newdomains,dc=com hacia el archivo dump.ldif:
3. Generación de contraseñas
En el transcurso del funcionamiento del directorio el administrador en más de una ocasión se encontrará en la necesidad de
generar contraseñas para diversas entradas de usuarios a fin que puedan autenticarse en el futuro valiéndose de la herramienta
slappasswd. Observe la forma de uso de esta herramienta:
slappasswd [opciones]
Opciones:
-e CLAVE : Genera un hash a partir de la clave brindada o se la pide al usuario si se omite parámetro
-h ESQUEMA : Define el esquema del hash generado. Valores: {SHA}, {MD5}, {CRYPT}, {SSHA}, {SMD5} y {CLEARTEXT}
-T ARCHIVO : Genera un hash a partir del contenido del archivo especificado
-v : Modo verboso
En el siguiente ejemplo se genera un hash MD5 para la contraseña que será especificada desde la entrada estándar por el
administrador:
# slappasswd -h {md5}
New password:
Re-enter new password:
{MD5}TRhjIcGn8PNUspfokUqyQA==
ldapmodify [opciones]
Opciones:
Las entradas pueden ser modificadas a través de un archivo de formato LDIF en el cual se indiquen las entradas a agregar o
modificar especificando qué atributos eliminar, agregar o modificar. Este archivo debe contener la palabra changetype que
permitirá especificar de qué tipo de cambio se trata el que está por efectuarse, siguiendo la forma descrita debajo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 377
Source Linux
Así, en el siguiente ejemplo se crean dos entradas que son una unidad organizativa y un usuario dentro de ésta:
# /root/update.ldif
dn: ou=users,dc=newdomains,dc=com
objectClass: organizationalUnit
ou: users
dn: uid=angel,ou=users,dc=newdomains,dc=com
objectClass: account
objectClass: posixAccount
uid: angel
cn: Angel Rengifo
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/angel
Luego el contenido de dicho archivo LDIF se agregará al directorio autenticado con el rootdn correspondiente:
Ahora se generará un archivo donde se indique las modificaciones a hacer sobre el directorio:
El contenido del archivo LDIF donde se ordene las operaciones a realizar es:
# /root/update.ldif
dn: uid=admin,ou=users,dc=newdomains,dc=com
changetype: add
objectClass: account
objectClass: posixAccount
uid: admin
cn: Administrator
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/admin
userPassword: {SSHA}fSR/7ya65y4LRfgDGdv1kO52WpTwj3L4
dn: uid=angel,ou=users,dc=newdomains,dc=com
changetype: modify
add: userPassword
userPassword: {SSHA}a4bbXzy/ybSNWs5IOErixG9n3DnZ2F9X
# /root/update.ldif
dn: uid=angel,ou=users,dc=newdomains,dc=com
changetype: delete
Una forma equivalente de eliminar una entrada sería usar la herramienta ldapdelete de manera directa sin necesidad de generar
un archivo LDIF con las modificaciones. La forma de usarlo sería como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 378
Source Linux
En caso se desee eliminar una entrada que tiene otras tantas subordinadas se requiere el parámetro -r como el siguiente ejemplo
donde se eliminará la entrada "ou=users,dc=newdomains,dc=com" y todos los usuarios que existan dentro:
Búsquedas en el directorio
Una operación de búsqueda sobre un directorio puede implicar algunos aspectos extras al sólo definir el patrón a buscar. Debe
considerarse que muchas veces será necesario autenticarse antes de intentar buscar algo, así como también puede ser necesario
limitar el ámbito de búsqueda, ser más específico con el uso de filtros LDAP, limitar el número de resultados, etc. Todos estos
aspectos entre otros son tratados por la herramienta ldapsearch cuya forma de uso es la siguiente:
Opciones:
En el siguiente ejemplo buscamos todo lo existente dentro del sufijo de directorio "dc=newdomains,dc=com" autenticándonos
como rootdn bajo el DN "cn=Manager,dc=newdomains,dc=com":
Agregar un filtro a la búsqueda anterior para encontrar aquellos cuyo nombre contenga "juan" o en su apellido contenga "ruiz":
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 379
Source Linux
18.3. Laboratorio N° 18
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Implementar una libreta de direcciones básica para ser consultada desde Outlook Express, Microsoft Outlook u otro cliente
de correo con soporte LDAP para libretas de contactos.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 380
Source Linux
18.3.1. Solución del laboratorio N° 18
1. Implementar una libreta de direcciones básica para ser consultada desde Outlook Express, Microsoft Outlook u otro cliente
de correo con soporte LDAP para libretas de contactos.
+ En un sistema CentOS tras instalar OpenLDAP dejando intacto su archivo de configuración, editar el archivo
/etc/openldap/slapd.conf para agregar lo siguiente al final del mismo:
database bdb
suffix "dc=consultorianet,dc=com"
rootdn "cn=admin,dc=consultorianet,dc=com"
rootpw {SSHA}kJhc0B7zQW16lAaVv13cnE86V5zjew7I
directory /var/lib/ldap/consultorianet.com
mode 0770
# slappasswd -h {SSHA}
+ Crearemos el contenido base del directorio creando un archivo LDIF (Ejm: /root/base.ldif) con un contenido como el
siguiente:
dn: dc=consultorianet,dc=com
objectClass: dcObject
objectClass: organization
dc: consultorianet
o: Libreta de direcciones de Consultorianet
dn: ou=libreta,dc=consultorianet,dc=com
objectClass: organizationalUnit
ou: libreta
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 381
Source Linux
mail: apacheco1981@hotmail.com
# mkdir /var/lib/ldap/consultorianet.com
+ Nos aseguramos que OpenLDAP no esté en ejecución e insertamos el contenido del archivo LDIF al directorio
perteneciente a dc=consultorianet,dc=com:
+ Si el paso anterior terminó correctamente entonces nos toca corregir los permisos de la base de datos OpenLDAP al
usuario con el cual corre el demonio slapd:
+ Verificamos la sintaxis del archivo de configuración y si no hay ningún error iniciamos OpenLDAP, verificando luego que
éste haya arrancado correctamente:
# slaptest -u
# service ldap start
# ps -ef | grep slapd
# netstat -tnlp | grep 389
+ Comprobamos el contenido del directorio haciendo una búsqueda básica a la base dc=consultorianet,dc=com:
+ Si lo anterior ya retorna el contenido completo del directorio, entonces este servidor OpenLDAP ya está listo para ser
consultado desde un cliente de correo indicando los siguientes datos de conexión:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 382
Source Linux
Unidad 19: Servidor de Correo Electrónico
19.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Conocer los componentes de un sistema de correo electrónico y propósito de cada uno de ellos.
✔ Saber implementar los servicios básicos POP3, IMAP y SMTP con componentes Open Source.
✔ Integrar herramientas de filtrado de Spam y Virus sobre los servicios de correo existentes.
✔ Implementar una herramienta de monitoreo y control de cuarentena de los correos electrónicos.
✔ Realizar una instalación y configuración básica de un Webmail para los usuarios remotos.
Así pues, un servidor de correo consta en realidad de dos servidores: un servidor SMTP que será el encargado de enviar y recibir
mensajes, y un servidor POP/IMAP que será el que permita a los usuarios obtener sus mensajes.
Para obtener los mensajes del servidor, los usuarios se sirven de clientes, es decir, programas que implementan un protocolo
POP/IMAP. En algunas ocasiones el cliente se ejecuta en la máquina del usuario (como el caso de Mozilla Thunderbird, Evolution,
Microsoft Outlook). Sin embargo existe otra posibilidad: que el cliente de correo no se ejecute en la máquina del usuario; es el caso de
los clientes vía web, como GMail, Hotmail, OpenWebmail, SquirrelMail o Terra. En ellos la arquitectura del servicio es más compleja:
En una máquina (A) tenemos el servidor SMTP y el servidor POP/IMAP. En otra (B) tenemos un servidor web con una aplicación cliente
POP/IMAP. El usuario conecta vía WEB con (B) y entonces el cliente POP/IMAP establece una conexión POP/IMAP con el servidor de
la máquina A; éste servidor le devuelve a B los mensajes del usuario, y una vez recibidos, el cliente genera una página web con los
mensajes recibidos. La página web se pasa al servidor web que será el que la envíe al explorador web del usuario.
En cualquier caso, los protocolos SMTP/POP/IMAP son inseguros en cuanto a que los mensajes viajan en claro por la red, es decir, es
fácil obtener nuestros mensajes y contraseñas. Para ello se suele añadir una capa SSL, es decir, un método de cifrado que puedan
implementar tanto el servidor como el cliente. En el caso del correo vía web se pueden utilizar dos capas SSL: una entre A y B y otra
entre el servidor web de B y el navegador web del usuario.
Tecnologías usadas
Este documento le guiará a través de los pasos a seguir para instalar y configurar un sistema de correo completo que consta de
diversos componentes como los mencionados a continuación:
• Postfix
El MTA o servidor SMTP para el envío y recepción de correos
• Cyrus IMAP
El servidor POP/IMAP usado por los usuarios para la lectura de correos
• Cyrus SASL
El servicio encargado de la autenticación
• MailScanner
El filtro de contenidos para los correos que eliminará el Spam y Virus
• ClamAV
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 383
Source Linux
El antivirus
• SpamAssassin
La avanzada herramienta antispam
• Horde
El Webmail completo y funcional
• MailWatch
El administrador de tráfico de correo y cuarentenas
Consideraciones iniciales
SASL son las siglas de Simple Authentication and Security Layer, un método para añadir soporte para la autenticación a protocolos
basados en la conexión que ha sido estandarizado por la IETF (Internet Engineering Task Force). Se usa en servidores (en este
caso Cyrus IMAP) para manejar las peticiones de autenticación de los clientes. Para ello, el protocolo incluye un comando para
identificar y autenticar un usuario contra un servidor y para, opcionalmente, negociar la protección de las subsiguientes
interacciones del protocolo. Si se negocia su uso, una capa de seguridad es añadida entre el protocolo y la conexión.
La librería SASL de Cyrus también usa la librería OpenSSL para cifrar los datos. El lector encontrará más información en la página
web de Cyrus SASL.
En Debian y derivados el archivo a editar es /etc/default/saslauthd y modificamos la líneas que se mencionan a continuación:
START=YES
MECHANISMS="pam"
En Red Hat / CentOS y derivados el archivo a editar es /etc/sysconfig/saslauthd y modificamos la líneas que se mencionan a
continuación:
MECH="pam"
configdirectory
Permite definir la ruta al directorio de la configuración IMAP del servicio. En este directorio se almacena información variada sobre
los buzones de los usuarios como por ejemplo la cuota, muchos de ellos presentados como archivos binarios indexados de la base
de datos Berkeley.
Ejemplo:
configdirectory: /var/lib/imap
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 384
Source Linux
defaultpartition
Esta directiva permite definir la partición por defecto usada para la creación de nuevos buzones. El nombre que recibe es definido
en una directiva partition-NOMBRE. Es en esta partición donde se almacena el contenido de los buzones de todos los usuarios.
Ejemplo:
defaultpartition: default
partition-NOMBRE
Esta directiva permite definir un nombre de partición que apunta a una ruta de directorio dentro del sistema de archivos.
Ejemplo:
partition-default: /var/spool/imap
unixhierarchysep
Esta directiva permite que los buzones de IMAP puedan tener el caracter punto "." como parte de su nombre. Esto es porque por
defecto Cyrus IMAP usa el punto "." como delimitador de buzones en sus diversos niveles de jerarquía y asignando el valor yes
a esta directiva evitará interpretaciones incorrectas respecto a dicho caracter especial.
Ejemplo:
unixhierarchysep: yes
admins:
Esta directiva define una lista de usuarios del sistema que tendrán los mayores privilegios de administrador sobre todos los
servicios que ofrezca Cyrus IMAP.
Ejemplo:
admins: cyrus
allowplaintext
Esta directiva permite que las autenticaciones se puedan dar en texto plano pues es la única forma soportada por SASL PLAIN.
Asignar su valor en yes para asegurar la compatibilidad con el valor de la siguiente directiva:
allowplaintext: yes
sasl_mech_list
Esta directiva especifica la lista de mecanismos SASL permitidos para que los usuarios puedan autenticarse.
Ejemplo:
sasl_mech_list: PLAIN
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 385
Source Linux
sasl_pwcheck_method
Esta directiva permite definir el método que se usará para realizar el proceso de autenticación. Algunos valores posibles son
auxprop y saslauthd pero se procederá a usar el primero de ellos. El segundo puede usarse cuando se tiene la necesidad de
usar mecanismos más seguros como el caso de CRAM-MD5 o DIGEST-MD5
Ejemplo:
sasl_pwcheck_method: saslauthd
autocreatequota
Esta directiva define el valor en KB del tamaño de la cuota que será aplicado automáticamente a los buzones recién creados. Si
tiene un valor no positivo entonces se asumirá que la cuota es ilimitada.
autocreatequota: 10240
quotawarn
Esta directiva define en qué porcentaje de la cuota de un buzón el sistema Cyrus IMAP empezará a generar advertencias.
Ejemplo:
quotawarn: 90
tls_cert_file
Esta directiva la ruta del archivo de certificado global usado para todos los servicios (POP3, IMAP).
Ejemplo:
tls_cert_file: /etc/cyrus-imapd/mail.newdomains.com-cert.pem
tls_key_file
Esta directiva la ruta de la llave privada que pertenece al certificado global usado para todos los servicios (POP3, IMAP).
Ejemplo:
tls_key_file: /etc/cyrus-imapd/mail.newdomains.com-key.pem
Importante:
Para que el soporte SSL/TLS de POP3 e IMAP sea activado, se requiere habilitar en el archivo /etc/cyrus.conf las líneas siguientes:
Estas han sido algunas de las directivas que comúnmente requieren ser modificadas respecto a sus valores por defecto. La
documentación completa de todas las demás directivas se pueden encontrar en imapd.conf(5).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 386
Source Linux
Iniciando los servicios
Una vez configurados ambos servicios de Cyrus procederemos a iniciarlos.
En Debian y derivados:
En el ejemplo de arriba se especifica al usuario cyrus con el parámetro --user debido a que es esa la cuenta que se configuró
con permisos de administrador en el archivo /etc/imapd.conf. La ejecución de dicho comando nos preguntará una clave que es la
que tiene asignada dicho usuario en el sistema según /etc/passwd.
Una vez que nos autenticamos con la contraseña correspondiente se nos presentará una shell con un prompt en el cual podremos
consultar la ayuda de los comandos disponibles como sigue:
localhost> ?
authenticate, login, auth authenticate to server
chdir, cd change current directory
createmailbox, create, cm create mailbox
deleteaclmailbox, deleteacl, dam remove ACLs from mailbox
deletemailbox, delete, dm delete mailbox
disconnect, disc disconnect from current server
exit, quit exit cyradm
help, ? show commands
info display mailbox/server metadata
listacl, lam, listaclmailbox list ACLs on mailbox
listmailbox, lm list mailboxes
listquota, lq list quotas on specified root
listquotaroot, lqr, lqm show quota roots and quotas for mailbox
reconstruct reconstruct mailbox (if supported)
renamemailbox, rename, renm rename (and optionally relocate) mailbox
server, servername, connect show current server or connect to server
setaclmailbox, sam, setacl set ACLs on mailbox
setinfo set server metadata
setquota, sq set quota on mailbox or resource
version, ver display version info of current server
Algunos comandos los explicamos brevemente por ser los más usados:
lm [patron]
Hace un listado de los buzones que coincidan con un patrón opcional expresado como wildcars.
Ejemplo:
localhost> lm *rios*
lam <patron>
Muestra los permisos de los buzones que coincidan con un patrón opcional expresado como
wildcars. Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 387
Source Linux
para cada usuario
• w (write): el usuario puede modificar los flags excepto Seen y Deleted (los cuales son
controlados por otros permisos)
• i (insert): el usuario puede insertar mensajes en el buzón de correo
• p (post): el usuario puede mandar correo a la dirección de envío del buzón. Este permiso
difiere del permiso i en que el sistema de envío inserta información de seguimiento en
los mensajes envíados
• c (create): el usuario puede crear subcarpetas en el buzón
• d (delete): el usuario puede alterar el flag Deleted, expirar correos y borrar o
renombrar el buzón
• a (administer): el usuario puede cambiar la ACL del buzón
• all (todos): posee todos los permisos anteriores
Ejemplos:
cm <buzón>
Crea un buzón de un usuario determinado. Especificar el separador "." si "unixhierarchysep: no"
o el separador "/" si se usa "unixhierarchysep: yes". Ejemplo:
localhost> cm user.amendoza
localhost> cm user/arengifo
dm <buzón>
Elimina un buzón. Su uso es similar al comando cm. Ejemplo:
localhost> dm user.amendoza
localhost> dm user/arengifo
lq <buzón>
Muestra el estado de la cuota de un buzón especifico. Ejemplo:
localhost> lq user.jchavez
sq <buzón> [numero]
Asigna una cuota en KB a un buzón específico. Si se omite el tamaño de la cuota se asigna
ilimitado. En el primer ejemplo se asigna 15 MB de cuota y en el segundo ejemplo se le da
una cuota ilimitada:
Consideraciones iniciales
El MTA (Mail Transportation Agent) Postfix pretende ser rápido, fácil de administrar y seguro, a la vez que suficientemente
compatible con Sendmail como para que los usuarios existentes no se asusten. Por lo tanto, externamente mantiene el estilo de
Sendmail, mientras que internamente es completamente diferente.
A diferencia de Sendmail, Postfix no es un programa monolítico, sino una combinación de pequeños programas, cada uno de los
cuales lleva a cabo una función especializada. En este documento, el lector encontrará la información necesaria para tener el
sistema funcionando junto a otros componentes que completan la instalación de un sistema de correo electrónico. Puede
encontrarse más información sobre Postfix en la documentación online de su website.
Instalación de Postfix
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 388
Source Linux
primero nos centraremos en este documento.
El archivo /etc/postfix/main.cf contiene las directivas que afectan directamente a las funcionalidades de Postfix dentro de una red, tal
como el dominio de correo que atenderá, las opciones de relay, la autenticación de usuarios para el servicio SMTP, entre otros. Es
por ello que se mostrarán una serie de directivas que suelen ser de las más comunes a la hora de configurar un servidor de envío y
recepción de correos.
mydomain
Esta directiva el nombre de dominio asociado al servidor. Su valor puede ser invocado en otras secciones del archivo de
configuración.
Ejemplo:
mydomain = newdomains.com
myhostname
Esta directiva define el nombre del servidor usado para el funcionamiento normal en los diálogos SMTP.
Ejemplos:
myhostname = mail.newdomains.com
myhostname = mail.$mydomain
mydestination
Esta directiva define una lista de dominios que serán aceptados por el servidor como destino final válido
Ejemplo:
myorigin
Esta directiva permite definir el dominio desde el cual se aparenta que se originan los correos enviados a través del servidor.
Ejemplo:
myorigin = newdomains.net
mynetworks
Esta directiva define las direcciones de red que se consideran de mayor confianza que otros clientes externos. Por lo general a los
clientes que coinciden con estas redes se les permite el relay a través del servidor.
Ejemplo:
alias_maps
Esta directiva define la fuente de alias para los buzones de correo del servidor.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 389
Source Linux
alias_maps = hash:/etc/aliases
Otros tipos posibles de fuentes además de archivos indexados puede ser obtenida de la salida del comando postconf -m y el
uso de cada uno de esos tipos puede ser estudiado en postconf(1).
mailbox_transport
Esta directiva define un agente externo que se encargará de la entrega de los mensajes hacia el buzón correspondiente de los
usuarios.
En el siguiente ejemplo se indica la ruta del socket de Cyrus IMAP el mismo que se define en el archivo /etc/cyrus.conf debido a que
en este documento se asume la integración de Postfix con Cyrus IMAP:
mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
smtpd_sasl_auth_enable
Esta directiva permite activar la autenticación SMTP para los usuarios a la hora de intentar enviar correos a través del servidor.
Ejemplo:
smtpd_sasl_auth_enable = yes
header_checks
Esta directiva define la fuente desde la cual se leen una serie de condiciones y acciones a tomar sobre las cabeceras de los
mensajes de correo una vez que son recibidos por el servidor pero aún no enviados al buzón de los usuarios.
En el siguiente ejemplo se le dice a Postfix que cualquier mensaje recibido (saliente o entrante) sea automáticamente enviado a la
cola hold del sistema de modo tal que se quede por así decirlo estancado para que luego MailScanner lo recoja, analice y envíe
según su destino ya definido.
header_checks = regexp:/etc/postfix/header_checks
/^Received:/ HOLD
message_size_limit
Esta directiva establece el tamaño máximo en bytes que se Postfix permite recibir.
message_size_limit 20971520
smtpd_helo_required
Esta directiva define si es obligatorio o no que los clientes realicen la fase HELO propia del diálogo SMTP. Muchos spammers
omiten este paso mientras que los servidores de correo legítimos casi nunca lo dejan de lado.
Ejemplo:
smtpd_helo_required = yes
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 390
Source Linux
smtpd_client_restrictions
Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase cliente para poder decidir una acción a
tomar. La fase de cliente analiza la naturaleza del origen de su dirección de red (dirección IP, resolución inversa, etc.).
Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en
blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.
permit_mynetworks
Permite el paso a los clientes que coincidan con $mynetworks
permit_sasl_authenticated
Permite el paso a los clientes autenticados por SMTP
reject_unknown_client
Rechaza a los clientes que no cuenten con una resolución inversa consistente
reject_rbl_client RBL
Rechaza a los clientes que se encuentren en alguna de las listas negras especificadas
En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan
autenticado con un usuario y contraseña válidos, mientras que se rechazará a quienes pertenezcan a alguna lista negra de las
indicadas debajo:
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client list.dsbl.org
smtpd_helo_restrictions
Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase HELO para poder decidir una acción a
tomar. En tal fase se analiza la conformidad de los parámetros usados en el comando HELO dentro del diálogo SMTP.
Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en
blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.
permit_mynetworks
Permite el paso a los clientes que coincidan con $mynetworks
permit_sasl_authenticated
Permite el paso a los clientes autenticados por SMTP
reject_non_fqdn_hostname
Rechaza a quienes usen un nombre no DNS en el HELO tal como: mail, server01, mailer u otros
que carezcan de la sección host.dominio correspondiente. En Postfix 2.3 en adelante la
condición es reject_non_fqdn_helo_hostname
reject_invalid_hostname
Rechaza a quienes usen un nombre DNS (host.dominio) pero con valores inválidos tales como:
1mail.domain.com, mail.new_domain.com, smtp.españa.com u otros que en general no califiquen
como un nombre DNS válido de Internet. En Postfix 2.3 en adelante la condición es
reject_invalid_helo_hostname
reject_unknown_hostname
Rechaza a quienes usen un nombre DNS válido pero inexistente en Internet. En Postfix 2.3 en
adelante la condición es reject_unknown_helo_hostname
En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan
autenticado con un usuario y contraseña válidos o usen nombres DNS válidos en el HELO:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 391
Source Linux
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname
smtpd_sender_restrictions
Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase remitente para poder decidir una acción a
tomar. En tal fase se analiza la conformidad de la dirección de correo usada como remitente en el diálogo SMTP.
Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en
blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.
permit_mynetworks
Permite el paso a los clientes que coincidan con $mynetworks
permit_sasl_authenticated
Permite el paso a los clientes autenticados por SMTP
reject_non_fqdn_sender
Rechaza a quienes usen una forma incorrecta de dirección e-mail como remitente que no cuente
con la sección usuario y dominio respectivo (usuario@dominio).
reject_unknown_sender_domain
Rechaza a quienes usen una dirección e-mail como remitente de un dominio inexistente.
En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail
remitente:
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain
smtpd_recipient_restrictions
Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase del destinatario para poder decidir una acción
a tomar. En tal fase se analiza la conformidad de la dirección de correo usada como destinatario en el diálogo SMTP.
Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en
blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.
Esta fase permite controlar el relay a los clientes ya que es la que define si finalmente el mensaje será enviado o no a su
destinatario final por lo que es donde nunca deberían faltar las restricciones mínimas.
permit_mynetworks
Permite el paso a los clientes que coincidan con $mynetworks
permit_sasl_authenticated
Permite el paso a los clientes autenticados por SMTP
reject_non_fqdn_recipient
Rechaza a quienes usen una forma incorrecta de dirección e-mail como destinatario que no
cuente con la sección usuario y dominio respectivo (usuario@dominio)
reject_unknown_recipient_domain
Rechaza a quienes usen una dirección e-mail como destinatario de un dominio inexistente.
reject_unauth_destination
Rechaza a quienes intenten enviar correo a alguna dirección externa, es decir a un dominio no
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 392
Source Linux
servido por Postfix
En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail
destinatario. Luego que se verifique lo primero el servidor será permisivo con los clientes que coincidan con $mynetworks o se
hayan autenticado por SMTP, y finalmente se protege de ser un relay abierto al rechazar a quienes intenten enviar correo a través
de nuestro servidor a un dominio externo no servido por Postfix a menos que no haya cumplido alguna de las reglas permisivas
anteriores.
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_use_tls
Esta directiva habilita el soporte opcional de TLS/SSL para la comunicación con los clientes. Esto quiere decir que el usuario puede
elegir entre usar o no TLS/SSL para la comunicación entera con el servidor.
Ejemplo:
smtpd_use_tls = yes
smtpd_tls_auth_only
Cuando el soporte de TLS/SSL es opcional (ver directiva anterior) esta directiva permite controlar si se acepta o no la autenticación
en un canal inseguro, es decir no cifrado o sin SSL/TLS.
Ejemplo:
smtpd_tls_auth_only = yes
smtpd_tls_cert_file
Esta directiva define la ruta del archivo de certificado en formato PEM que usará Postfix para conexiones TLS/SSL de los clientes.
Ejemplo:
smtpd_tls_cert_file = /etc/postfix/ssl/mail.newdomains.com-cert.pem
smtpd_tls_key_file
Esta directiva define la ruta de la llave privada del certificado que usará Postfix para conexiones TLS/SSL de los clientes.
Ejemplo:
smtpd_tls_key_file = /etc/postfix/ssl/mail.newdomains.com-key.pem
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 393
Source Linux
loglevel: 3
Estas líneas de configuración le dice a Postfix que los mecanismos válidos a aceptar de los clientes son PLAIN y LOGIN a través
del método saslauthd que representa al demonio del mismo nombre.
Definitivamente estas no son todas las directivas de configuración de Postfix ni mucho menos, pero la documentación sobre la gran
mayoría de ellas puede ser encontrada en postconf(5) a donde el lector debería dirigirse a fin de complementar el estudio de
algunas características específicas de su interés no cubiertas en este documento.
Administración de Postfix
A continuación se entrará en el estudio de algunas operaciones comunes de caracter administrativo que son importantes para dar
mantenimiento al servidor.
Una de estas operaciones implica el manipular el estado del MTA y verificar la correcta configuración una vez que se encuentra en
marcha. Para ello nos basaremos en el comando postfix el cual recibe algunos parámetros como los descritos a continuación:
check
Comprueba la conformidad de los permisos y propietarios de ciertos archivos/directorios así como también su
existencia
start
Inicia el MTA con un previo chequeo igual que el descrito arriba
stop
Detiene el MTA de manera correcta y ordenada
abort
Detiene el MTA de manera abrupta e inmediata
reload
Relee su archivo de configuración haciendo efectivo los cambios del mismo
flush
Intenta enviar todos los mensajes que han sido encolados por errores previos diversos puestos en la cola
deferred
Así el siguiente ejemplo hará un chequeo general a la consistencia de archivos/directorios respecto a sus permisos y luego hará
efectivo los cambios realizados al archivo de configuración:
# postfix check
# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
Si el estado del MTA es correcto respecto a su configuración y entorno de trabajo con archivos y directorios no está de más poder
verificar el estado de la cola de mensajes siendo esto posible con el comando mailq:
# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
A4EEC67D06B 16238 Sat Sep 1 05:06:13 sunilb@ajantapharma.com
(host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply to
RCPT TO command))
info@newdomains.com
-- 20 Kbytes in 3 Requests.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 394
Source Linux
En el ejemplo anterior se aprecia 3 mensajes encolados, aparentemente los buzones a los que se intentaba enviar mensajes en el
dominio newdomains.com se han excedido en su cuota. Para ello sería de utilidad aumentar la cuota de dichos buzones en Cyrus y
luego ejecutar postfix flush.
Entre otra de las operaciones administrativas podemos encontrar el mantenimiento de los alias del sistema de correo que
permitirán crear distintos nombres para uno o más buzones en particular así como crear grupos simples de distribución. Para ello
ha de modificarse el archivo /etc/aliases el cual tiene la siguiente forma:
La primera columna indica el nombre del alias, es decir el nombre del buzón al que originalmente estaba destinado un mensaje, y
los valores especificados a la derecha indican los destinos reales a los cuales se enviará el mensaje de correo.
En el siguiente ejemplo se crea una serie de alias imprescindibles los cuales son destinados finalmente al usuario root:
postmaster: root
abuse: root
mailer-daemon: root
hostmaster: root
webmaster: root
noc: root
En el ejemplo anterior se crean alias individuales destinados cada uno al usuario root solamente. Pero también es posible crear
grupos que se asemejen a listas de distribución en el cual un alias permitirá enviar una copia del mensaje a más de un usuario del
sistema tal como se aprecia debajo:
Una vez que se hayan realizado los cambios correspondientes en el archivo de alias se requiere regenerar a partir de éste una
versión indexada del mismo el cual será el que Postfix use en realidad por motivos de mejor desempeño. Este archivo indexado por
lo general será "/etc/aliases.db" y se actualiza con cualquiera de los dos comandos mostrados a continuación:
# postmap hash:/etc/aliases
# newaliases
Una vez que ha sido compilado y actualizado nuevamente el archivo de alias se necesita recargar Postfix como sigue:
# postfix reload
Finalmente como es normal en la administración de cualquier servicio el monitoreo de los logs es siempre una labor de gran
importancia. Para esto se tiene que el registro de actividad de Postfix suele ser almacenado en archivos como /var/log/maillog, /var/
log/mail.log, /var/log/mail u otro archivo similar dependiendo de la distribución Linux con la que se trabaje, el cual debe ser
constantemente vigilado como sigue:
# tail -f /var/log/mail.log
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 395
Source Linux
19.3. Filtro de contenidos, Antispam, Antivirus
Componentes necesarios
La configuración de un servidor de mensajería no sería completo si no cuenta con alguna herramienta de filtro de contenidos, la misma
que permita reducir en gran medida los correos no deseados tal como aquellos infectados por algún virus o los que contengan algún
tipo de publicidad no solicitada comúnmente conocido como Spam.
Es por ello que se requiere la instalación de un filtro de contenidos como MailScanner el cual se encargará de analizar cada correo
entrante y saliente bajo ciertas reglas que el administrador lo configure previamente.
MailScanner no es una herramienta que directamente analice y desinfecte virus, ni tampoco detecte Spam, sino son ClamAV y
SpamAssassin los que realizan dichas labores respectivamente.
Sin embargo MailScanner se encargará de tomar cada correo de la cola de Postfix y evaluarlo bajo una lista de condiciones y de ser
necesario invocará a SpamAssassin y/o ClamAV para completar su análisis, pudiendo luego opcionalmente tomar acciones como
eliminar el mensaje, enviarlo a una cuarentena o enviarlo al destinatario final.
Respecto a ClamAV podemos agregar nada más que nos basaremos en su configuración por defecto y debemos asegurarnos que su
demonio respectivo se encuentre iniciado.
Instalación de MailScanner
MailScanner puede ser descargado desde su Web oficial:
http://www.mailscanner.info
En este en la sección Downloads existen paquetes para distribuciones Red Hat, SuSE y derivados. Todos estos paquetes son un
tarball el cual debe ser descomprimido y desde adentro ejecutar el script install.sh como sigue:
Este script se encargará de hacer todo el trabajo de instalación y configuración predeterminada de MailScanner en el sistema,
colocando normalmente los binarios y otras librerías debajo de /usr y la configuración debajo de /etc/MailScanner.
Sin embargo si descargó el paquete MailScanner de la versión "Solaris / BSD / Other Linux / Other Unix" se tendrá que la
instalación de manera predeterminada se hará debajo del directorio /opt/MailScanner. Asimismo se debe contemplar el hecho de
crear uno mismo su script SySV en /etc/init.d para iniciar MailScanner desde su directorio de instalación.
Configurando MailScanner
El archivo de configuración por defecto suele ser ubicado en /etc/MailScanner/MailScanner.conf. A continuación la descripción de
directivas de MailScanner:
%org-name%
Esta directiva define simplemente un nombre de la organización la cual administra el servicio. No debe contener espacios en
blanco.
Ejemplo:
%org-name% = NewDomains
%org-long-name%
Esta directiva define un nombre largo de la organización el mismo que aparecerá como parte de la firma en los reportes generados
por MailScanner. Puede contener espacios en blanco.
Ejemplo:
%web-site%
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 396
Source Linux
Esta directiva define el sitio Web de la organización, el mismo que se muestra junto con el nombre largo de la organización como
parte de la firma de algunos reportes.
Ejemplo:
%web-site% = http://www.newdomains.com
%report-dir%
Esta directiva define la ruta del directorio que contiene los reportes de MailScanner. Por lo general existe un directorio por cada
idioma soportado y esta directiva pretende definir el idioma de los reportes.
Ejemplo:
%report-dir% = /etc/MailScanner/reports/es
Run As User
Run As Group
Estas directivas definen el usuario y grupo bajo el cual se ejecutará MailScanner.
Ejemplo:
Ejemplo:
Ejemplo:
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 397
Source Linux
Incoming Work Dir = /var/spool/MailScanner/incoming
Quarantine Dir
Esta directiva define la ruta del directorio de la cuarentena de MailScanner.
Ejemplo:
MTA
Esta directiva define cuál es el MTA que se integrará con MailScanner. Su valor debe ser postfix, sendmail, exim o zmailer
Ejemplo:
MTA = postfix
Ejemplo:
Quarantine User
Quarantine Group
Quarantine Permissions
Esta directiva define los propietarios y permisos del directorio de la cuarentena de MailScanner definido en Quarantine Dir.
A fin de que más adelante MailWatch que es ejecutado a través de Apache sea capaz de modificar los archivos de la cuarentena se
asigna el grupo de ejecución al mismo del proceso Apache, y se configura al usuario postfix como miembro de ese grupo.
Virus Scanning
Esta directiva define si se analizarán o no los correos con un antivirus externo.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 398
Source Linux
Virus Scanning = yes
Virus Scanners
Esta directiva define el antivirus externo a usar. Algunos valores posibles válidos son clamav, sophos, mcafee, etrust, panda,
trend antivir, entre otros.
Ejemplo:
Allow Filenames
Deny Filenames
Esta directiva define qué tipos de archivos se permiten o se deniegan en los correos como adjuntos. Puede tomar como valor las
expresiones regulares que hagan coincidencia con un tipo de archivo.
Ejemplo:
Filename Rules
Esta directiva define la ruta de un archivo donde se establecerán con mayor detalle cada uno de los tipos de archivos permitidos o
denegados de manera similar a las dos directivas anteriores.
Ejemplo:
El archivo al cual se hace referencia debe contener 4 campos de los cuales el primero es la acción a tomar (allow o deny), el
segundo una expresión regular que coincida con el archivo, el tercer campo un mensaje de log y el cuarto campo es un mensaje
que será enviado al destinatario como reporte. Los campos deben estar estrictamente separados por tabulaciones como en el
siguiente ejemplo:
deny pretty\s+park\.exe$ "Pretty Park" virus "Pretty Park" virus found in attachments
Quarantine Infections
Esta directiva decide si se enviarán a cuarentena o no los correos que contengan archivos infectados.
Ejemplo:
Spam Checks
Esta directiva decide si se buscará o no Spam en los mensajes.
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 399
Source Linux
Spam List
Esta directiva define una serie de listas negras de Internet a las cuales se consultará si pertenecen o no las direcciones IP de los
remitentes. Los nombres que se definen en esta directiva están definidos en el archivo /etc/MailScanner/spam.lists.conf.
Ejemplo:
Ejemplo:
Ejemplo:
Ejemplo:
Use SpamAssassin
Esta directiva define si se usará o no a SpamAssassin como herramienta de detección de Spam.
Ejemplo:
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 400
Source Linux
High SpamAssassin Score
Esta directiva define el puntaje mínimo que debe tener un mensaje según la calificación de SpamAssassin para que sea
considerado Spam de nivel alto.
Ejemplo:
Sin embargo MailScanner requerir analizar sólo parte de un mensaje para saber si es spam o no (Ejm: analizar sólo los primeros
200 KB) sin afectar el rendimiento de SpamAsassin. Por esta razón se recomienda que el límite de tamaño que puede analizar
MailScanner sea un valor alto, alrededor de 1 MB o más dependiendo del tamaño de los mensajes de spam que reciba
frecuentemente, mientras que el tamaño máximo de mensajes analizados por SpamAssassin se mantenga bajo o en sus valores
predeterminados.
Ejemplo:
Spam Actions
Esta directiva define la acción a tomar cuando se detecte Spam moderado en un mensaje.
deliver
Entrega el mensaje a su destinatario de manera normal
delete
Elimina el mensaje
store
Almacena una copia del mensaje en la cuarentena
bounce
Envia un mensaje de rechazo al remitente
forward usuario@dominio
Reenvía una copia del mensaje a una cuenta de correo
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 401
Source Linux
Sintaxis : High Scoring Spam Actions = accion
Hasta aquí con el estudio de directivas de MailScanner, que cuenta con un gran número de opciones disponibles para cambiar a
nuestro gusto pero todas las directivas se encuentran muy bien documentadas en su archivo de configuración por lo que resultará
bastante sencillo al lector entenderlas.
19.3.2. Analizador de Spam SpamAssassin
Instalación de SpamAssassin
SpamAssassin está incluido en los repositorios de las principales distribuciones Linux. El procedimiento de instalación es directo
como debajo se indica:
En Debian y derivados:
ok_languages
ok_locales
Esta directiva define la codificación y el idioma preferentemente esperados en los contenidos de los mensajes de correo. Puede ser
útil si se recibe Spam en idiomas que no son los nuestros y sobre todo con codificación de caracteres que no son propios de
nuestra lengua.
Ejemplo:
ok_languages es en
ok_locales es en
use_bayes
Esta directiva permite activar el motor Bayesiano que en base a métodos estadísticos clasificará los mensajes como Spam.
Ejemplo:
use_bayes 1
bayes_auto_learn
Esta directiva permite que SpamAssassin aprenda de manera automáticamente cuando un mensaje es o no Spam en base a las
estadísticas bayesianas.
Ejemplo:
bayes_auto_learn 1
bayes_path
Esta directiva define el prefijo de los archivos de Bayes que se crearán durante el tiempo de funcionamiento.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 402
Source Linux
En el siguiente ejemplo se crearán los archivos de bayes con un prefijo de nombre "bayes" en el directorio /etc/MailScanner/bayes.
Tenga cuidado que /etc/MailScanner/bayes/bayes no es ni debe ser un directorio.
bayes_path /etc/MailScanner/bayes/bayes
bayes_file_mode
Esta directiva define los permisos de los archivos de Bayes.
Ejemplo:
bayes_file_mode 0660
Plugins de SpamAssassin
SpamAssassin es capaz de extender la funcionalidad que por defecto incluye a través del uso de plugins, los mismos que pueden
ser activados (los que vienen por defecto con SpamAssassin) o descargados algún sitio Web publicado por terceros.
En la Web de SpamAssassin se puede encontrar una lista de plugins personalizados de diferentes licencias (gratuitos, licencia
Apache, comerciales de pago, etc), bajo la siguiente URL:
http://wiki.apache.org/spamassassin/CustomPlugins
Estos plugins tras ser descargados, deben ser colocados en el directorio /etc/mail/spamassassin. Los plugins por lo general serán
archivos de extensión .pm y sus directivas de configuración se guardan en archivos de extensión .cf.
Es recomendable habilitar algunos plugins:
• TextCat : Habilita la identificación de idiomas. Si se habilitan las directivas ok_languages y/o ok_locales en
/etc/MailScanner/spam.assassin.prefs.conf se requiere habilitar este plugin.
Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::TextCat en el archivo
/etc/mail/spamassassin/v310.pre.
• SPF : Habilita la validación SPF de los dominios de los remitentes. Para habilitarlo se debe descomentar la línea
loadplugin Mail::SpamAssassin::Plugin::SPF en el archivo /etc/mail/spamassassin/init.pre.
• DCC : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos
DCC. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::DCC en el
archivo /etc/mail/spamassassin/v310.pre.
DCC se puede obtener descargar desde http://www.rhyolite.com/dcc/ y tras ser compilado e instalado, se debe definir
en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta del binario del comando dccproc como sigue:
ifplugin Mail::SpamAssassin::Plugin::DCC
dcc_path /usr/local/bin/dccproc
endif
• Razor2 : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos
Razor. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::Razor2 en el
archivo /etc/mail/spamassassin/v310.pre.
Razor2 se puede obtener descargar desde http://razor.sourceforge.net/ y tras ser compilado e instalado, se debe
definir en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta de configuración de razor como sigue:
use_razor2 1
razor_config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf
Razor2 debe crear el archivo de configuración con el comando razor-admin como sigue:
# mkdir -p /var/spool/MailScanner/spamassassin/razor
# razor-admin -create -config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf
# chown -R postfix:mail /var/spool/MailScanner/spamassassin
• Relayed By Dialup : Habilita el análisis de los remitentes de correo para evaluar si provienen desde direcciones IP
públicas fijas o dinámicas (conexiones caseras del tipo ADSL o Diaulp).
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 403
Source Linux
Este plugin debe ser descargado desde el sitio Web de Spamassassin donde se publican los plugins personalizados (link
líneas arriba mostrado).
Existen otros plugins que pueden ser instalador y habilitados a criterio del administrador. Entre ellos existen algunos que analizan
archivos PDF (plugin PDFassassin), análisis de spam en imágenes (plugin Fuzzy OCR), y otros.
Muchos de estos plugins tras ser habilitados puede que requieran cumplir algunas dependencias de paquetes antes de poder
funcionar correctamente. Para poder averiguar si existen dependencias incumplidas de los plugins de SpamAssassin se puede
ejecutar lo siguiente:
Este comando nos arroja una salida extensa de la cual requerimos filtrar el texto 'not installed' para identificar los módulos de Perl
no instalados y requeridos como dependencia:
En el ejemplo arriba mostrado se puede apreciar que los siguientes módulos no están instalados:
• Mail::SPF::Query
• IP::Country::Fast
• Net::Ident
• IO::Socket::SSL
• Mail::DomainKeys
• Mail::DKIM
http://search.cpan.org
Donde podremos utilizar el buscador para cada uno de los módulos con palabras clave como 'Mail SPF Query', 'IP Country Fast',
'Net Ident' y así con el resto.
Cada uno de estos módulos de Perl se encuentran publicados como tarballs los cuales deben ser instalados bajo un procedimiento
general como el siguiente:
Es necesario observar con atención la salida del comando perl Makefile.PL ya que éste puede advertir de la ausencia de
otros módulos de Perl que son necesarios tener instalados antes de la compilación del módulo de nuestro interés.
1. En Red Hat / CentOS y derivados : Se requiere tener configurado el repositorio de DAG (http://dag.wieers.com) y ejecutar
desde la línea de comandos lo siguiente:
3. Descargar desde el sitio oficial de ClamAV (http://www.clamav.net) los instaladores para la distribución Linux que tengamos e
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 404
Source Linux
instalar los paquetes de manera individual:
# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
Luego empezaremos a probar un diálogo SMTP con el servidor para enviarle un mensaje sencillo desde comandos telnet:
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.newdomains.com ESMTP
HELO gsmtp163.google.com
250 mail.newdomains.com
MAIL FROM: <angelrengifo@gmail.com>
250 2.1.0 Ok
RCPT TO: <postmaster@newdomains.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Mensaje de Prueba
.
250 2.0.0 Ok: queued as CD4A267D083
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Luego de eso debería haber entrado un nuevo mensaje en la cola de Postfix y éste pasarlo luego a MailScanner. Veamos algunas
líneas de los logs:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 405
Source Linux
Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function
MailWatchLogging
Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLWhitelist
Sep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam whitelist
Sep 2 18:38:10 localhost MailScanner[16132]: MailScanner child dying of old age
Sep 2 18:38:10 localhost cyrus/master[17799]: about to exec /usr/lib/cyrus/bin/lmtpd
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: executed
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: accepted connection
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: lmtp connection preauth'd as postman
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 0
Sep 2 18:38:10 localhost MailScanner[17800]: MailScanner E-Mail Virus Scanner version 4.55.10
starting...
Sep 2 18:38:10 localhost MailScanner[17800]: Read 748 hostnames from the phishing whitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLBlacklist
Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Blacklist
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 0
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: starting txn 2147485203
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: committing txn 2147485203
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_mark:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 1188776290 47597596182714
Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 blacklist entries
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function
MailWatchLogging
Sep 2 18:38:10 localhost MailScanner[17800]: Started SQL Logging child
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLWhitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Whitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 whitelist entries
Sep 2 18:38:10 localhost MailScanner[17800]: Using SpamAssassin results cache
Sep 2 18:38:10 localhost MailScanner[17800]: Connected to SpamAssassin cache database
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: Delivered:
<20070902233801.077FA67D087@mail.newdomains.com> to mailbox: user.root
Sep 2 18:38:10 localhost postfix/lmtp[17798]: 0BD5867D088: to=<root@newdomains.com>,
orig_to=<postmaster@newdomains.com>, relay=mail.newdomains.com[/var/run/cyrus/socket/lmtp],
delay=17, delays=16/0.01/0.02/0.39, dsn=2.1.5, status=sent (250 2.1.5 Ok)
Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: removed
Sep 2 18:38:10 localhost MailScanner[17800]: Enabling SpamAssassin auto-whitelist
functionality...
Sep 2 18:38:11 localhost MailScanner[17800]: Using locktype = flock
En medio de la gran cantidad de líneas puede apreciarse cual es el remitente (MAIL FROM) y el destinatario (RCPT TO), así como
también como MailScanner analiza su contenido y finalmente lo devuelve a Postfix para finalmente entregarlo a Cyrus IMAP.
Una forma alternativa de enviar un correo desde la línea de comandos con el mismo resultado que el anterior es como sigue:
Finalmente podemos probar el correcto funcionamiento de la autenticación y el servicio IMAP como sigue:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 406
Source Linux
* 3 FETCH (BODY[TEXT] {6}
Hola
)
. OK Completed (0.000 sec)
w
* BYE LOGOUT received
. OK Completed
Connection closed by foreign host.
Con esto ya se tiene un sistema de correo con los servicios SMTP, POP e IMAP protegidos por un filtro de contenidos como
MailScanner trabajando en conjunto con SpamAssassin y ClamAV.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 407
Source Linux
19.4. Webmail y monitoreo
19.4.1. Monitoreo con MailWatch
Requerimientos
MailWatch es una aplicación Web escrita sobre PHP capaz de generar gráficas estadísticas obtenidas desde una base de datos
MySQL. Como tal requerirá que se instale lo siguiente:
✔ Apache 2.x
✔ PHP 5
✔ La librería GD
✔ MySQL Server 5.0
En Debian y derivados:
Una vez que se tengan instalados dichos componentes debe procederse a ajustar algunos parámetros de configuración de PHP en
el archivo php.ini (/etc/php.ini en Red Hat / CentOS y derivados, o /etc/php5/apache2/php.ini en Debian) correspondiente a cada
distribución Linux, como se muestra a continuación:
short_open_tag = On
safe_mode = Off
register_globals = Off
magic_quotes_gpc = On
magic_quotes_runtime = Off
session.auto_start = 0
Luego de ello haremos los cambios efectivos en el servicio Apache y nos aseguraremos que el servicio MySQL esté correctamente
iniciado también.
Instalación y configuración
La instalación de MailWatch es un proceso que consta de varios pasos bastante sencillos. Debemos primero obtener el tarball
correspondiente desde su sitio oficial en Internet:
http://mailwatch.sourceforge.net
# wget http://ufpr.dl.sourceforge.net/sourceforge/mailwatch/mailwatch-x.y.z.tar.gz
# tar zxf mailwatch-x.y.z.tar.gz -C /tmp
# cd /tmp/mailwatch-x.y.z
Una vez dentro del directorio de la distribución de MailWatch crearemos la base de datos necesaria:
Luego debemos asignar los privilegios correspondientes para las operaciones en la base de datos a un usuario como se muestra
debajo:
# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.0.32-Debian_7etch1-log Debian etch distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 408
Source Linux
Es entonces que debemos hacer la primera modificación a la base de datos recién creada para crear así un usuario con privilegios
de Administración en la interfaz Web de MailWatch:
Luego dentro del directorio de la distribución de MailWatch se encontrarán los archivos MailWatch.pm y SQLBlackWhiteList.pm los
cuales tendremos que editar para cambiar los parámetros de conexión a la base de datos tal como el usuario (mailwatch) y
contraseña ('clave' en los ejemplos de arriba).
# MailWatch.pm
...
...
...
# SQLBlackWhiteList.pm
...
...
...
sub CreateList {
my($type, $BlackWhite) = @_;
my($dbh, $sth, $sql, $to_address, $from_address, $count);
my($db_name) = 'mailscanner';
my($db_host) = 'localhost';
my($db_user) = 'mailwatch';
my($db_pass) = 'clave';
Estos archivos permiten integrar MailScanner con MailWatch. MailWatch.pm guarda un registro de cada mensaje de correo que
analiza MailScanner así como también la cuarentena, mientras que SQLBlackWhiteList.pm permite guardar listas blancas y negras
personalizadas.
Dentro del directorio de la distribución de MailWatch se encuentra el directorio mailscanner/ el mismo que procederemos a colocar
en una ruta servida por Apache, y haremos algunos ajustes de permisos para que el usuario bajo el cual se ejecuta Apache sea
capaz de escribir a fin de cumplir con sus labores:
# cp -r mailscanner /var/www
# cd /var/www/mailscanner
# mkdir temp
# chown -R .www-data temp images
# chmod -R g+w temp images
# cp conf.php.example conf.php
Si se aprecia arriba se hizo una copia del archivo conf.php.example a conf.php siendo éste último el cual modificaremos como sigue:
# conf.php
...
...
...
define(DB_TYPE, 'mysql');
define(DB_USER, 'mailwatch');
define(DB_PASS, 'clave');
define(DB_HOST, 'localhost');
...
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 409
Source Linux
...
// Paths
define(MAILWATCH_HOME, '/var/www/mailscanner');
define(MS_CONFIG_DIR, '/etc/MailScanner/');
Finalmente debemos hacer algunos cambios en el archivo de configuración de MailScanner para culminar el proceso de instalación
de MailWatch, como se muestra a continuación:
Luego simplemente debemos reiniciar MailScanner para que los cambios se hagan efectivos y a través de un navegador acceder a
la URL del MailWatch que es la siguiente:
http://servidor/mailscanner
Al intentar ingresar a dicha URL se nos pedirá autenticación y debe ingresarse el usuario y clave insertados en la base de datos
anteriormente (usuario 'admin' y clave 'clave-mailwatch').
Requerimientos
La instalación de Horde requiere básicamente un servidor MySQL y Apache con soporte PHP. Pero PHP en la mayoría de
distribuciones viene repartido en una serie de paquetes independientes que incluyen el soporte para la integración con diferentes
tecnologías como LDAP, IMAP, gd, gettext, MySQL, entre otros. Los siguientes son nombres de paquetes referenciales que se
consideran necesarios:
✔ mysql-server
✔ apache2
✔ php5
✔ php-pear
✔ php5-mysql
✔ php5-imap
✔ php5-gettext
✔ php5-gd
En Debian y derivados:
El paquete php-pear a la vez incluye el soporte para ciertas funcionalidades que no están incluidas en su versión predeterminada
de las distribuciones Linux por lo que se requiere instalar lo faltante:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 410
Source Linux
Luego ya se debe encontrar listo el sistema para iniciar la configuración de Horde.
Instalación y configuración
Horde es un Webmail completo y modular cuyo sitio oficial en Internet es:
http://www.horde.org
Horde actualmente posee una serie de módulos que agregan funcionalidades diversas siendo algunas de ellas las siguientes:
• horde: El framework
• imp: El cliente IMAP para leer los buzones de correo
• mimp: El cliente IMAP para leer los buzones de correo hecho para dispositivos móviles
• vacation: Las respuestas automáticas de fuera de oficina
• forward: La redirección de mensajes a otra cuenta de correo
• turba: La libreta de direcciones
• passwd: El módulo de cambio de contraseñas
• nag: Las tareas de usuario
• mnemo: Las notas personales
• kronolith: El calendario de actividades
• gollem: El disco duro virtual
• ingo: Los filtros personalizados de correos
http://ftp.horde.org/pub
El proceso de instalación de cada uno de los módulos es bastante sencillo. En este documento se cubrirá la instalación del
framework base Horde y el módulo IMP pero el lector puede seguir los mismos pasos para instalar cualquiera de los módulos
adicionales que le interese.
# wget http://ftp.horde.org/pub/horde/horde-x.y.z.tar.gz
# wget http://ftp.horde.org/pub/imp/imp-x.y.z.tar.gz
Dentro de cada módulo existe un directorio config/ en el cual centraremos nuestra atención para realizar los ajustes necesarios.
Empezamos por generar los archivos de configuración a partir de los archivos de ejemplo incluidos por defecto en la distribución de
los paquetes:
# cd /var/www/horde/config
# for i in *.dist; do cp $i $(basename $i .dist); done
# cd /var/www/horde/imp/config
# for i in *.dist; do cp $i $(basename $i .dist); done
Luego es necesario que se asignen ciertos permisos de escritura al usuario de Apache sobre los directorios config/:
De este modo ya sabemos que Apache será capaz de modificar los archivos que existan dentro de los directorios config/ así como
también poder crear otros tantos nuevos.
Es necesario ahora ajustar el archivo de configuración imp/config/servers.php para que el proceso de autenticación se realice hacia
el servidor adecuado:
$servers['_prompt'] = array(
'name' => _("Choose a mail server:")
);
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 411
Source Linux
/* Example configurations: */
$servers['cyrus'] = array(
'name' => 'Servidor IMAP',
'server' => 'mail.newdomains.com',
'hordeauth' => false,
'protocol' => 'imap/notls',
'port' => 143,
'maildomain' => 'newdomains.com',
'smtphost' => 'mail.newdomains.com',
'smtpport' => 25,
'realm' => '',
'preferred' => '',
'admin' => array(
'params' => array(
'login' => 'cyrus',
'password' => 'abc123',
// The 'userhierarchy' parameter defaults to 'user.'
// If you are using a nonstandard hierarchy for personal
// mailboxes, you will need to set it here.
'userhierarchy' => 'user.',
// Although these defaults are normally all that is required,
// you can modify the following parameters from their default
// values.
'protocol' => 'imap/notls',
'hostspec' => 'localhost',
'port' => 143
)
),
'quota' => array(
'driver' => 'cyrus',
'params' => array(),
),
'acl' => array(
'driver' => 'rfc2086',
),
);
En el recuadro de arriba se muestra un ejemplo de las primeras líneas de configuración del archivo imp/config/servers.php y Ud.
apreciará que existirán muchas instancias del tipo $server['nombre'] como por ejemplo $server['imap'],
$server['pop'], $server['exchange'], entre otros de donde Horde leerá la que se encuentre primera dentro del archivo
siendo en nuestro caso la sección $server['cyrus'].
Los valores que deben ser cambiados dentro de la sección $server['cyrus'] son los que están remarcados con negrita y algún
otro adicional que sea de interés del lector. Además se recalca que las líneas 'login' => 'cyrus' y 'password' =>
'abc123' representan los datos de inicio de sesión del usuario con privilegios de administrador en Cyrus IMAP (el usuario
especificado en la directiva admins:).
# cd /var/www/horde/scripts/sql
# mysql < create.mysql.sql
Ahora es tiempo ya de acceder a la segunda parte de la configuración de Horde pero esta vez a través de la interfaz Web,
accediendo por la URL:
http://servidor/horde
Apenas se ingrese a la URL indicada apreciarán que ya han iniciado sesión y tienen acceso a un menú en la parte izquierda donde
una de las entradas lleva el nombre "Administration" y se empezará a proceder como indica los siguientes pasos:
Sobre IMP:
Ir a 'Administration -> Setup' y dar clic sobre el módulo 'Imp' en la parte derecha. Dentro de tal categoría se pueden
ajustar algunas características y valores predeterminados para todos los usuarios, para luego finalizar la configuración de IMP
dando clic en 'Generate Mail Configuration'.
Sobre Horde:
Ir a 'Administration -> Setup' y dar clic sobre el módulo 'Horde' en la parte derecha. Dentro de tal categoría se pueden
ajustar algunas características y valores predeterminados para todos los usuarios de las que se requiere mínimamente las
siguientes:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 412
Source Linux
1. En la pestaña 'Authentication' completar como sigue los campos del formulario:
Which users should be treated as administrators (root, super-user) by Horde?: (rellenar con un usuario)
What backend should we use for authenticating users to Horde?: Let a Horde application handle authentication
The application which is providing authentication: imp
Los campos de los formularios que no son mencionados pueden ser tranquilamente dejados con los valores predeterminados.
Finalmente dar clic en 'Generate Horde Configuration', donde se apreciará que el sistema ya ha cerrado sesión y será
necesario que se se indique un nombre de usuario y contraseña correspondiente para poder acceder al sistema Horde.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 413
Source Linux
Unidad 20: Virtualización Open Source
20.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Conocer los conceptos básicos de virtualización de sistemas operativos y las técnicas más comunes existentes.
✔ Instalación y configuración básica de Xen para implementar máquinas virtuales (guests).
✔ Conocer las tareas rutinarias de administración de máquinas virtuales con Xen.
Virtualización
En informática, virtualización se refiere a la abstracción de los recursos de una computadora, llamada Hypervisor o VMM (Virtual
Machine Monitor) que crea una capa de la abstracción entre el hardware de la maquina física (host) y el sistema operativo de la
maquina virtual (virtual machine, guest)., siendo un medio para crear una versión virtual de un dispositivo o recurso, como un
servidor, un dispositivo de almacenamiento, una red o incluso un sistema operativo, donde se divide el recurso en uno o más
entornos de ejecución.
Esta capa de software (VMM) maneja, gestiona y arbitra los cuatro recursos principales de una computadora (CPU, Memoria, Red,
Almacenamiento) y así podrá repartir dinámicamente dichos recursos entre todas las maquinas virtuales definidas en el
computador central. De modo que nos permite tener varios ordenadores virtuales ejecutándose sobre el mismo ordenador físico.
Tal término es antiguo; se viene usando desde 1960, y ha sido aplicado a diferentes aspectos y ámbitos de la informática, desde
sistemas computacionales completos, hasta capacidades o componentes individuales. Lo mas importante en este tema de
virtualización es la de ocultar detalles técnicos a través de la encapsulación.
La virtualización se encarga de crear un interfaz externo que esconde una implementación subyacente mediante la combinación de
recursos en locaciones físicas diferentes, o por medio de la simplificación del sistema de control. Un avanzado desarrollo de
nuevas plataformas y tecnologías de virtualización han hecho que se vuelva a prestar atención a este importante concepto. De
modo similar al uso de términos como “abstracción” y “orientación a objetos”, virtualización es usado en muchos contextos
diferentes.
Este concepto que es realmente interesante y que se lleva desarrollando desde hace muchos años, parece que finalmente está
encontrando sus caminos productivos y de desarrollo para profesionales.
La maquina virtual en general es un sistema operativo completo que corre como si estuviera instalado en una plataforma de
hardware autónoma. Típicamente muchas máquinas virtuales son simuladas en un computador central. Para que el sistema
operativo “guest” funcione, la simulación debe ser lo suficientemente grande (siempre dependiendo del tipo de virtualización)
El único y pequeño inconveniente es que necesitamos un gestor de arranque que al encender nuestro ordenador nos de la opción
de elegir que sistema operativo queremos utilizar, lo que conlleva a que si por ejemplo estamos en Windows y queremos cambiar a
Linux deberíamos reiniciar nuestro ordenador. La virtualización por el contrario permite cambiar de sistema operativo como si se
tratase de cualquier otro programa, sin embargo, esta agilidad tiene la desventaja de que un sistema operativo virtualizado no es
tan potente como uno que ya estuviera instalado.
Ventajas de la virtualización
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 414
Source Linux
• Reduce los tiempos de parada.
• Migración en caliente de máquinas virtuales (sin pérdida de servicio) de un servidor físico a otro, eliminando la necesidad
de paradas planificadas por mantenimiento de los servidores físicos.
• Balanceo dinámico de máquinas virtuales entre los servidores físicos que componen el pool de recursos, garantizando
que cada máquina virtual ejecute en el servidor físico más adecuado y proporcionando un consumo de recursos
homogéneo y óptimo en toda la infraestructura.
• Alto grado de satisfacción general
• Host : También conocido como anfitrión. Es el sistema que sirve de base para la ejecución de las máquinas virtuales.
• Guest : También definido como huésped. Se define así al sistema que es virtualizado (máquina virtual) sobre un host.
• Hypervisor : Un hipervisor (en inglés hypervisor) o monitor de máquina virtual (virtual machine monitor) es una
plataforma de virtualización que permite utilizar, al mismo tiempo, diferentes sistemas operativos (sin modificar o
modificados en el caso de paravirtualización) en una misma computadora. Es una extensión de un termino anterior,
“supervisor”, que se aplicaba a kernels de sistemas operativos.
Existen dos tipos de hypervisor:
Hypervisor de nivel 1
También denominado nativo, unhosted o sobre el metal desnudo (bare metal), es software que se ejecuta
directamente sobre el hardware, para ofrecer la funcionalidad descrita.
Hypervisor de nivel 2
También denominado hosted, es software que se ejecuta sobre un sistema operativo para ofrecer la funcionalidad
descrita.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 415
Source Linux
20.2.2 Técnicas de virtualización
Las siguientes son las técnicas de virtualización más comunes que existen:
Es dentro de esta aplicación de virtualización que una o más máquinas virtuales se crean para ejecutar los sistemas operativos
guest en el equipo host. La aplicación de virtualización es la responsable de iniciar, detener y administrar cada máquina virtual y,
esencialmente, controlar el acceso a los recursos de hardware físico en nombre de las máquinas virtuales individuales.
La también aplicación de virtualización también se involucra en un proceso conocido como traducción que implica el análisis de la
secuencia de instrucciones del sistema guest en ejecución reemplazando las instrucciones privilegiadas con emulaciones
seguridas de las mismas sobre el equipo host.
Esto genera el efecto de hacer creer al sistema guest que está corriendo directamente en el hardware en lugar de una máquina
virtual dentro de una aplicación.
Algunos ejemplos de tecnologías de virtualización de Sistema operativo guest incluyen VMware Server y VirtualBox.
Como se muestra en la imagen superior, los sitemas guest trabajan en máquinas virtuales dentro de la aplicación de virtualización,
la cual corre sobre el sistema host como lo hace cualquier otra aplicación (Ejm: Mozilla Firefox, Microsoft Word, etc).
Estas múltiples capas de abstracción entre el sistema guest y el sistema host que hay debajo no conducen a buenos niveles de
rendimiento de las máquinas virtuales.
Sin embargo esta técnica tiene la ventaja que no hay requerimientos específicos que cumplir sobre el guest o host, ni tampoco se
necesitan características específicas del CPU (Ejm: soporte de virtualización en el procesador. Intel VT o AMD-V)
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 416
Source Linux
Virtualización con kernel compartido
Conocido también como virtualización a nivel de sistema operativo. Esta técnica toma ventaja del diseño estructural de los
sistemas UNIX y Linux. Para entender la virtualización con kernel compartido se requiere entender la función de dos componentes
principales de estos sistemas.
Uno de estos componentes es el kernel, que es el corazón de un sistema operativo. El kernel en términos simples se encarga de
manejar toda la interacción entre el sistema operativo y el hardware sobre el cual correo.
El otro componente es el sistema de archivos raíz, el cual contiene todas las librerías, archivos y utilitarios necesarios para que
funcone el sistema operativo.
En un esquema de virtualización con kernel compartido cada sistema guest tiene su propio sistema de archivos raíz pero
comparten el kernel que ejecuta el sistema host. La estructura de este modo de virtualización se muestra debajo:
Este tipo de virtualización es posible gracias a la habilidad del kernel de cambiar dinámicamente el sistema de archivos raíz actual
(concepto conocida como chroot) hacia otro sistema de archivos raíz diferente sin la necesidad de reiniciar el sistema entero. Es
así que la virtualización con kernel compartido es una extensión a esta capacidad.
Quizás el impacto adverso más grande que genera esta técnica de virtualización es el hecho que los sistemas guest deben ser
compatibles con la versión del kernel (del host) que están compartiendo. Es así que por ejemplo no es posible correr Microsoft
Windows como guest en un sistema Linux usando esta técnica de virtualización. Tampoco es posible ejecutar un sistema Linux
diseñado para un kernel de la rama 2.4.x correr sobre un Linux con kernel 2.6.x.
Sin embargo el beneficio que presenta esta técnica es que sea quizás la de mejor rendimiento sobre cualquier otra técnica de
virtualización existente.
Algunos ejemplos de tecnologías de virtualización con kernel compartido son Linux Vserver, Solaris Zones and Containers,
FreeVPS, OpenVZ, FreeBSD Jails, Paralells Virtuozzo Containers, entre otros.
Ejemplos de tecnologías que usan esta técnica son UML (User Mode Linux) y KVM (Kernel-based Virtual Machine). El diagrama de
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 417
Source Linux
abajo muestra la forma como trabaja la virtualización con esta técnica:
En un entorno de virtualización dominado por esta técnica existe un programa conocido como hypervisor (conocido también como
VMM o Virtual Machine Monitor -Monitor de máquina virtual- de tipo 1) se ejecuta directamente en el hardware del sistema host en
el anillo 0. La tarea de este hypervisor es manejar la asignación de recursos y memoria para las máquinas virtuales además de
proveer interfaces para niveles más altos de administración y herramientas de monitoreo.
Claramente, con el hypervisor ocupando el anillo 0 de la CPU, los kernels de cualquier sistema operativo guest corriendo en el
sistema host deberían corren entonces en anillos menos privilegiados. Desafortunadamente, la mayoría de sistemas operativos
han sido creados para correr sobre el anillo 0 por la sencilla razón de que ellos necesitan realizar tareas que están disponibles sólo
en dicho anillo, tal como la habilidad de instrucciones privilegiadas de CPU y manipular la memoria directamente.
Para este problema se han desarrollado un número de soluciones en los últimos años, cada una de las cuales es descrita a
continuación:
1. Paravirtualización : En la paravirtualización el kernel del sistema operativo guest ha sido modificado especialmente para
correr sobre un hypervisor. Esto involucra reemplazar cualquier operación privilegiada -que normalmente corren en el
anillo 0- con llamadas al hypervisor (llamadas hypercalls o hyper llamadas). Es así que el hypervisor ejecuta entonces en
nombre del kernel guest la tarea privilegiada.
Esto limita el soporte de sistemas guest a sistemas operativos Open Source gracias a la posibilidad de ser libremente
modificables (por ejemplo Linux) y otros sistemas operativos propietarios cuyos fabricantes han accedido a hacer las
modificaciones de código necesarias para correr sobre un hypervisor específico.
Sin embargo la habilidad del kernel guest de comunicarse directamente con el hypervisor trae como resultado mayores
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 418
Source Linux
niveles de rendimiento con respecto a otras técnicas de virtualización.
2. Virtualización completa : Conocido también como Full Virtualización. Esta técnica provee soporte para sistemas
operativos sin modificar. Esto quiere decir que el kernel de los sistemas guest no han sido modificados o reescritos para
correr sobre un hypervisor y sin embargo aún ejecutan tareas privilegiadas como si se ejecutasen en el anillo 0 de la
CPU.
En este escenario el hypervisor provee emulación de CPU para manejar y modificar las operaciones protegidas y
privilegiadas invocadas por el kernel de los sistemas operativos guest (sin modificar).
Lamentablemente este proceso de emulación requiere tanto recursos de sistema y tiempo para funcionar resultando en
un rendimiento inferior comparado al ofrecido por la paravirtualización.
3. Virtualización por hardware : Conocida también como virtualización asistida por hardware. La virtualización por
hardware aprovecha las características de virtualización integradas en los CPU de última generación tanto de Intel como
de AMD. Estas tecnologías conocidas como Intel VT y AMD-V respectivamente, proveen extensiones necesarias para
correr sistemas guest sin modificar sin los impactos negativos inherentes a la emulación de CPU en virtualización
completa.
En términos muy simples, estos nuevos procesadores proveen un modo privilegiado adicional sobre el anillo 0 en el cual
el hypervisor puede ejecutarse casi dejando así el anillo 0 libre para los sistemas operativos guest sin modificar.
Como se muestra en la imagen de arriba, adicionalmente a las máquinas virtuales, un sistema operativo de
administrativo y/o una consola de administración también corren sobre el hypervisor permitiendo a las máquinas
virtuales ser controladas por un usuario administrador.
Entre las soluciones de virtualización con hypervisor existen Xen, Vmware ESX Server y Microsoft Hyper-V.
La meta del diseño es poder ejecutar instancias de sistemas operativos con todas sus características, de forma completamente
funcional en un equipo sencillo. Xen proporciona aislamiento seguro, control de recursos, garantías de calidad de servicio y migración
de máquinas virtuales en caliente. Los sistemas operativos pueden ser modificados explícitamente para correr Xen (aunque
manteniendo la compatibilidad con aplicaciones de usuario). Esto permite a Xen alcanzar virtualización de alto rendimiento sin un
soporte especial de hardware. Intel ha realizado diversas contribuciones a Xen que han permitido añadir soporte para sus extensiones
de arquitectura VT-X Vanderpool. Esta tecnología permite que sistemas operativos sin modificar actúen como hosts dentro de las
máquinas virtuales de Xen, siempre y cuando el servidor físico soporte las extensiones VT de Intel o Pacifica de AMD.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 419
Source Linux
Xen utiliza una técnica llamada paravirtualización para alcanzar alto rendimiento (es decir, bajas penalizaciones del rendimiento,
típicamente alrededor del 2%, con los peores casos de rendimiento rondando el 8%; esto contrasta con las soluciones de emulación
que habitualmente sufren penalizaciones de un 20%).
Con la paravirtualización, se puede alcanzar alto rendimiento incluso en arquitecturas (x86) que no suelen conseguirse con técnicas
tradicionales de virtualización. A diferencia de las máquinas virtuales tradicionales, que proporcionan entornos basados en software
para simular hardware, Xen requiere portar los sistemas operativos para adaptarse al API de Xen. Hasta el momento hay ports para
NetBSD, Linux, FreeBSD y Plan 9.
En 2005, Novell muestra un port de NetWare para Xen. Un port de Windows XP fue creado durante el desarrollo inicial de Xen, pero las
licencias de Microsoft prohíben su lanzamiento público.
Intel ha realizado modificaciones a Xen para soportar su arquitectura de extensiones Vanderpool. Esta tecnología permite que sistemas
operativos sin modificaciones se ejecuten en máquinas virtuales Xen, si el sistema soporta las extensiones Vanderpool o Pacífica (de
Intel y AMD respectivamente, extensiones para soportar virtualización de forma nativa). Prácticamente, esto significa una mejora de
rendimiento, y que es posible virtualizar Windows sin tener que modificarlo.
El 15-08-2007 Citrix adquiere XenSource, por un valor de 500 millones de dólares estadounidenses. Esta empresa ha lanzado
recientemente XenServer 4.1, habiendo un producto gratuito, el XenServer Express Edition, aunque solo puede soportar cuatro
máquinas virtuales.
En la actualidad muchas distribuciones incluyen Xen entre su software soportado, estando esta versión basada en la publicación libre
del software liberada por XenSource, mientras que a la par se mantiene una versión comercial de mayores prestaciones.
Terminología Xen
• Domain : Término usado por Xen para designar a una máquina virtual o sistema guest.
• Domain-0 : Conocido también como Dom0. Es el dominio inicial con el cual arranca el sistema host, y a diferencia de
otros dominios éste es el único privilegiado para tener acceso a interfaces de control del hypervisor. Desde Dom0 se
puede administrar el resto de dominios.
• Domain-U : Conocido también como DomU. Es cualquier dominio distinto no privilegiado, y el hypervisor los mantiene
aislados del hardware y del resto de dominios.
• PV : Dominio paravirtualizado.
Requerimientos
• Xen en la actualidad puede ser ejecutado sobre x86, x86-64, IA-64 y PowerPC.
• Para correr un PV con Xen se requiere que el CPU tenga soporte de PAE (Physical Address Extension)
• Para correr un HVM con Xen se requiere que el CPU tenga soporte de virtualización (El flag vmx en /proc/cpuinfo para
Intel VT, o el flag svm en /proc/cpuinfo para AMD-V).
Identificación de DomU
Cada DomU puede ser identificado de 3 formas:
En Debian y derivados:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 420
Source Linux
# yum install xen-linux-system-2.6.26-2-xen-686 virt-manager -y
Cada DomU tiene su propio archivo de configuración pero es posible prescindir de uno si se arranca el dominio usando directamente
una herramienta como xm.
Los archivos de configuración son creados automáticamente cuando se crean un nuevo dominio utilizando virt-manager, que es
una herramienta gráfica de administración de máquinas virtuales.
name = "linux1"
memory = "512"
disk = [ 'tap:aio:/var/lib/xen/images/linux1.img,xvda,w', ]
vif = ["type=vnc,vncunused=1"]
uuid = "eb675005-e347-4e47-8678-48ce3b676fe1"
bootloader = "/usr/bin/pygrub"
vcpus = 1
on_reboot = 'restart'
on_crash = 'restart'
En la ventana principal de virt-manager debe aparecer un único hypervisor de nombre 'localhost'. Si debajo de él no se muestra
ningún dominio entonces es necesario conectarse a dicho hypervisor dando doble clic sobre su nombre (localhost).
1.Una vez conectado al hypervisor, seleccionar el nombre 'localhost' y dar clic al botón 'Nuevo' mostrado en la parte inferior.
3.En la siguiente pantalla definir el nombre que se asignará a la máquina virtual, luego dar clic en 'Adelante'.
4.En la siguiente pantalla escoger la técnica de virtualización: 'Paravirtualizado' o' 'Completamente virtualizado'. Asimismo elegir la
arquitectura de CPU que se pretende emular si se escoge la segunda técnica. Asumiendo que se eligió la opción 'Paravirtualizado' dar
clic en 'Adelante'.
5.En la siguiente pantalla elegir 'Linux' como tipo de sistema operativo y 'Red Hat Enterprise Linux 5' como variante de SO. Luego dar
clic en 'Adelante'.
6.En la siguiente pantalla se debe especificar una URL (HTTP, FTP) donde se publica el árbol de instalación del sistema operativo a
instalar (el contenido del DVD de instalación de RHEL 5). Si se planea usar Kickstart o modificar parámetros de arranque del kernel se
pueden especificar en los campos siguientes. Luego dar clic en el boton 'Adelante'.
7.En la siguiente pantalla se debe especificar el almacenamiento (disco duro) que usará el DomU. Se puede optar por elegir una
partición o Logical Volume existente, o crear un archivo de imagen de tamaño y ruta específicos. Tras elegir la segunda opción (crear
archivo de imagen) con un tamaño de 5000 MB promedio y marcando la opción 'Asignar el disco virtual ahora', dar clic en 'Adelante'.
8.En la siguiente pantalla se debe elegir el tipo de red que se asignará al DomU. La 'Red Virtual' crea una red propia separada y
'Dispositivo físico conectado' a través de la creación de un bridge sobre nuestra interfaz Ethernet permite al DomU acceder y ser
accedido por la red física real a la cual está conectada nuestro Dom0. Tras elegir la segunda opción de red (bridge) y dejar la dirección
MAC ser asignada automáticamente, dar clic en 'Adelante'.
9.En la siguiente pantalla se debe elegir la cantidad de memoria RAM y CPUs virtuales asignados al DomU. Luego dar clic en
'Adelante'
10.En la siguiente pantalla se muestra el resumen de la configuración hecha y se debe confirmar dando clic en 'Finalizar' para crear ya
el DomU, arrancarlo e iniciar la instalación según los parámetros configurados.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 421
Source Linux
•virt-manager y virsh : Herramientas creadas para soportar distintas tecnologías de virtualización (Xen, KVM, QEMU, etc) con una
interfaz comun al usuario.
A continuación estudiaremos algunas tareas rutinarias con los dominios utilizando para cada caso los dos tipos de herramientas
disponibles.
Iniciando dominios
Las formas de iniciar un dominio existente ya definido en /etc/xen son las siguientes:
# xm create <dominio>
# virsh start <dominio>
xm create permite aceptar parámetros adicionales que sobreescriban algunos de los ya definidos en el archivo de configuración.
Por ejemplo a continuación se inicia un dominio con una memoria distinta a la definida en su configuración:
# xm destroy <dominio>
# virsh destroy <dominio>
# xm shutdown <dominio>
# virsh shutdown <dominio>
# xm reboot <dominio>
# virsh reboot <dominio>
La diferencia entre las operaciones destroy y shutdown es que la primera lo hace de manera brusca e inmediate (como si un
corte de energía sucediese) y la segunda correctamente de acuerdo a las rutinas de apagado del sistema operativo.
# xm pause <dominio>
# virsh suspend <dominio>
Las formas posibles de resumir o reactivar un dominio suspendido son las siguientes:
# xm unpause <dominio>
# virsh resume <dominio>
Las formas posibles de reanudar un dominio desde un archivo de estado son las siguientes:
# xm restore <ruta_archivo>
# virsh restore <ruta_archivo>
# xm list
# virsh list
virsh list lista la información de todos los dominios activos, mientras que xm list puede aceptar el nombre de un dominio como
parámetro adicional para listar la información de aquel solamente.
xm list muestra un listado de información con campos como los debajo descritos:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 422
Source Linux
ID El número ID del dominio en ejecución.
Mem (MiB) La memoria en MB del dominio.
VCPUs El número de CPUs virtuales usados por el dominio.
State Existen seis estados:
# chkconfig xendomains on
# ln -s /etc/xen/dominio /etc/xen/auto
CPUs virtuales
A cada dominio se le asigna un número de CPUs virtuales (VCPUs) cuando se crea el dominio. Los VCPUs son programados para
correr en CPUs reales enel sistema por el hypervisor (Dom0). Por defecto todos los dominios tienen igual acceso al CPU real.
La forma de definir la cantidad de CPUs virtuales para un dominio es a través de la directiva vcpus configurada como debajo se
muestra:
vcpus=4
Se puede asignar más CPUs virtuales de la cantidad de CPUs reales que existen en el sistema físico, sin embargo eso trae como
consecuencia un rendimiento negativo.
Se puede elegir en cuál de los CPU físicos del sistema se ejecutará un dominio como se muestran en los siguientes ejemplos:
cpus=2,4-6
cpus=2,3
Xen no diferencia entre CPUs físicos (sockets), núcleos (cores) en un mismo CPU o hyperthreads. Normalmente Xen buscará
CPUs en el orden siguiente: primero hyperthreads, luego núcleos en el mismo CPU y luego núcleos en CPUs distintos (otros
sockets de procesador).
Esto puede compararse con la información de hardware del sistema host o Dom0 como sigue:
# virsh nodeinfo
La cantidad de CPUs virtuales de un dominio se puede modificar dinámicamente a través de las siguientes formas:
El comando anterior sin embargo depende del máximo número de CPUs asignados inicialmente al arrancar el dominio (según la
definición en su archivo de configuración). Es así que sólo se puede cambiar la cantidad de CPUs virtuales a un valor igual o menor
al máximo soportado por el dominio durante su ejecución, no ser incrementado más allá de dicho límite.
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 423
Source Linux
Memoria
Por defecto el Dom0 al arrancar usa toda la memoria disponible en el sistema, y conforme van iniciando otros dominios va
asignándoles la memoria que requieren mientras esa misma cantidad decrece en la usada por Dom0.
La cantidad de memoria asignada a un domino se define con la siguiente directiva en su archivo de configuración:
memory="512"
La cantidad de memoria de un dominio puede ser dinámicamente modificada de alguna de las siguientes formas:
Al igual como sucede con los CPUs virtuales, la cantidad de memoria máxima es la asignada al arrancar el dominio y por encima
de este valor no podría incrementarse la memoria de un DomU.
Dispositivos virtuales de bloques
Los dispositivos de bloques virtuales simulan ser discos duros para los DomU, los cuales pueden ser utilizados como cualquier otro
dispositivo de bloques real para ser particionado, formateado con un sistema de archivos y montado.
Generalmente el primero de estos dispositivos de bloques virtuales se muestra al DomU como /dev/xvda, el segundo como /dev/xvdb
y así sucesivamente. También las particiones siguen el esquema tradicional de nomenclatura como /dev/xvda1, /dev/xvda2, etc.
El backend real de estos dispositivos virtuales de bloques se muestran como archivos de imágenes o dispositivos de bloques
reales en Dom0.
Y la configuración de este archivo de imagen se configura como un dispositivo virtual de bloques para un DomU en su archivo de
configuración como sigue:
disk = [ 'tap:aio:/var/lib/xen/images/linux1.img,xvda,w', ]
Como alternativa a los archivos de imágenes, se puede configurar un dispositivo de bloques real de Dom0 como dispositivo virtual
de bloques para un DomU con una configuración similar a alguno de los ejemplos:
Dispositivos de red
Cuando inicia Dom0, la interfaz de red eth0 que conectaba inicialmente a la red física es renombrada a peth0, y se crea luego un
dispositivo de red virtual de nombre eth0 que funciona conectado al dispositivo bridge xenbr0 para conectar a Dom0 con la
misma red física a la que se conecta peth0.
Es así que se pueden crear múltiples interfaces de red virtuales adheridas al bridge xenbr0 para cada uno de los DomU de modo
que éstos puedan acceder a la red física.
La manera de configurar los dispositivos virtuales en el archivo de configuración de DomU es como sigue:
Se recomienda asignar una dirección MAC dentro del rango 00:16:3E que es el código reservado para el fabricante Xen.
vfb = [ "type=vnc,vncunused=1" ]
O si se desea ser más detallado con el control VNC algo como lo siguiente:
vfb = [ "type=vnc,vncdisplay=4,vnclisten=172.31.0.3,vncpasswd=abc123" ]
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 424
Source Linux
De estas configuraciones se puede explicar que:
vncunused=1
Permite elegir automáticamente un puerto de escucha libre para servir VNC. Por defecto es el 5900.
vncdisplay=N
Permite elegir el display (y así el puerto de escucha) del servicio VNC. El puerto usado se calcula de la suma de 5900 + N. El
comando virsh vncdisplay <dominio> permite averiguar el display asociado a un dominio.
vnclisten=DIRECCIÓN
Permite elegir la dirección de esucha del servicio VNC, ya que por defecto se limita a escuchar en localhost.
vncpasswd=PASSWORD
Permite definir un password de acceso al servicio VNC, ya que por defecto no trae ningún password asignado.
20.2.8. Instalación desde línea de comandos
Para hacer instalaciones de guests desde línea de comandos se hace uso de la herramienta virt-install cuya forma de uso se
muestra debajo:
virt-install [opciones]
Crea e instala nuevas dominios
Opciones:
path=RUTA
Define la ruta del dispositivo de almacenamiento.
device=TIPO
Define el tipo de almacenamiento. Puede ser 'cdrom', 'floppy' o 'disk'.
size=TAMAÑO
Define el tamaño en GB que tendrá el dispositivo de almacenamiento cuando es de tipo 'disk'
sparse=true|false
Si es false, entonces al momento de crear la imagen del dispositivo de almacenamiento lo hará ocupando el tamaño máximo
completo. Si es true entonces la imagen de almacenamiento crecerá conforme se necesite espacio en el DomU.
El siguiente ejemplo crea un DomU paravirtualizado que será instalado desde una imagen ISO (el DVD de RHEL 5.4 x86_64). El
DomU tendrá 512 MB de RAM y un disco duro virtual de 10 GB de tamaño completo asignado desde el principio, y estará conectado a
la red física bajo el bridge xenbr0:
El siguiente ejemplo crea un DomU completamente virtualizado que será instalado desde la lectora de CDROM/DVD (conteniendo un
disco de instalación de Windows XP). El DomU tendrá 1 GB de RAM y un disco duro virtual de 30 GB de tamaño completo asignado
desde el principio, y estará conectado a la red física bajo el bridge xenbr0:
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 425
Source Linux
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 426
Source Linux