U nida d didá ctica 2

A d m in is tra c ió n d e s is te m a s d e s o ftw a re
lib re

E n esta unidad v amos a aprender a config urar y administrar un serv idor Linux.
E mpezaremos con lo más sencillo como son permisos, usuarios, paquetería… y
terminaremos config urando una serie de aplicaciones consideradas fundamentales a
la hora de trabajar con serv idores de producción como puedan ser Apache2, Bind9,
S amba…

Al finalizar el estudio de estas lecciones serás capaz de:

Crear usuarios y g rupos y g estionar los permisos que tienen sobre los
recursos.

Instalar todo tipo de software mediante la utilización de las herramientas de

g estión de paquetes.

Gestionar los procesos del sistema operativ o.

C onfig urar aplicaciones que proporcionen serv icios web, de compartición de

archiv os, etc.

C onfig urar la seg uridad del sistema operativ o.

S olucionar ciertos problemas que pueden surg ir a la hora de config urar el

serv idor.

Administración de sistemas de software libre 1

 Ca p ítulo 1
Ges tión de us uarios y g rupos

La creación de usuarios y g rupos, junto con los permisos asociados a estos es

fundamental en cualquier sistema. E s importante saber a quién le damos acceso al
sistema debido a que puede representar un problema g rav e de seg uridad. E n este
capítulo v eremos los comandos necesarios para realizar esta g estión de manera
eficaz.

Al finalizar el estudio de estas lecciones serás capaz de:

C rear usuarios y g rupos para el acceso al sistema.

C onfig urar la expiración de las cuentas de usuario y otros parámetros

necesarios.

E stablecer las políticas por defecto a la hora de crear usuarios.

C onfig urar el sistema de cuotas para ev itar la saturación del sistema.

Administración de sistemas de software libre 2

 L e c ció n 1
I ntroducción

Los sistemas Linux son multiusuario y multitarea, esto quiere decir que puede
g estionar muchos usuarios y estos pueden estar realizando div ersas tareas a la v ez.
Para poder g estionar todos los usuarios, a cada uno de ellos se les asig na un
nombre de usuario y una contrase a con los que podrán acceder al sistema.
Además del nombre de usuario y la contrase a se les puede asig nar también un
identificador de usuario ( UID) y un identificador de g rupo ( GID)

Normalmente el proceso de ag reg ar un identificador de usuario, así como un

identificador de g rupo, lo realiza el sistema operativ o por defecto asig nando
siempre números may ores que los que aparezcan en el fichero / etc/ log in.defs el
cual puede ser modificado. Los números menores normalmente son utilizados por
los usuarios del sistema así como los usuarios de las nuev as aplicaciones que
instalemos.

Los usuarios del sistema se ag reg an al instalar aplicaciones como Apache2 o Bind9
y son usados por estas para llev ar a cabo ciertas tareas. E stos usuarios no inician
sesión en el sistema en ning ún momento.

Además de los usuarios que v ay amos ag reg ando al sistema, existe un usuario con
todos los priv ileg ios que se crea automáticamente cuando realizamos la instalación
del sistema operativ o llamado root. root, también llamado s uperus uario, es la
cuenta de administrador en los sistemas Linux la cual posee permisos para realizar
cualquier cosa en el sistema operativ o. Por esta misma razón y debido al pelig ro
que entra a, la cuenta root debe ser utilizada con extremo cuidado y a que al
poseer permisos para realizar cualquier tarea, podemos desconfig urar o eliminar
alg o crítico para el sistema. La cuenta del usuario root se crea con el UID 0 y GID 0

La correcta administración de los usuarios de un sistema operativ o Linux es crítica

debido a que una mala g estión de los mismos puede poner el sistema en riesg o.

Administración de sistemas de software libre 3

 L e c ció n 2

Com a ndos de g es tión de us uarios

E l comando para a adir nuev os usuarios al sistema es us eradd

La sintaxis del comando es la sig uiente:

us eradd pa rá m etros us uario

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- u uid ? C on esta opción le asig namos el identificador de usuario

manualmente al nuev o usuario del sistema.
- g g id ? Con esta opción le asig namos el identificador del g rupo primario al
que pertenecerá el nuev o usuario del sistema.
- G g id ? C on esta opción incluimos al usuario en otros g rupos adicionales
además del primario.
- d directorio ? C on esta opción definimos el directorio de trabajo por
defecto del nuev o usuario del sistema.
- e fecha de ex piración ? C on esta opción definimos la fecha de expiración
de la cuenta del nuev o usuario en formato AAAA- MM- DD
- p " contras eña" ? C on esta opción definimos en el propio comando
useradd la nuev a contrase a del usuario.
- s s hell ? C on esta opción definimos el intérprete de comandos que podrá
utilizar el usuario. C omo norma g eneral se utiliza bash como intérprete de
comandos por defecto.
- c com entario ? C on esta opción le asig namos un comentario a la cuenta
del usuario que v amos a crear.

C omo ejemplo, si quisiéramos crear un nuev o usuario que se llame "Pepito" con
UID 5000, cuy o directorio home fuera /home/pepito y cuy a cuenta expirara el 1 de
enero de 2012 utilizaríamos el sig uiente comando:

us eradd - u 9 9 9 - g 8 5 0 - d / hom e/ pepito - e 2 0 1 2 - 0 1 - 0 1 P epito

Para más opciones sobre useradd así como cualquier comando del sistema basta
con consultar su pág ina man ? m an us eradd

Una v ez creado el usuario podemos asig narle la contrase a con el comando

pas s w d .

La sintaxis del comando es la sig uiente:

pas s w d pará m etros us uario

Administración de sistemas de software libre 4

Alg unos de los parámetros usados por el comando son:

- l ? Con esta opción bloqueamos la cuenta del usuario. C onv ierte la

contrase a en una cadena inv álida a adiéndole el carácter "! ".
- u ? Con esta opción hacemos lo contrario que con la opción - l. Desbloquea
la cuenta del usuario y le quita el prefijo !
- n días ? C on esta opción indicamos el tiempo mínimo de v ida en días para
la contrase a del usuario.
- x días ? C on esta opción indicamos el tiempo máximo de v ida en días para
la contrase a del usuario.
- w día s ? Con esta opción indicamos el número de días a partir del cual el
usuario recibe un warning diciendo que debe cambiar la contrase a antes de
que expire.

C uando se crea un nuev o usuario del sistema, su información se almacena en el

fichero / etc/ pas s w d al cual sólo puede acceder el usuario root y no se deberían
modificar dichos permisos a no ser que sea imprescindible. Además de los usuarios
que creemos nosotros, en ese fichero aparecen también las cuentras de los
usuarios del sistema como Apache2 o bind9.

S i mostramos el contenido del fichero /etc/passwd tendremos alg o parecido a esto:

cat / etc/ pas s w d

E l formato del fichero especifica siete campos distintos, cada uno de ellos separado
por ": " Los campos corresponden con lo sig uiente:

1. Nombre de la cuenta del usuario.

2. C ontrase a del usuario codificada. No nos serv iría de nada intentar modificar
la contrase a del usuario aquí y a que no único que conseg uiríamos es que la

Administración de sistemas de software libre 5

 cuenta quedara bloqueada. La x hace referencia también a que se está
usando el archiv o / etc/ s hadow .
3. E l número del identificador de usuario ( UID)
4. E l número del identificador del g rupo al que pertenece el usuario ( GID)
5. E l comentario que le hay amos asig nado al usuario. S i no le hemos asig nado
ning ún comentario, este campo quedará v acío.
6. E l directorio de trabajo del usuario al cual se conectará por defecto al iniciar
sesión en el sistema.
7. La shell o intérprete de comandos que utilizará el usuario al iniciar sesión en
el sistema.

No todo el contenido de las cuentas de los usuarios se almacena en el fichero

/etc/passwd. Dado que cualquier usuario puede leer el fichero ( aunque no
modificarlo) , es posible que con el tiempo y una buena herramienta de
desencriptado, cualquier usuario lleg ara a conocer las contrase as de los demás si
estas aparecieran en el fichero. Para solucionar este problema existe el fichero
/ etc/ s hadow . La x que aparece en el campo contrase a de los usuarios en el
fichero /etc/passwd sig nifica que se está utilizando el archiv o /etc/shadow al cual
sólo puede acceder root y de esta forma se ev ita que cualquier usuario del sistema
acceda a las contrase as cifradas. S i no se hiciera uso de /etc/shadow, en el campo
de contrase a aparecería directamente la contrase a cifrada.

E l contenido del archiv o /etc/shadow debería ser similar a este:

Podemos apreciar cómo aparece la contrase a cifrada de root y cómo no aparece la

de los usuarios del sistema al no tener ning una asig nada y por lo tanto no poder
iniciar sesión en el sistema.

Los campos que aparecen en el fichero /etc/shadow se corresponden con:

1. Nombre del usuario.

2. C ontrase a cifrada. E n el caso de que aparezca "*" la cuenta no puede
iniciar sesión.

Administración de sistemas de software libre 6

 3. Número de días transcurridos desde el 1 de enero de 1970 hasta la fecha en
la que la contrase a fue cambiada por última v ez.
4. Número de días hasta que la contrase a se pueda cambiar.
5. Días en los que expira la contrase a y por lo tanto hay que cambiarla.
6. Días antes de la expiración de la contrase a a partir del cual se le env iarán
notificaciones al usuario para que la cambie.
7. Número de días después de que expire la contrase a tras los cuales se
inhabilitará.
8. Día en el que caduca la cuenta. S e cuenta a partir del 1 de enero de 1970.

¡ P onte a prueba!

Ahora que hemos v isto cómo funcionan los usuarios en los sistemas operativ os
Linux v amos a practicar con ellos. Para ello v amos a crear un usuario que se
llame "pepe", cuy o UID sea 600, con contrase a "12345", su shell sea
/bin/false y le a adiremos el comentario "usuario de prueba".

Para ello, nos conectamos a la terminal de nuestra máquina v irtual Centos

y endo a aplicaciones?accesorios?terminal. Podemos crearnos un acceso
directo si no lo hemos hecho y a pinchando en la terminal y arrastrándola hasta
la barra superior. T ambién podemos conectarnos desde nuestro escritorio
utilizando la aplicación de ssh "putty "

Una v ez con la terminal abierta podemos crear el usuario. Para

ello, necesitamos tener permisos para utilizar el comando useradd
por lo que pasamos a utilizar la cuenta de root:

su -

Administración de sistemas de software libre 7

 Una v ez que estemos utilizando la cuenta de root construimos el comando
useradd:

us era dd - u 6 0 0 - s / bin/ fa ls e - c " U s ua rio de prueba " pepe

Le asig namos la contrase a al usuario:

pas s w d pepe

Nos pedirá introducirla dos v eces, le asig namos "12345".

Ahora v amos a comprobar el contenido del fichero /etc/passwd para v er si

se ha creado correctamente el usuario:

cat / etc/ pas s w d | g rep pepe

Deberíamos obtener la sig uiente salida:

V amos a comprobar también si la cuenta de pepe aparece en el fichero

/etc/shadow:

cat / etc/ s hadow

Ahora que hemos creado el nuev o usuario v amos a probar a acceder al sistema
con él. Para ello v amos a cerrar sesión y a iniciarla con la cuenta "pepe". Nos
v amos a sistema?salir

Una v ez deslog ueados probamos a iniciar sesión con el nombre de usuario

"pepe" y la contrase a "12345". No deberías poder iniciar sesión. S i puedes
iniciar sesión, rev isa los comandos introducidos y aseg úrate de que estos
coinciden con los expuestos aquí.

Administración de sistemas de software libre 8

Además del comando useradd, si queremos modificar los datos de un usuario y a
creado, eliminarlo, etc disponemos de otros comandos que se explican a
continuación:

Para modificar la información de un usuario creado prev iamente se utiliza el

comando us erm od.

La sintaxis del comando es la sig uiente:

us erm od pa rá m etros us uario

A parte de los comandos que se le pasan a useradd se le pueden pasar entre otros:

- L ? Bloquea la cuenta de un usuario impidiendo que acceda al sistema.

- U ? Desbloquea una cuenta de usuario bloqueada prev iamente con la

opción - L

- l nuev o nom bre de us uario ? C ambia el nombre de usuario con el que

iniciará sesión en el sistema.

- a nom bre de g rupo ? A ade al usuario a otro g rupo. Hay que usarlo
siempre con la opción - G.

- G g rupos ? E specifica el g rupo o los g rupos a los que se a adirá al

usuario.

Para poder eliminar un usuario, se utiliza el mandato us erdel.

La sintaxis del comando es la sig uiente:

us erdel pará m etros us uario

Userdel, si no se le pasa ning ún parámetro eliminará la cuenta del usuario de los

ficheros /etc/passwd y de /etc/shadow pero no eliminará ni su directorio de trabajo
ni los ficheros que hubiera ahí.

S i le pasamos la opción - r se eliminará la cuenta de /etc/passwd y /etc/shadow y

también su directorio de trabajo y los archiv os que hay a en el. S i el usuario está
log ueado en el sistema no dejará eliminarlo.
Por último, la opción - f hace lo mismo que - r pero da ig ual si el usuario se
encuentra log ueado o no.

Otro comando útil a la hora de trabajar con usuarios es el comando chag e el cual
nos ay uda a modificar los tiempos de expiración de las contrase as entre otras
cosas.

La sintaxis del comando es:

chag e pa rá m etros us ua rio

Administración de sistemas de software libre 9

Los parámetros más utilizados son los sig uientes:

- m día s ? Número mínimo de días entre cambios de contrase as.

- M días ? Número máximo de días entre cambios de contrase as.

- E fecha ? Día en el que expira la cuenta en formato AAAA- MM- DD

- W días ? Número de días antes de que el usuario teng a que cambiar la

contrase a en el que se le empezarán a env iar "warning s"

Por ejemplo, si quisiéramos que la cuenta de pepe expirara el día 31/dic/2011, lo

haríamos de la sig uiente forma:

cha g e - E 2 0 1 1 - 1 2 - 3 1 pepe

Administración de sistemas de software libre 10

 L e c ció n 3

Com a ndos de g es tión de g rupos

C on el objetiv o de facilitar la concesión de permisos a distintos usuarios y tener la

jerarquía de usuarios mejor org anizada existen los g rupos. Al ig ual que con los
usuarios, a la hora de crear un nuev o g rupo se le asig na el sig uiente GID que esté
disponible por defecto.

E l comando para a adir nuev os g rupos es g roupadd que se construiría así:

g roupa dd parám etros g rupo

Podemos cambiar la información de un g rupo mediante g roupm od:

- g GI D ? Le cambiamos el GID al g rupo.

- n nuev o nom bre del g rupo ? S e le cambia el nombre al g rupo.

- A us ua rio ? S e a ade al usuario al g rupo especificado.

Podemos eliminar un g rupo mediante el comando g roupdel

La información sobre los g rupos que hay creados así como los usuarios que
pertenecen a cada uno se puede v er en el fichero / etc/ g roup

S i mostramos el contenido de dicho fichero deberíamos v er alg o parecido a lo

sig uiente:

Los campos de dicho fichero se corresponden con:

1. Usuario.

2. C ontrase a del g rupo. Aparece una x al no tener contrase a, si tuv iera

alg una, se mostraría encriptada.

3. E l GID o identificador de g rupo.

Administración de sistemas de software libre 11

 4. Grupos a los que pertenece el usuario.

¡ P onte a prueba!

V amos a solucionar el problema por el cual el usuario "pepe" no puede iniciar

sesión y v amos a a adirle a un g rupo que crearemos ahora llamado
"formación" con GID 1000.

E l problema por el cual el usuario pepe no podía iniciar sesión en el sistema es

que le hemos asig nado como shell o intérprete de comandos /bin/false y por lo
tanto no hemos permitido su acceso.

Debemos conectarnos al serv idor C entos mediante putty o a trav és del propio
serv idor mediante la terminal. Para proporcionarle acceso al sistema v amos a
decirle que su shell es la shell por defecto, es decir /bin/bash, lo hacemos con
el comando de modificación de usuarios usermod pero primero debemos pasar
a usar la cuenta de root:

su -

A continuación ejecutamos el comando:

us erm od - s / bin/ bas h pepe

Ahora no deberíamos tener problemas para iniciar sesión en el equipo como

pepe, lo probamos y efectiv amente comprobamos que es así.

Ahora v amos a crear el g rupo "formación" con GID 1000 mediante el comando
g roupadd:

g roupa dd - g 1 0 0 0 form a ción

Ahora v amos a a adir al usuario pepe al g rupo formación:

us erm od - a G form ación pepe

Mostramos el contenido del fichero /etc/g roup para comprobar que se ha

a adido correctamente a pepe al g rupo:

cat / etc/ g roup | g rep pepe

Ahora el usuario pepe pertenece tanto al g rupo que llev a su

nombre como al g rupo formación.

Administración de sistemas de software libre 12

 L e c ció n 4
O tros com a nd os d e interés

Además de los comandos aquí expuestos, hay otros que resultan útiles a la hora de
trabajar con usuarios y g rupos como son los sig uientes:

id nom bre de us ua rio ? Muestra información sobre la identidad del

usuario.

E jemplo:

id pepe

fing er nom bre de us uario ? Muestra información detallada de los

usuarios.

fing er pepe

g roups nom bre de us uario ? Muestra los g rupos en los que está incluido
un determinado usuario.

g roups pepe

Administración de sistemas de software libre 13

 L e c ció n 5

F ic hero s d e c o nfig ura ció n

La tarea de asig nar un g id a cada usuario, ponerle el tiempo de expiración de la

contrase a, asig nar los permisos que deberá tener por defecto cuando inicie sesión,
etc uno a uno puede ser una tarea tediosa y puede alarg arse mucho en el tiempo.

Para simplificar la tarea existe el fichero / etc/ log in.defs .

E l contenido del fichero debería ser similar a este:

E n él se pueden definir v ariables que usarán por defecto los comandos useradd y
usermod a la hora de crear nuev os usuarios.

A continuación se definen alg unas de las v ariables que aparecen en el fichero:

MA I L _ D I R ? Directorio que se usará para alberg ar el correo.

CR E A T E _ H O ME ? S i está puesto a "y es" creará un directorio a cada
usuario que creemos por defecto.
P A S S _ MI N_ L E N ? Long itud mínima que debe tener la contrase a para que
sea aceptada por el sistema.
P A S S _ MA X _ D A Y S ? Número máximo de días que deben pasar entre
cambios de contrase as.

Para el resto de opciones basta con leer la descripción asociada a ellas.

Además del fichero /etc/log in.defs existen también otros ficheros que podremos
modificar para cambiar el comportamiento por defecto a la hora de trabajar con los
usuarios que inicien sesión. E stos se encuentran en la ruta / etc/ s kel/

Administración de sistemas de software libre 14

S i nos v amos a esa ruta y hacemos un ls para mostrar el contenido de la carpeta no
v eremos nada, esto es porque son ficheros ocultos y llev an un "." delante del
nombre. Para mostrarlos debemos usar la opción - a:

ls - a

E n el fichero .bas h_ log out se definen las acciones, prog ramas, etc que se
ejecutarán cuando se cierre la sesión.

E n el fichero .bas hrc se definen los prog ramas a ejecutar una v ez iniciada la sesión
del usuario.

E n el fichero .bas h_ profile se define sobre todo la config uración del entorno del
usuario que se ejecutará al iniciar sesión.

Administración de sistemas de software libre 15

 L e c ció n 6

A d m inis tra ción d e us ua rios y g rup os

m ed ia nte el ento rno g rá fic o

E s posible g estionar tanto los usuarios como los g rupos desde la herramienta
g ráfica. E sta puede ser inv ocada en C entos mediante el comando s y s tem - config -
us ers . E sta herramienta puede resultar muy práctica cuando no se tiene
experiencia en el manejo de sistemas linux.

C on la opción "añadir us ua rio" podremos crear nuev os usuarios y asig narles

div ersos v alores como se aprecia en la imag en de abajo.

C on la opción "añadir g rupo" simplemente podremos asig nar el nombre del g rupo
y el ID.

Administración de sistemas de software libre 16

C uando seleccionemos un usuario o un g rupo se habilitará el botón de propiedades
y podremos a adir a usuarios a un g rupo especificado, modificar la fecha de
expiración de las cuentas, etc.

E n un sistema de producción al no incluirse entorno g ráfico la may oría de las v eces,

esta herramienta no estará disponible.

Administración de sistemas de software libre 17

 L e c ció n 7
E l s is tem a d e cuota s

La administración del espacio en disco es v ital para cualquier sistema. Los recursos
de los que dispone una máquina son limitados y por lo tanto si v arios usuarios v an
a trabajar en un determinado equipo se debe implementar alg ún mecanismo que
establezca un límite en el número de recursos que se v an a utilizar.

C on el fin de g estionar el espacio en disco existe el concepto de cuota. Las cuotas

se establecen en una determinada partición del sistema y se pueden aplicar a
usuarios us rquota , a g rupos g rpquota o a ambos.

E l comando quotacheck se utiliza para analizar el espacio en disco, crear o reparar

archiv os de cuota. Alg unos de los parámetros que se le pueden pasar son:

- m ? S e fuerza al sistema a comprobar el sistema de archiv os en modo

lectura- escritura.
- a ? Comprueba todos los sistemas de archiv os.
- v ? V a informando del prog reso de la operación mientras esta se ejecuta.
- u ? S ólo se comprueban las cuotas de usuario.
- g ? S ólo se comprueban las cuotas de g rupo.

C on los comandos quotaon y quotaoff podemos habilitar o deshabilitar las cuotas

en el sistema de archiv os.

quotaon:

- v ? E nse a un mensaje por cada sistema de archiv os en el que las

cuotas están activ adas.
- a ? Activ a las cuotas para todos los sistemas de archiv os.

quotaoff:

- a ? Deshabilita las cuotas en todos los sistemas de archiv os.

- v ? E nse a un mensaje por cada sistema de archiv os afectado.

C on el comando repquota se puede obtener información del estado de las cuotas

en un determinado sistema de archiv os.

- a ? S aca un reporte completo del estado de las cuotas.

- u ? S aca por pantalla las cuotas de los usuarios.
- n ? No resuelv e los UID/GID en nombres, esto puede acelerar
considerablemente el proceso de reporte.

Administración de sistemas de software libre 18

C on el comando edquota podemos establecer la cuota de un determinado usuario.
Al ejecutarlo, se modificará el fichero mediante el editor v i y habrá v arias columnas
que modificar.

Las columnas "blocks " e "inodes " son informativ as e indican la cantidad de
bloques e inodos utilizados actualmente por el usuario. Lo habitual es establecer los
límites ( soft, hard) en el número de inodos o en el de bloques pero no en los dos a
la v ez aunque esto sería también posible.

Los bloques ocupan un 1K B por lo tanto para establecer una cuota de 5MB a un
usuario deberíamos asig narle 5000 bloques. Los inodos representan el número de
archiv os que un usuario puede crear en el sistema.

Cuando el usuario rebase el límite s oft se le notificará la usuario y entrará en el

"periodo de g racia". Cuando se acabe el periodo de g racia ( por defecto 7 días) o el
usuario lleg ue al límite hard, no podrá crear más archiv os hasta que elimine
alg unos.

Alg unos de los parámetros de edquota son:

- p us uario1 us ua rio2 ? C opia el patrón de cuotas del usuario1 al

usuario2.
- u ? E dita las cuotas de los usuarios.
- g ? E dita las cuotas de los g rupos.

¡ P onte a prueba!

V amos a implementar el sistema de cuotas para usuario en nuestro sistema

C entos. Para ello habrá que a adir la opción usrquota a la partición / y v olv er a
montarla para que surtan efecto los cambios.

Nos conectamos a nuestra máquina Centos v ía putty o a trav és de la propia

terminal del sistema y usando el usuario root editamos el fichero /etc/fstab. E l
fichero /etc/fstab indica las particiones disponibles así como las opciones
aplicadas a cada partición.

joe / etc/ fs tab

y a adimos la opción usrquota en las opciones de la partición /

Administración de sistemas de software libre 19

 V olv emos a montar la partición / con la opción que le acabamos de a adir:

m ount - o rem ount /

C on la opción - o le decimos a mount que v uelv a a montar ( remount) la

partición.

Le decimos al sistema que cree el fichero necesario para g estionar las quotas
mediante el comando:

quotacheck - m av u

Lo cual debería habernos g enerado en la raíz / el fichero aquota .us er:

ls - a /

Finalmente le decimos al sistema que habilite las quotas con el comando:

quotaon /

Ya tenemos habilitado el sistema de cuotas.

Administración de sistemas de software libre 20

 Ca p ítulo 2
Ges tión d e p erm is o s d e us ua rio

La g estión de permisos es un tema fundamental en cualquier sistema operativ o,

una mala g estión de los mismos puede desembocar en g rav es problemas de
seg uridad y por lo tanto, que el sistema se v ea expuesto a posibles ataques.

E n este capítulo v amos a aprender a manejar los comandos necesarios para

administrar los permisos en Linux.

Al finalizar el estudio de estas lecciones serás capaz de:

Modificar los permisos de ficheros y directorios.

Modificar el usuario y g rupo propietario de ficheros y directorios.

C onfig urar sudo para que otros usuarios puedan ejecutar comandos sólo
accesibles por root.

C onfig urar AC Ls para incluir permisos para v arios usuarios sobre una
determinada carpeta o archiv o.

Administración de sistemas de software libre 21

 L e c ció n 1
I ntroducción

Además de la correcta g estión de los usuarios y g rupos de un sistema, es v ital la

administración de los permisos que se le asig nan a cada uno. Una asig nación
errónea de demasiados permisos a un determinado usuario puede traer consig o un
ag ujero de seg uridad considerable.

E xisten tres tipos de permisos:

r= lectura ? Cualquier usuario que teng a permiso de lectura sobre un

directorio podrá mostrar su contenido. S i el permiso de lectura lo tiene sobre
un archiv o, podrá v er su contenido.

w = es critura ? E l usuario que teng a permisos de escritura sobre un

determinado directorio podrá crear y borrar nuev os archiv os en el. S i está
asig nado a un archiv o, podrá modificar su contenido.

x = ejecución ? C uando se tiene este permiso sobre un directorio, el

usuario puede acceder a el, mientras que si se trata de un archiv o, este
podrá ser ejecutado.

Podemos mostrar los permisos de los archiv os de un directorio mediante el

comando ls - l, a continuación se muestran, por ejemplo, los permisos de la carpeta
/tmp:

Hay nuev e campos en total separados por espacios. V amos a cog er, por ejemplo, el
último directorio que aparece "v irtual- root.eflZ cm"

E l primer campo lo compone d r w x - - - - - -

E l primer carácter que aparece "d" indica el tipo de archiv o que en este caso es un
directorio "d", los sig uientes nuev e caracteres indican los permisos efectiv os para
ese archiv o.

De esos nuev e caracteres, los tres primeros rw x indican los permisos para el
propieta rio del archiv o. E n este caso el propietario tendría permisos de lectura,
escritura y ejecución.

Administración de sistemas de software libre 22

Los sig uientes tres caracteres indican los permisos efectiv os para el g rupo
propietario del archiv o. E n este caso, el g rupo propietario no tendría ning ún
permiso sobre el archiv o en cuestión.

Los últimos tres caracteres indican los permisos efectiv os para "otros ", es decir,
cualquiera que no sea el propietario o pertenezca al g rupo de propietarios. E n este
caso no tendrían ning ún permiso efectiv o sobre el archiv o.

Así pues, cada g rupo de tres caracteres representa los permisos efectiv os del
propietario, el g rupo y otros.

E l sig uiente campo de los nuev e que nos interesa es el tercero. E se campo nos
dice quién es el propieta rio del archiv o en cuestión, en este caso root.

E l cuarto campo corresponde al g rupo propietario del archiv o, en este caso root.

E l quinto campo nos dice el tam año del archiv o en by tes.

E l resto de campos se corresponden con la fecha y la hora en la que el archiv o fue

modificado por última v ez.

Administración de sistemas de software libre 23

 L e c ció n 2
Co m a nd o s d e m o d ific a c ió n d e p erm is o s

Todos los usuarios cuando crean cualquier archiv o en el sistema se crea con unos
permisos determinados. E stos permisos v ienen dados por la llamada "máscara" que
se aplica a los usuarios. E sta máscara se puede definir en el fichero / etc/ profile
para que la usen todos los usuarios del sistema o bien podemos asig narla sólo al
usuario que deseemos a adiendo la opción um as k en el fichero .bas hrc_ profile
que se encuentra en el directorio home de cada usuario. S u función es quitar a los
ficheros y directorios, los permisos que le hay amos especificado.

Los directorios tienen permisos 777 y los ficheros 666, de tal forma que si para un
usuario tenemos una máscara 022, los permisos efectiv os que tendrían los
directorios que creara serían 775 y ficheros 664.

Podemos cambiar la máscara que está usando el usuario en ese momento mediante
el comando um as k, por ejemplo, ejecutar umask 077 en la sesión de fernando
haría que todos los ficheros creados a partir de ese momento por el se crearan con
permisos 600 y todos los directorios con permisos 700. E ste cambio sólo duraría
mientras el usuario esté conectado, para hacer el cambio permanente tendríamos
que modificar los ficheros nombrados anteriormente ( /etc/profile o . bashrc_ profile
seg ún nuestras necesidades)

Para modificar los permisos de los archiv os tenemos el comando chm od que puede
ser usado de dos formas: mediante notación binaria o mediante el uso de
caracteres.

E l comando se construy e de la sig uiente forma:

chm od perm is os directorio/ archiv o opciones

S i nos decidimos a usar el comando mediante el uso de caracteres hay que seg uir
el patrón us ua rio acción perm is os

u ? Usuario propietario del archiv o.

g ? Grupo propietario del archiv o.
o ? Otros usuarios.
a ? Todo el mundo.
+ ? A adir permisos.
- ? Quitar permisos.
= ? S ólo deja ese permiso.
r ? Permiso de lectura.
w ? Permiso de escritura.
x ? Permiso de ejecución.

Administración de sistemas de software libre 24

Por ejemplo, si quisiéramos darle permisos a otros de lectura y ejecución sobre el
directorio "v irtual- root.eflZ cm", el comando quedaría así:

chm od o+ rx v irtua l- root.eflZ cm /

Ahora si hacemos un ls - l:

V amos a quitarle los priv ileg ios recién otorg ados al directorio usando - en lug ar de
+:

chm od o- rx v irtua l- root.eflZ cm /

S i por el contrario preferimos trabajar en binario con el comando chmod deberemos

hacerlo de la sig uiente forma:

Lo primero que hay que tener claro es que cada g rupo de tres caracteres
representa los permisos efectiv os del propietario, del g rupo y de otros
respectiv amente, por lo tanto cada g rupo de tres será tratado independientemente.

Los v alores en binario corresponden a los sig uientes:

0 ?_ _ _
1 ?_ _ x
2 ?_ w _
3 ?_ w x
4 ?r_ _
5 ?r_ x
6 ?rw _
7 ?rw x

C ada g rupo de tres deberá tener un v alor comprendido entre 0 y 7 incluidos a la

hora de establecer los permisos.

Así por ejemplo, si quisiéramos asig nar todos los permisos al propietario, lectura y
ejecución al g rupo y lectura y ejecución a otros sobre el fichero v irtual- root.ef1Z cm
quedaría de la sig uiente forma:

chm od 7 5 5 v irtual- root.eflZ cm /

Mostrando los permisos:

Administración de sistemas de software libre 25

S i quisiéramos dejarle los permisos como estaban, es decir, que el g rupo y otros no
tuv ieran ning ún priv ileg io, se haría de la sig uiente forma:

chm od 7 0 0 v irtual- root.ef1 Z cm /

Alg unos de los parámetros que se le pueden pasar a chmod son:

- R ? C ambia recursiv amente los permisos de los archiv os y directorios que

hay a debajo del directorio seleccionado.
- v ? S aca una descripción de las acciones tomadas sobre cada fichero.
- c ? Muestra una descripción de los ficheros a los que les hay an cambiado
los permisos realmente.

Para modificar el usuario propietario de un archiv o existe el comando chow n

chow n us ua rio archiv o

Alg unos de los parámetros que se le pueden pasar a chmod son:

- R ? C ambia recursiv amente el propietario de los archiv os y directorios que

hay a debajo del directorio seleccionado.
- v ? S aca una descripción de las acciones tomadas sobre cada fichero.
- c ? Muestra una descripción de los ficheros a los que les hay a cambiado
propietario realmente.

Así pues, si quisiéramos cambiar el propietario del archiv o " v irtual- root.ef1Z cm"
para que el nuev o fuera pepe, usaríamos el sig uiente comando:

chow n pepe v irtua l- root.ef1 Z cm /

Haciendo un ls - l:

V olv emos a dejarlo como estaba:

chow n root v irtua l- root.ef1 Z cm /

También podemos modificar el g rupo propietario de un archiv o mediante el

comando chg rp

chg rp g rupo directorio/ a rchiv o

Alg unos de los parámetros que se le pueden pasar a chmod son:

- R ? C ambia recursiv amente el g rupo propietario de los archiv os y

directorios que hay a debajo del directorio seleccionado.
- v ? S aca una descripción de las acciones tomadas sobre cada fichero.

Administración de sistemas de software libre 26

 - c ? Muestra una descripción de los ficheros a los que les hay a cambiado
g rupo propietario realmente.

C ambiemos, por ejemplo, el g rupo propietario del fichero v irtual- root.ef1Z cm a

"pepe":

chg rp pepe v irtual- root.ef1 Z cm /

Dejémoslo como estaba:

chg rp root v irtua l- root.ef1 Z cm /

Podemos cambiar el propietario y el g rupo propietario a la v ez mediante el

comando chown. Por ejemplo si quisiéramos cambiar el propietario y el g rupo del
fichero v irtual- root.ef1Z cm por pepe en ambos casos:

chow n pepe: pepe v irtua l- root.ef1 Z cm /

Lo dejamos como estaba:

chow n root: root v irtual- root.ef1 Z cm /

E n lug ar de usar el nombre de los usuarios también podríamos utilizar su UID y GID
respectiv amente.

Administración de sistemas de software libre 27

 L e c ció n 3
P erm is os es p ecia les

Además de los permisos mencionados anteriormente existen otros permisos menos

comunes pero que aportan ciertas funcionalidades.

S ticky bit

E l primero de ellos es el "S ticky bit".

C uando el stick y bit está habilitado en un determinado

directorio, todos los archiv os que hay a dentro de ese directorio
sólo podrán ser eliminados por el usuario que los hay a creado.

E sto ev ita el problema de que cualquier usuario con permisos de

escritura sobre un directorio pueda eliminar estos archiv os.

Para habilitar el stick y bit hay que a adir un 1 a los permisos normales.

Por ejemplo, creamos un directorio que se llame sticky en /tmp:

m kdir / tm p/ s ticky

A continuación le asig namos permisos 755 al directorio y le asig namos el 1 del

stick y bit:

chm od 1 7 5 5 / tm p/ s ticky

Ahora si miramos los permisos del directorio:

ls - l / tm p/ s ticky

C omprobamos que aparece una "t" en lug ar de la x de ejecución en los permisos.

A partir de ahora sólo el propietario de los archiv os creados en ese directorio podrá
borrarlos.

Administración de sistemas de software libre 28

B it s g id

E l seg undo tipo de permiso especial es el "bit s g id".

E l bit sg id se utiliza para establecer directorios colaborativ os. C uando un directorio

tiene el bit sg id habilitado, cualquier archiv o que se cree dentro de él pertenecerá al
g rupo propietario del directorio y no al del creador.

Para habilitarlo basta con a adir un 2 a los permisos normales.

V amos a habilitar el bit sg id en el directorio sticky :

chm od 2 7 5 5 / tm p/ s ticky

Ahora mostramos los permisos:

ls - l / tm p/ s ticky

S e aprecia cómo ha desaparecido la "t" del stick y bit y ahora en los permisos del
g rupo aparece una "s" en lug ar de la x de ejecución. Ahora todos los archiv os que
se creen dentro del directorio sticky pertenecerán al g rupo propietario del
directorio, es decir, root.

B it s uid

E l último tipo de permiso especial es el "bit s uid".

C uando un archiv o tiene habilitado el bit suid, cualquiera que ejecute dicho archiv o
lo hará con los mismos priv ileg ios que el creador del mismo. Hay que tener mucho
cuidado con este permiso porque por ejemplo, si el administrador crear un archiv o
y le asig na el bit suid, cualquiera que pueda ejecutar ese archiv o lo hará con los
mismos priv ileg ios que el administrador.

Para habilitarlo basta con a adir un 4 a los permisos normales.

V amos a crear un archiv o en /tmp llamado suid:

touch / tm p/ s uid

A continuación le asig namos el bit suid:

chm od 4 7 5 5 / tm p/ s uid

Administración de sistemas de software libre 29

Comprobamos los permisos:

ls - l / tm p/ s uid

C omprobamos que aparece una s en lug ar de la x de ejecución en los permisos del

propietario.

Administración de sistemas de software libre 30

 L e c ció n 4
El comando sudo

E n ocasiones es necesario proporcionar acceso a ciertas funciones del sistema

propias del usuario root a otros usuarios que, de otra forma, no podrían ejecutar.

S udo proporciona acceso a otros usuarios a comandos sólo accesibles por root.

Por ejemplo, si el usuario crear usuarios, intentaría ejecutar sudo / usr/ sbin/ useradd
obteniendo el siguiente resultado tras introducir su contrase a:

Para otorg ar priv ileg ios mediante el comando sudo a los distintos usuarios, existe el
fichero / etc/ s udoers . Podemos modificar dicho fichero mediante el editor de texto
que prefiramos sin embarg o, la modificación suele realizarse mediante el comando
v is udo el cual lo edita con el editor por defecto que debería ser v i.

Es recomendable utilizar el mandato visudo debido a que tiene dos grandes ventajas:

Cuando se edita el fichero lo bloquea de tal manera que no pueda haber dos
personas a la vez modificándolo y por lo tanto uno modifique el trabajo del otro.
Una vez guardado el fichero, visudo comprueba la sintaxis del mismo y si detecta
algún error en la misma no deja salir de él hasta que ha sido subsanado.

E l contenido del fichero sería como este:

Administración de sistemas de software libre 31

S e pueden definir priv ileg ios en el fichero /etc/sudoers sig uiendo el sig uiente
patrón:

us uario hos t= com ando/ s

S i quisiéramos que el usuario pepe pudiera crear usuarios, editaríamos el fichero de

la sig uiente forma:

v is udo

y a adiríamos la sig uiente línea:

pepe A L L = / us r/ s bin/ us era dd

Log ueamos con el usuario pepe y probamos a crear un usuario:

s u - pepe

s udo / us r/ s bin/ us eradd pruebas udo

cat / etc/ pas s w d

C on el objetiv o de ag ilizar la tarea podemos definir alias .

Para crear un alias de usuarios usaríamos la sig uiente sintaxis:

U s er_ alias NOMB R E _ D E L _ A L I A S = U s ua rios

Para crear un alias de host:

H os t_ alias NOMB R E _ D E L _ A L I A S = hos ts

Finalmente, para crear un alias de comandos:

Cm nd_ a lias NOMB R E _ D E L _ A L I A S = com a ndos

Administración de sistemas de software libre 32

 L e c ció n 5
L is ta s d e a cces o o A CL S

E n ocasiones, los permisos tradicionales que se le asig nan a los distintos archiv os
se quedan cortos y es necesaria una may or g ranularidad. C uando queremos
otorg arles priv ileg ios a otros usuarios sobre un archiv o sin tener que recurrir al
g rupo "otros" necesitamos utilizar las AC LS .

Para que nuestro sistema trabaje con ACLS es necesario que la partición en
cuestión esté montada con esa opción.

¡ P onte a prueba!

V amos a habilitar las AC LS en nuestro sistema para poder trabajar con ellas,
para ello habrá que modificar la config uración del fichero /etc/fstab, a adir la
opción y v olv er a montar la partición.

Lo primero que hay que hacer es, ig ual que se hizo con las cuotas, modificar el
fichero /etc/fstab y a adir la opción de las ACLS :

joe / etc/ fs tab

Una vez que hemos agregado la opción, montamos de nuevo la partición:

m ount - a

Ahora y a podremos utilizar AC LS en nuestro sistema.

E xisten dos tipos de AC LS , de acces o y por defecto. Una AC L de acceso es la que

controla un directorio o archiv o específico. Una AC L por defecto sólo puede
establecerse en un directorio. S i los archiv os dentro del directorio no tienen una
AC L, usarán la AC L por defecto.

E l comando para establecer una AC L es s etfacl, su sintaxis es la sig uiente:

s etfacl pa rá m etros reg las ficheros

Alg unos de los parámetros que se le pueden pasar son:

- m ? Modifica o a ade una AC L al directorio o archiv o.

- b ? E limina cualquier AC L que existiera en el directorio o archiv o.
- d ? Modifica la AC L por defecto el directorio.
- R ? Aplica los cambios de manera recursiv a los subdirectorios y archiv os.

Administración de sistemas de software libre 33

 - k ? E limina la AC L por defecto.
- x ? S e eliminan los permisos de un usuario, g rupo o de otros.

La parte de las reg las debe ser de la forma:

u: us ua rio: perm is os ? E stablece la ACL para un determinado usuario. S e puede

especificar tanto su nombre como su UID.

g : g rupo: perm is os ? E stablece la AC L para un g rupo dado. S e puede especificar

tanto el nombre del g rupo como su GID.

o: perm is os ? E stablece la AC L para los demás usuarios.

Para poder comprobar si un archiv o o directorio tiene una AC L aplicada tenemos el

comando g etfa cl, que tiene la sig uiente sintaxis:

g etfacl pará m etros directorio o archiv o

Al comando g etfacl se le pueden pasar, entre otros, los sig uientes parámetros:

- d ? Muestra la AC L por defecto

- R ? Lista recursiv amente las AC LS de todos los directorios y archiv os.

Para más parámetros, como siempre, m a n g etfa cl

Para v er cómo funcionan las AC LS , creamos un archiv o llamado "prueba" en /tmp

con la cuenta de root:

touch / tm p/ prueba

Miramos los permisos que tiene el archiv o recién creado:

cd / tm p

ls - l

C omprobamos que el usuario es root y el g rupo también es root.

E l usuario pepe entraría en el g rupo "otros" y por lo tanto sólo podría leer el archiv o
creado por root.

V amos a hacer que pepe teng a permiso de escritura sobre el archiv o mediante una
AC L:

s etfacl - m u: pepe: rw prueba

Administración de sistemas de software libre 34

Ahora comprobamos cómo ha quedado la ACL:

g etfacl prueba

E l comando anterior debería producir una salida similar a la sig uiente:

E n donde comprobamos que pepe tiene permisos tanto de lectura como de

escritura.

S i listamos los permisos ahora:

ls - l

V eremos que junto a los permisos efectiv os aparece el símbolo "+ " lo que indica
que se está usando una AC L.

Así pues, le hemos proporcionado permisos a pepe además de a root sin tener que
meterlo en el saco de "otros".

Administración de sistemas de software libre 35

 Ca p ítulo 3
Ges tión de paquetes

La g estión de paquetes es una tarea habitual de cualquier administrador de

sistemas, saber en todo momento qué estamos instalando y qué repercusiones v a a
tener sobre lo que y a se encuentra instalado es esencial. E n este capítulo
aprenderemos a g estionar los paquetes con los g estores de las distribuciones
C entos y Ubuntu.

Al finalizar el estudio de estas lecciones serás capaz de:

Gestionar paquetes mediante las herramientas rpm y y um de C entos.

Gestionar paquetes mediante las herramientas dpkg , aptitude y sy naptic de

Ubuntu.

Instalar las actualizaciones disponibles para el sistema mediante cualquiera

de los g estores citados anteriormente.

Administración de sistemas de software libre 36

 L e c ció n 1
I ntroducción

E n linux, los prog ramas se instalan a trav és de un conjunto de paquetes. E stos

paquetes incluy en todo tipo de archiv os ( librerías, ejecutables, pág inas de manual y
otra documentación) y son instalados mediante una serie de herramientas que
v arían seg ún la distribución en la que estemos trabajando.

Normalmente los paquetes se encuentran se encuentran alojados en serv idores en

internet, son los llamados repos itorios . Los repositorios oficiales de cada
distribución v ienen config urados por defecto para que cualquier usuario pueda
descarg arse el software seg ún sus necesidades y además podemos a adir otros
repositorios no oficiales si lo deseamos.

E stos paquetes pueden ser el propio códig o fuente de los prog ramas o paquetes
específicos para nuestra distribución listos para ser instalados. S i nos descarg amos
el códig o fuente de un prog rama hará falta compilarlo para que este funcione.
C ompilar consiste en procesar un fichero con div ersas órdenes mediante un
leng uaje de prog ramación como C o Py thon para g enerar un fichero que pueda ser
procesado por el sistema. Para que la tarea resulte más sencilla, normalmente
estos paquetes v ienen con un fichero llamado R E ADME o INS T ALL en el cual se
detallan las instrucciones necesarias para llev ar a cabo la instalación.

E l otro tipo de paquetes, los que se descarg an específicamente para cada

distribución suelen llev ar una extensión .rpm, .deb, etc seg ún la distribución que
usemos y son g estionados e instalados por unas herramientas específicamente
pensadas para ello lo que conv ierte la tarea en alg o muy sencillo.

E l problema que ha existido siempre a la hora de instalar paquetes ha sido las

dependencias que existen entre los distintos paquetes. E s posible que nosotros
queramos instalar cierto software y para ello necesitemos un paquete, pero para
que funcione, ese paquete necesita de otro paquete del cual depende y así
sucesiv amente.

E sta tarea puede suponer un g ran problema para el usuario porque necesita de una
atención constante y resolv er las dependencias no siempre resulta sencillo. Para
solucionar esto, existen las herramientas de g estión de paquetes que, hoy en día,
resuelv en las dependencias sin ning ún problema facilitando enormemente la labor
al usuario.

Aquí nos v amos a centrar en los g estores de paquetes que utilizan C entos ( basado
en R ed Hat Linux) y Ubuntu ( basado en Debian) y más concretamente en los
paquetes preparados explícitamente para cada distribución, dejando a un lado los
que necesitan ser compilados a partir del códig o fuente.

Por parte de Centos v amos a nombrar R PM y Yum mientras que por parte de
Ubuntu v amos a citar dpk g , aptitude y el g estor de paquetes S y naptic.

Administración de sistemas de software libre 37

 L e c ció n 2
Ges tor de paquetes R P M

R PM ( R ed Hat Packag e Manag er) fue desarrollado por R ed Hat

para su distribución R ed Hat Linux pero su buen
funcionamiento hizo que fuera adoptado rápidamente por
otras distribuciones como S uS E . R PM se utiliza para instalar,
desinstalar, actualizar y v erificar prog ramas localmente.

La estructura de un paquete rpm es la sig uiente:

paquete- v ers ion- releas e- arquitectura.rpm

V ers ión: Número que identifica el estado de desarrollo de un

paquete.

R eleas e: Cambios en el paquete ( actualizaciones, soluciones a

problemas de seg uridad…)

A rquitectura : Procesador y otros componentes físicos sobre los que trabaja

nuestro sistema.

Normalmente, dentro de cada paquete hay archiv os binarios, documentación,

ficheros con config uraciones por defecto, log de los cambios sobre el paquete…

Para llev ar a cabo la tarea de instalación, realiza una serie de operaciones como
son:

V erificar las dependencias de los paquetes que deseamos instalar, de tal

manera que si el paquete que v amos a instalar necesita de otro, nos av isa
de que para instalarlo necesitamos tener prev iamente el otro.
C omprueba los posibles conflictos entre paquetes como por ejemplo que
estemos instalando una v ersión más v ieja de un paquete que y a tenemos
instalado.
A la hora de instalar una v ersión nuev a reemplaza los archiv os de ese
paquete salv o los de config uración. S i el archiv o de config uración que existe
actualmente ha sido modificado con respecto al orig inal, R PM lo deja como
está. S i el archiv o no fue modificado lo reemplaza con el nuev o que se acaba
de descarg ar. S i el nuev o archiv o nuev o necesita ser instalado, el archiv o de
config uración existente se renombra a .rpmsav e o .rpmnew
E xtrae los archiv os del paquete y lo ubica en el sitio correcto dentro del
sistema asig nando además los priv ileg ios necesarios para que funcionen
correctamente.
Guarda una traza de todas las operaciones que se han hecho con los
paquetes de manera que estas pueden ser consultadas posteriormente.

Administración de sistemas de software libre 38

A la hora de eliminar paquetes:

Comprueba que ning ún otro paquete dependa de ese y de ser así elimina el
paquete.
R ev isa los archiv os pertenecientes a ese paquete y si no son usados por
ning ún otro paquete los elimina.
E limina cualquier traza que pueda quedar de ese paquete en la base de
datos R PM.

E l uso de rpm es muy sencillo, la sintaxis del comando es la sig uiente:

rpm parám etros nom bre de pa quete

- i ? Instala el paquete en cuestión

- F ? Actualiza el paquete a una v ersión más nuev a si existe una v ersión
antig ua del paquete. S i no existe una v ersión antig ua del paquete que se
está instalando, no se instalará.
- U ? S e comporta como – F si existe una v ersión antig ua del paquete a
instalar y si no se comporta como – i
- e ? E limina el paquete escog ido.
- v ? Presenta información del proceso de instalación a medida que este
av anza.
- V ? V erifica el paquete instalado comparándolo con la base de datos de
rpm y muestra las diferencias que aprecie.
- - chang elog ? Muestra información sobre los cambios que ha sufrido ese
paquetes a lo larg o del tiempo.
- - las t ? Muestra los paquetes ordenados seg ún fecha de instalación ( los
últimos primero)

T ambién podemos hacer consultas mediante los sig uientes parámetros:

- q ? Nos muestra el nombre del paquete y la v ersión.

- qa ? Nos muestra todos los paquetes instalados.
- qf ? Nos muestra el paquete propietario del archiv o especificado.
- qi ? Muestra información g eneral sobre ese paquete.
- ql ? Muestra todos los archiv os correspondientes a ese paquete.

E stas son sólo alg unas de las opciones, como siempre para más opciones consultar
la pág ina man del comando en cuestión, en este caso m a n rpm

Administración de sistemas de software libre 39

 L e c ció n 3
Ges tor de paquetes Y um

Yum ( Yellow Dog Updater Modified) es una herramienta de g estión de paquetes

para sistemas basados en R PM. Fue desarrollada con la intención de resolv er las
dependencias que R PM no podía solucionar. E s una herramienta que se utiliza
mediante línea de comandos, sin embargo hay una serie de aplicaciones como
“pup” o “y umex” que lo otorg an de una interfaz g ráfica simplificando bastante su
uso.

R ealiza las tareas de instalación, desinstalación y actualización de paquetes al ig ual

que R PM pero resuelv e las dependencias haciendo el proceso de instalar software
mucho más sencillo. A la hora de instalar un paquete, y um comprobará si ese
paquete necesita de otros y en caso afirmativ o los instalará.

Lo mismo pasa a la hora de desinstalar software. Yum comprobará si alg ún otro

paquete se instaló como dependencia del que se está desinstalando y en caso
afirmativ o, si ning ún otro paquete necesita de esos otros paquetes los desinstalará.
E n caso de que alg uno de esos paquetes sea usado por otro paquete, no se
desinstalará.

Podemos a adir nuev os repositorios a los y a existentes en la red. E sto se consig ue

a adiendo un nuev o archiv o en / etc/ y um .repos .d/ con el mismo formato que los
que y a se encuentran en ese directorio. S i mostramos el contenido de uno por
ejemplo, v eremos seg mentos como el sig uiente:

T anto el campo que v a entre corchetes como “name” indican descripciones del
nuev o repositorio. E n baseurl podemos especificarle la ubicación física del
repositorio. E n este caso se trata de uno local, pero podríamos especificarle una
dirección en internet mediante una UR L o bien un ftp. E l campo g pg check indica si
se debe comprobar que los paquetes estén firmados dig italmente, si es 1 se
comprobará, si no no. E l campo enabled establece si el repositorio está habilitado o
no, si está a 1 estará habilitado y si está a 0 deshabilitado.

Además de los repositorios ex istentes en la red, y um nos permite crear nuestros

propios repositorios. Podemos crear un directorio que conteng a los paquetes,
hacerlo accesible v ía http o ftp e instalando el paquete “ createrepo”, hacer que
ese directorio teng a los ficheros necesarios para funcionar.

Administración de sistemas de software libre 40

La sintaxis de y um es la sig uiente:

y um pa rám etros acción nom bre del paquete

Alg unas de las acciones que se le pueden pasar son las sig uientes:

ins tall ? Instala el paquete seleccionado.

localins tall ? Instala el paquete desde un repositorio ubicado en el sistema
local.
g roupins tall nom bre del g rupo de pa quetes ? Instala el g rupo de
paquetes seleccionado. Un g rupo de paquetes es un conjunto de software
que aporta ciertas funcionalidades como por ejemplo funciones de
impresión.
rem ov e nom bre de pa quete ? E limina el paquete especificado.
update nom bre del paquete ? Busca actualizacones del paquete
especificado. E n el caso de no especificar ning ún paquete, busca
actualizaciones de todos.
lis t ( ins talled|av ailable|updates ) ? lista los paquetes instalados,
disponibles o las actualizaciones seg ún se le especifique.
s earch patrón de paquete ? Lista todos los paquetes que se ajusten al
patrón establecido.
info nom bre del pa quete ? Muestra información detallada del paquete en
cuestión.

Alg unos de los parámetros serían los sig uientes:

- y ? E specifica la opción y es por defecto antes de instalar un paquete.

- q ? No muestra el prog reso en pantalla.
- v ? Muestra el prog reso de manera más detallada.

¡ P onte a prueba!

V amos a dotar a y um de un entorno g ráfico para hacer que sea más fácil
trabajar con el. Para ello v amos a instalar el paquete y umex.

Nos abrimos una terminal desde la propia máquina o accedemos v ía

putty a la máquina C entos. V amos a decirle a y um que busque
paquetes relacionados con y umex:

y um s earch y um ex

Administración de sistemas de software libre 41

 Después de buscar, nos dice que ha encontrado un paquete con esas características
llamado “yumex.noarch” y nos dice que es una extensión gráfica para yum.

S i quisiéramos más información sobre el paquete:

Y um info y um ex .noarch

C omo se puede apreciar, aparece el tama o, la release, la UR L…

Procedemos a instalar el paquete:

y um ins tall y um ex - noarch

Conforme avance la instalación nos avisará del progreso y llegado un determinado punto
nos mostrará las dependencias de ese paquete y el tama o que va a ocupar entre otras
cosas. También nos preguntará si deseamos instalar lo, le damos a “y” y al enter.

Administración de sistemas de software libre 42

 Ya tenemos instalado el paquete en nuestra máquina.

Ahora v amos a iniciar el terminal de la máquina v irtual para probarlo.

E scribimos “ y um ex ” en el terminal y nos aparecerá la sig uiente pantalla.

E n la barra de arriba escribiremos el prog rama que queramos buscar. Una v ez

eleg ido, lo seleccionaremos mediante el correspondiente checkbox y le
daremos a “procesar cola” con lo que se instalará.

Administración de sistemas de software libre 43

 L e c ció n 4
Ges tor de paquetes dpkg

Dpkg ( abrev iatura de Debian Packag e) es el sistema de g estión de

paquetes creado por el proy ecto Debian en el a o 1993. E l g estor es
utilizado para instalar, desinstalar y manipular los paquetes .deb

E s la base de los sistemas g estores de paquetes para sistemas

basados en Debian y es en sí misma una herramienta de bajo niv el
que precisa de otras más av anzadas como apt para traer los
paquetes desde sitios remotos y resolv er las dependencias que
existen entre los distintos paquetes.

A la hora de instalar un paquete realiza los sig uientes pasos:

E xtrae los ficheros de control del nuev o paquete.

S i existe otra v ersión del mismo paquete en el sistema se ejecuta un script
de pre- eliminación del antig uo paquete.
S e ejecuta el script de pre- instalación del nuev o paquete.
S e desempaquetan los nuev os ficheros y se crea una copia de seg uridad de
los antig uos por si la instalación fallara.
S i existiera otra v ersión del paquete que se está instalado se ejecuta el
script de post- eliminación del paquete antig uo.
S e config ura el nuev o paquete.

La sintaxis del comando dpkg es la sig uiente:

dpkg pa rám etros acción nom bre de paquete

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- B ? Desconfig urará los paquetes que dependan del paquete eliminado.

- G ? No instala un paquete del que y a existe una v ersión más nuev a en el
sistema.
- E ? E v ita la instalación de un paquete si la v ersión que se está instalando
es la misma que la que y a está instalada.

Alg unas de las acciones que se le pueden pasar son las sig uientes:

- i ? Instala el paquete especificado.

- r ? E limina el paquete y todos sus archiv os, excepto los de config uración.
E sto puede ser útil si se instala más tarde el mismo paquete.
- P ? E limina el paquete y todos sus archiv os incluidos los archiv os de
config uración.

Administración de sistemas de software libre 44

 - l ? Lista todos los paquetes instalados en el sistema.
- L ? Muestra los ficheros instalados en el sistema que pertenecen al
paquete especificado.

Administración de sistemas de software libre 45

 L e c ció n 5
Ges tor d e p a q uetes a p titud e

Apt ( Adv anced Packag ing T ool) es un sistema de g estión de paquetes que nació
g racias al proy ecto Debian. R ealmente apt no es un prog rama en sí sino un
conjunto de funciones en C+ + que es utilizado por otros prog ramas en la tarea de
distribución de paquetes. Uno de estos prog ramas es apt- g et, una herramienta que
permite instalar, desinstalar y actualizar el software mediante una serie de
comandos. Apt- g et fue muy utilizado en su momento pero actualmente se está
v iendo reemplazado por otras herramientas de mejor funcionamiento como es
aptitude.

Aptitude es una herramienta de g estión de paquetes basada en apt- g et pero que

incorpora un entorno g ráfico que hace que la tarea de instalación de paquetes
resulte mucho más sencilla sobre todo a usuarios sin g randes conocimientos.
Aptitude utiliza apt para realizar estas tareas y para llev arlas a cabo mantiene
actualizada la lista de paquetes de debian que se encuentran en los repositorios en
internet.

La mejor v irtud de aptitude es, que a diferencia de apt- g et, g estiona de manera
eficaz las dependencias existentes entre los distintos paquetes de tal forma que si
al instalar un paquete, este depende de otro, lo instalará de manera automática.
E sta v entaja se aplica también a la hora de desinstalar software.

Los repositorios utilizados tanto por aptitude como apt- g et se encuentran en el

archiv o / etc/ apt/ s ources .lis t y es aquí donde podemos a adir nuev os
repositorios no oficiales a los y a existentes.

C omo se aprecia en ese archiv o, hay v arios tipos de repositorios:

Main: Aquí se encuentra el software libre con actualizaciones de seg uridad y

soporte por parte de Ubuntu.
U niv ers e: C ontiene software sin ning ún tipo de soporte que es desarrollado
por la comunidad. S i consig uen el apoy o de desarrolladores que se
encarg uen de mantenerlo actualizado y de proporcionar soporte puede lleg ar
a pasarse al repositorio univ erse.
Multiv ers e: Licencias no necesariamente libres. E s responsabilidad del
usuario cumplirlas.
R es tricted: S oftware de pag o que usualmente es mantenido por Ubuntu.

Para instalar software mediante línea de comandos se utiliza la sig uiente sintaxis:

aptitude pa rá m etros acción nom bre de pa quete

Administración de sistemas de software libre 46

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- f ? Intenta arreg lar las dependencias de paquetes “rotos”

- r ? Trata las recomendaciones como dependencias a la hora de instalar
paquetes nuev os.
- s ? S imula las acciones introducidas en la línea de comandos sin llev arlas a
cabo realmente.
- d ? Descarg a los paquetes pero no los instala ni los elimina.

Alg unas de las acciones que se le pueden pasar son las sig uientes:

ins tall ? Instala el paquete eleg ido.

rem ov e ? E limina el paquete eleg ido y todas las dependencias que no sean
usadas por otro paquete en el sistema.
update ? Actualiza la lista de paquetes disponibles desde los repositorios.
s earch ? Busca paquetes que coincidan con el patrón de paquete
especificado.
s how ? Nos muestra información sobre el paquete en cuestión.

Además de usar aptitude mediante la línea de comandos, podemos usarlo como

herramienta g ráfica escribiendo aptitude tras lo cual aparecerá lo sig uiente:

Una v ez en esta pantalla podremos pinchar con el ratón en los diferentes menús
que aparezcan hasta dar con el paquete que buscamos y cuando queramos
instalarlo pulsaremos “g ”.

Administración de sistemas de software libre 47

E n la v entana de abajo aparece la descripción sobre el paquete o g rupo de
paquetes que estemos instalando. Las opciones manejadas por este g estor
g ráficamente son muchas e implican bastante complejidad, normalmente
utilizaremos la línea de comandos antes que la interfaz g ráfica.

Administración de sistemas de software libre 48

 L e c ció n 6
Ges tor de paquetes S y naptic

E l g estor de paquetes S y naptic es una herramienta muy potente con interfaz

g ráfica que permite instalar, actualizar y desinstalar paquetes de forma muy
sencilla y que resuelv e las dependencias entre los distintos paquetes de forma
eficaz.

S u interfaz g ráfica ofrece mucha información sobre los paquetes y aseg ura un
control total de los mismos.

Para acceder a la aplicación hay que ir a S istema?Administración?Gestor de

paquetes S y naptic:

Una v ez hecho esto, se nos presentará la pantalla principal del g estor.

E n el panel de arriba a la izquierda tenemos las distintas secciones referentes a

paquetes que podemos instalar. E n la parte de abajo a la izquierda aparece la
sección de filtros que podemos aplicar a la búsqueda de paquetes.

Administración de sistemas de software libre 49

E n la parte superior podremos hacer búsquedas de paquetes en el cuadro
“búsqueda rápida” y justo debajo v eremos los paquetes que pertenecen a la
sección que hay amos seleccionado en el cuadro de la izquierda.

E n el panel de abajo podemos v er una descripción detallada del paquete que

teng amos seleccionado.

Los paquetes que tienen un icono de color v erde sig nifica que y a se encuentran
instalados en nuestro sistema. Así pues, para instalar paquetes sólo tenemos que
seleccionarlos, hacer doble clic o botón derecho “marcar para instalar” y una v ez
que teng amos seleccionados todos los que necesitamos darle a aplicar en la parte
superior de la v entana.

E s aconsejable darle al botón de “recarg ar” primero con el fin de que el g estor
teng a disponibles las últimas v ersiones de todos los paquetes.

Antes de instalar un paquete, el g estor nos av isa si el paquete seleccionado tiene

dependencias:

Dándole a “Marcar” aceptaremos la lista de paquetes.

Ahora si le damos a “aplicar” aparecerá una v entana con el resumen del proceso
que se v a a realizar:

Administración de sistemas de software libre 50

Para actualizar un paquete basta con seg uir el mismo procedimiento.
S eleccionaremos un paquete que dispong a de una v ersión superior en el repositorio
y seleccionaremos “marcar para actualizar”. Una v ez marcado le daremos a aplicar
y comenzará el proceso de actualización.

Para desinstalar un paquete seg uiremos el mismo procedimiento, marcaremos los

paquetes que deseemos eliminar, haremos botón derecho “marcar para desinstalar”
y una v ez que hay amos eleg ido todos los paquetes que deseemos eliminar le
daremos a aplicar para que lo/s elimine. S i hay alg ún paquete que dependa de los
que estamos instalando y no hay ning ún otro en el sistema que los necesite, se
desinstalará también.

Administración de sistemas de software libre 51

 Ca p ítulo 4
P roces os y s erv icios

La correcta g estión de los procesos y los serv icios puede ser v ital para que un
sistema no v ay a saturado en cuanto a la utilización de sus recursos. S i tenemos
demasiados procesos ejecutándose, la máquina funcionará muy lenta y por lo tanto
perderemos rendimiento. E n este capítulo v eremos la g estión de procesos y
serv icios mediante diferentes comandos que ay udarán a monitorizar el rendimiento
de la máquina y a habilitar únicamente los serv icios necesarios.

Al finalizar el estudio de estas lecciones serás capaz de:

Monitorizar el consumo de los recursos del sistema.

Obtener información sobre los procesos que se están ejecutando.

Iniciar y detener procesos seg ún las necesidades.

Comprobar el estado de los serv icios del sistema.

Iniciar y detener serv icios seg ún las necesidades.

Administración de sistemas de software libre 52

 L e c ció n 1

Los procesos

C uando trabajamos con cualquier tipo de sistema operativ o, cualquiera de los

objetos que se nos presentan en pantalla, están ahí g racias a que hay uno o v arios
procesos que se están ejecutando. Así pues, un proceso no es más que un
prog rama en ejecución. S in estos procesos en constante ejecución, sería imposible
poder manejar el sistema operativ o.

E n Linux, los procesos se ejecutan de una forma jerárquica, esto quiere decir que
existe un proceso padre que lanza cada proceso hijo. E n Linux el proceso padre es
el init debido a que este es el primero que se ejecuta cuando arranca el sistema.
C uando se termina un proceso padre, se terminan también los procesos hijos que
dependen de el.

Linux es un sistema multitarea, lo cual quiere decir que puede ejecutar muchos
procesos a la v ez sin que unos interfieran con otros. S i quisiéramos ejecutar un
mismo prog rama desde v arios equipos a la v ez, se g enerarían tantos procesos
como equipos están ejecutando el programa. Un prog rama es un conjunto de
comandos almacenados en un fichero ejecutable y que g enera uno o v arios
procesos cuando es utilizado.

Cada proceso v a identificado mediante un indicador único que lo disting ue

unív ocamente del resto, a este identificador de proceso se le llama P I D .

E xisten dos tipos de procesos:

P roces os de us uario: E s un proceso iniciado por un usuario que ha hecho

log in mediante una terminal o mediante el entorno g ráfico.
P roces os dem onio ( daem on) : E s un proceso del sistema que no ha sido
iniciado por ning ún usuario y espera a que ocurra un ev ento ( una conexión a
trav és de la red por ejemplo) para ejecutar una determinada acción.

Administración de sistemas de software libre 53

 L e c ció n 2
Com a ndos de g es tión de proces os

S i ejecutamos el comando top, v eremos, de manera dinámica, los procesos que se

están ejecutando y , entre otras cosas, su PID:

top

Las columnas corresponden con lo sig uiente:

P I D : Identificador único de cada proceso.

U S E R : Usuario que ha lanzado el proceso.
P R : Prioridad del proceso en el sistema.
NI : V alor de “nice” del proceso. C ontra más peque o sea este número más
prioridad tiene el proceso y v icev ersa.
V I R T : Uso de memoria v irtual del proceso.
R E S : Memoria R AM que utiliza.
S H R : C antidad de memoria compartida utilizada por el proceso.
S : E stado del proceso. Puede ser:
S : sleeping
R : running
T : stopped
Z : zombie
D: uninterruptible sleep
Un proceso en estado sleep, está parado durante x tiempo y después se
despierta y sig ue ejecutándose. Un proceso en estado running se está
ejecutando. Un proceso en stop, está pausado. Un proceso en estado
zombie, es un proceso que ha completado su ejecución pero todav ía
aparece en la tabla de procesos y permite al proceso que lo ha creado leer el
estado de su salida.
Un proceso en estado uninterruptible sleep es el que no puede ser matado
de ning una forma. S uelen aparecer cuando ha habido alg ún problema a la
hora de leer de alg ún medio defectuoso.
% CP U : Porcentaje de uso de C PU.
% ME M: Porcentaje de uso de memoria.

Administración de sistemas de software libre 54

 T I ME + : Tiempo que llev a el proceso ejecutándose.
CO MMA ND : Nombre del proceso y comandos que le hay amos pasado.

Podemos modificar las columnas que muestra top pulsando “f” una v ez dentro del
comando:

También podemos modificar el orden de las columnas pulsando “o” dentro del
propio comando. Podemos salir de top pulsando “q”.

Alg unos de los parámetros que podemos pasarle a top son los sig uientes:

- d tiem po en s eg undos ? E stablece el número de seg undos que tarde en

actualizarse top. Por defecto el tiempo son 3 seg undos.
- b ? Pasa a top a modo “batch” por si deseamos redirig ir la salida a un
fichero por ejemplo.
- n núm ero de iteraciones ? Hace que top se cierre automáticamente
después de haberse refrescado el número de iteraciones que le hay amos
asig nado.

Además del PID, cuando un proceso es lanzado desde la S hell, se le asig na un J ob

ID único que lo disting ue del resto.

Los procesos pueden lanzarse en primer plano ( foreg round) o en seg undo plano
( backg round) . C uando un proceso se lanza en primer plano, este se quedará
ejecutándose hasta que acabe y , entonces, el usuario v olv erá a tener control en la
S hell. S i un proceso se ejecuta en seg undo plano, el proceso se ejecutará mientras
el usuario sig ue teniendo el control de la S hell. Podemos mandar procesos a
seg undo plano o traerlos a primer plano seg ún consideremos oportuno. Podemos
v er los procesos lanzados en 2º plano mediante j obs .

Administración de sistemas de software libre 55

S i lanzamos el proceso xey es, por ejemplo desde la terminal de nuestra máquina
v irtual:

x ey es

E ste se quedará ejecutándose en primer plano hasta que acabe. Podemos pausar el
proceso pulsando Control+ z y ahora, escribiendo bg , lanzaremos el proceso en
seg undo plano.

bg

V eremos que aparece:

E l 1 que aparece entre corchetes es el job ID y el & indica que el proceso se ha

lanzado en primer plano.

Podemos traer el proceso a primer plano de nuev o escribiendo fg y el job ID:

fg 1

T ambién podemos lanzar directamente un proceso en seg undo plano escribiendo:

Nom bre de proces o &

C on el comando ps podemos v er las características de los procesos que se están

ejecutando en ese momento en el sistema. S i no se le pasa ning ún parámetro se
v isualizan los procesos que han requerido de una terminal para ejecutarse.

La sintaxis es:

ps pa rá m etros

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

x ? V isualiza todos los procesos que se están ejecutándose en el sistema.

u ? V isualiza un formato orientado al usuario.
F ? V isualiza los procesos en forma de árbol.
- u uid us ua rio? V isualiza los procesos pertenecientes al usuario con el UID
correspondiente.
- l ? V isualiza los procesos en formato extendido.

Mediante el comando ps tree podemos mostrar los procesos ordenados en forma de

árbol facilitando así la v isión de los procesos padre e hijo y las dependencias entre
ellos.

Administración de sistemas de software libre 56

La sintaxis del comando es:

ps tree pa rá m etros

E l formato que muestra sería el sig uiente:

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- p ? Muestra los PID de los procesos.

- Z ? Muestra el contexto de seg uridad de cada proceso.
- l ? Muestra cada línea en formato larg o.
- a ? Muestra los arg umentos pasados por línea de comandos a cada
proceso.

S i queremos manipular el estado de un proceso podremos hacerlo mandándole

se ales, esto se consigue mediante el comando kill.

La sintaxis del comando es:

kill parám etros pid del proces o

C on kill – l mostramos las se ales que se le pueden pasar:

La se al por defecto es la de matar el proceso, es decir la número 9.

Administración de sistemas de software libre 57

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- p nom bre de proces o? Le dice q k ill que sólo debe mostrar los PID de los
procesos que concuerden con el nombre.
- s núm ero de s eñal ? E specifica la se al a env iar.

C on el comando killall se consig ue lo mismo que con kill sólo que en lug ar de
utilizar el PID del proceso como indicador se utilizar el nombre.

Así, si tenemos v arias instancias de Apache funcionando, por ejemplo, con el

comando k illall env iaríamos la se al a todas ellas.

La sintaxis del comando es:

killall parám etros nom bre del proces o

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- i ? Preg unta interactiv amente al usuario por cada proceso antes de

matarlo.
- s núm ero de s eñal ? E nv ía esta se al en lug ar de la de k ill.
- u nom bre de us uario ? Mata sólo los procesos que hay a lanzado el
usuario especificado.
- v ? E nse a un mensaje si la se al fue mandada con éxito.

Podemos cambiar la prioridad de un proceso con los comandos nice y renice de tal
forma que si necesitamos que un proceso en concreto pueda utilizar más recursos
le incrementaremos la prioridad.

T odos los procesos se lanzan con una prioridad por defecto de 0, sólo el usuario
root puede establecer una prioridad más alta a 0. Los v alores de la prioridad v an
desde - 20 ( que es la prioridad más alta) a 19.

Para lanzar un proceso con una determinada prioridad utilizaremos la sig uiente
sintaxis:

nice – n núm ero de prioridad com ando, prog ram a

Así pues, si quisiéramos lanzar el prog rama xey es con una prioridad de 5 en
seg undo plano lo haríamos así:

nice – n 5 x ey es

Administración de sistemas de software libre 58

De ig ual manera, para cambiar la prioridad de un proceso que y a se está
ejecutando utilizaremos renice con la sig uiente sintaxis:

renice prioridad pid, pg rp, us er

Los parámetros que se le pueden pasar son los sig uientes:

- p ? E specifica el PID del proceso al que se le v a a cambiar la prioridad.

- u ? S e le cambiará la prioridad a los procesos que poseídos por dicho usuario.
- g ? Todos los procesos del g rupo especificado v erán cómo se cambia su
prioridad.

V amos a asig narle una prioridad de 4 al proceso que y a está lanzado:

renice 4 – p 5 8 0 4

Normalmente sólo asig naremos prioridades neg ativ os a procesos que sean críticos
para el sistema en el que estemos trabajando con el fin de que siempre teng a la
máxima disponibilidad de recursos.

Otra herramienta muy útil a la hora de trabajar con procesos es ls of.

lsof nos permite saber qué ficheros están abiertos actualmente en el sistema. Cuando no
sabemos qué proceso tiene abierto un fichero, esta herramienta resulta de extrema
utilidad. Es posible que no seamos capaces de llevar a cabo una determinada acción con
un programa porque ese programa depende de un fichero que está siendo utilizado por
otro proceso. Ahí es donde juega un papel importante lsof.

La sintaxis del comando es la sig uiente:

ls of pa rám etros nom bre

donde nombre puede ser un directorio, un fichero, un puerto… seg ún el parámetro

que le pasemos.

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

+ d nom bre de directorio ? Busca los procesos que tienen abierto el

directorio pero no desciende recursiv amente por los subdirectorios.
+ D nom bre de directorio ? Busca los procesos que tienen abierto el directorio
y recursivamente todos los subdirectorios y archivos que hay por debajo.
- i ip ? Lista los archiv os que estén siendo usados por la dirección
especificada.
- p P I D ? Lista los archiv os que tienen abiertos los procesos con el PID
seleccionado.
- N ? S elecciona los archiv os NFS .

Administración de sistemas de software libre 59

Para probar el comando, creamos un directorio llamado /tmp/pruebalsof y
accedemos a él:

m kdir / tm p/ pruebals of

cd / tm p/ pruebals of

Ahora comprobamos qué está usando el directorio en cuestión:

ls of + D / tm p/ pruebals of

Otro comando muy útil a la hora de trabajar con procesos es s creen. E l comando
screen nos permite crear tantos "terminales v irtuales" como queramos, de tal
forma que podemos lanzar procesos que v an a tardar mucho rato en acabar en
estos terminales v irtuales mientras nosotros seg uimos trabajando desde la terminal
orig inal.

Además, esta herramienta tiene otra v entaja muy importante y es que, en el caso
de que perdamos la conexión con la máquina en la que estamos trabajando v ía ssh,
la terminal creada mediante screen seg uirá ejecutándose por lo que podremos
conectarnos de nuev o, recuperar esa v entana y comprobaremos que el proceso ha
seg uido ejecutándose.

Para ejecutarlo basta con escribir s creen si lo tenemos instalado. E sto nos llev ará a
la terminal v irtual en la que trabajaremos.

Alg unos de los controles de screen son los sig uientes:

control+ a+ d ? Nos desconecta de la terminal actual v olv iendo a otra

terminal v irtual en la que estuv iéramos anteriormente o a la real.
control+ a+ c ? C rea una nuev a terminal v irtual.
control+ a+ n ? C ambiar a la sig uienter terminal v irtual.
control+ a+ p ? C ambiar a la terminal anterior.
s creen - r ? S e conecta a la terminal que hay amos dejado abierta.
s creen - x núm ero de term inal ? S e conecta a la terminal v irtual que
nosotros le especifiquemos.
s creen - lis t ? Lista las terminales v irtuales que se están ejecutando en ese
momento.

Para cerrar las terminales v irtuales basta con escribir ex it.

Administración de sistemas de software libre 60

 L e c ció n 3

S erv icios

Un serv icio ( también llamado daemon) es un proceso o conjunto de procesos que

están continuamente esperando a un ev ento que desencadene una determinada
acción. Por ejemplo el serv icio ssh, que está continuamente escuchando en el
puerto 22 hasta que le entre una conexión por ese puerto y establezca el túnel con
el cliente. Otro ejemplo sería el serv idor web, que está continuamente escuchando
en el puerto 80 hasta que le entra una petición de una web y la sirv e. No puede
haber dos serv icios escuchando en el mismo puerto.

Además de los serv icios normales, existen una serie de serv icios que se necesitan
menos frecuentemente que el resto. E stos serv icios suelen estar deshabilitados de
manera predeterminada y cuando alg uien los necesita, son puestos en marcha por
un serv icio llamado x inetd.

Podemos v er los puertos que utiliza cada serv icio por defecto en el fichero
/ etc/ s erv ices :

cat / etc/ s erv ices

C uando trabajemos con serv icios, muchos de ellos estarán orientados a ofrecer una
serie de funciones a trav és de la red y , por lo tanto, utilizarán un puerto de la
máquina que deberemos tener abierto para poder dar serv icio.

Dado que la cantidad de serv icios que podemos lleg ar a tener activ os es bastante
g rande, es necesario conocer qué puertos tenemos abiertos con el fin de ev itar
alg ún posible problema de seg uridad.

Para monitorizar qué serv icios están usando cada puerto y poder comprobar las
conexiones activ as con nuestra máquina existe el comando nets ta t.

Alg unos de los parámetros que se le pueden pasar son:

- a ? Muestra todas las conexiones y los puertos en escucha de la máquina.

- c ? S aca por pantalla la información solicitada cada seg undo de manera
continua.

Administración de sistemas de software libre 61

 - n ? Muestra la IP de las máquinas en lug ar de intentar resolv er el nombre
de host al que v an asociadas.
- l ? Muestra sólo las conexiones que están escuchando en alg ún puerto.
- p ? Muestra el PID y el nombre de cada prog rama que teng a abierta una
conexión.

Los serv icios trabajan en seg undo plano y normalmente son iniciados por el propio
sistema. No utilizan ning una terminal, de ahí que al ejecutar un ps x, debajo de la
columna TTY aparezca una “? ”

ps x | g rep s s h

Los serv icios o daemon se suelen reconocer porque normalmente su nombre acaba
en “d”

Para poder administrar los serv icios, existen una serie de scripts en la ruta
/ etc/ init.d que los controlan. La may oría de estos scripts están prog ramados de
tal forma que el usuario puede interactuar con ellos mediante las órdenes:

s tart ? Inicia el serv icio.

s top ? Detiene el serv icio.
res tart ? R einicia el serv icio.
s tatus ?Muestra si el serv icio está corriendo o no.

Así pues, podríamos comprobar el estado del serv icio sshd mediante:

/ etc/ init.d/ s s hd s tatus

Además, en ciertas distribuciones como C entos existe el comando s erv ice para
poder administrar los serv icios sin tener que escribir la ruta completa a la carpeta
/etc/init.d. Por ejemplo:

s erv ice s s hd s tatus

Los serv icios pueden config urarse para que arranquen junto con el sistema
operativ o y , al ig ual que este, se pueden iniciar en diferentes niv eles de ejecución o
runlev els.

E n linux existen ( normalmente) 7 niv eles de ejecución distintos, los cuales serían:

0 ? Apag ado del sistema.

1 ? Modo monousuario o "sing le user". S e suele emplear para tareas de
mantenimiento del sistema.
2 ? Modo multiusuario sin red.

Administración de sistemas de software libre 62

 3 ? Modo multiusuario con funciones de red.
4 ? No es utilizado. S e puede emplear para ser personalizado.
5 ? Modo multiusuario con entorno g ráfico.
6 ? R einicio del sistema.

Cuando arranca el sistema, comprueba el contenido del fichero / etc/ inittab e

inicia el sistema en el niv el de ejecución que esté definido por defecto ahí.

E n la captura de pantalla se aprecia que el niv el de ejecución por defecto es el 5

( initdefault) pero este podría ser cambiado seg ún nuestras necesidades.

Además, en este fichero se define también el runlev el que se le v a a pasar al

arrancar al script / etc/ rc.d/ rc tal y como se aprecia en la captura de pantalla.
Una v ez que recibe este arg umento, se v a al directorio / etc/ rcX .d/ donde X es el
niv el de ejecución que se le ha pasado anteriormente.

E n ese directorio hay unos enlaces simbólicos a los scripts de / etc/ init.d/ que
debe ejecutar. Por ejemplo si listamos el contenido de /etc/rc5.d/, para el niv el de
ejecución 5 tendríamos lo sig uiente:

E n ese directorio aparece el enlace a los scripts de /etc/init.d y unos llev an una S
delante y otros una K indicando si se debe iniciar ( S tart) ese serv icio o detener
( K ill) E l número que llev a asociado cada enlace es sólo el orden en el que se
ejecutarán. Así pues, podemos config urar los serv icios que arrancan en cada niv el
de ejecución cambiando la K de delante por la S o v icev ersa.

Podemos comprobar el niv el de ejecución en el que estamos trabajando mediante el

comando runlev el:

Administración de sistemas de software libre 63

Actualmente estamos en el niv el de ejecución 5 con entorno g ráfico pero podríamos
cambiar de niv el de ejecución en cualquier momento mediante el comando init
seg uido del niv el de ejecución. Por ejemplo para iniciar el niv el de ejecución 3:

init 3

V eremos cómo desaparece el entorno g ráfico y ahora si comprobamos el niv el de

ejecución en el que estamos:

runlev el

Nos indica que hemos pasado del 5 al 3. S i v olv emos al niv el de ejecución 5:

init 5

Puede resultar bastante tedioso el config urar qué serv icios se ejecutan en cada
niv el de ejecución de la forma que acabamos de v er. Para facilitar la tarea, existen
herramientas tanto g ráficas como de línea de comandos para tal efecto.

C on chkconfig podemos config urar qué serv icios se inician al arrancar el sistema y
cuáles no. Lo único que hace esta herramienta es modificar los scripts que
acabamos de v er pero de una forma que resulta mucho más amig able de cara al
usuario.

C on el comando chkconfig - - lis t listamos los serv icios que están actualmente
config urados en el sistema:

Como se aprecia en la imag en, los serv icios pueden ser config urados en cada niv el
de ejecución. Por ejemplo, el serv icio "anacronr" se iniciará en los niv eles de
ejecución 2, 3, 4 y 5 y permanecerá deshabilitado en el resto de niv eles.

Podemos config urar esto mediante chkconfig , por ejemplo, podemos decirle que
inicie anacron también en el niv el de ejecución 1:

chkconfig - - lev el 1 anacron on

Ahora si miramos la config uración:

chkconfig - - lis t | g rep anacron

Administración de sistemas de software libre 64

Por defecto, si utilizamos chkconfig para poner a on u off un determinado serv icio
sin especificar el niv el de ejecución que utilizará, toma por defecto los niv eles de
ejecución 2, 3, 4 y 5:

chkconfig anacron off

chkconfig anacron on

C omo siempre, para más opciones consultar m an chkconfig

Además de por línea de comandos, casi todas las distribuciones incluy en

herramientas g ráficas para poder g estionar los serv icios. E n C entos por ejemplo, si
escribimos s y s tem - config - s erv ices sacaremos la sig uiente interfaz g ráfica:

E n la parte de la izquierda tenemos los botones para iniciar, detener u reiniciar

serv icios.

Arriba si seleccionamos E ditar Niv el y eleg imos "Niv el de ejecución todos":

Administración de sistemas de software libre 65

V eremos los niv eles de ejecución 3, 4 y 5 y podremos config urar qué queremos que
se inicie en cada uno de ellos.

Administración de sistemas de software libre 66

 Ca p ítulo 5

Ges tores de arra nque

Conocer el proceso de arranque del sistema es una tarea importante debido a que
si sabemos cada paso del proceso, podremos determinar dónde se ha producido el
problema su lo hubiera. Además, si en el sistema v amos a tener v arios sistemas
operativ os necesitaremos de un g estor de arranque para poder determinar qué
sistema queremos arrancar en cada momento. E n este capítulo v amos a conocer el
funcionamiento de dos g estores de arranque y v amos a instalarlos en el sistema
para poder controlar un poco más el proceso de arranque del sistema.

Al finalizar el estudio de estas lecciones serás capaz de:

C onocer y entender el proceso de arranque del sistema Linux.

Iniciar el sistema en modo monousuario en caso de problemas.

Instalar un g estor de arranque para poder eleg ir el sistema operativ o que

deseemos iniciar.

Proteg er las opciones del g estor de arranque con el fin de ev itar que otro
usuario pueda modificarlas.

Administración de sistemas de software libre 67

 L e c ció n 1
I ntroducción

Lo primero que hay que conocer es qué pasos realiza el sistema Linux a la hora de
arrancar, lo que se conoce como secuencia de arranque:

1. Al pulsar el botón de encendido lo primero que ocurre es que se inicia la

BIOS . La BIOS hace un test al equipo y comprueba que todos los
componentes funcionen correctamente. Después, la BIOS accede a una
memoria no v olátil ( nv ram) que g uarda la información de qué dispositiv o se
v a a utilizar para el arranque del sistema ( normalmente suele ser un disco
duro) . Una v ez localizado el dispositiv o de arranque se acceder a el y se
lanza el carg ador de arranque o bootloader.
2. E l bootloader se encuentra en el primer sector del dispositiv o utilizado para
el arranque al cual se le conoce como MBR ( Master Boot R ecord) . E l MBR
tiene un espacio muy reducido ( 512 by tes) el cual contiene una peque a
parte del bootloader y la tabla de particiones. Al tener esta limitación de
espacio, se hace que el bootloader carg ue el resto de la información desde
otra partición más g rande. La función principal del bootloader es carg ar el
kernel y ejecutarlo.
3. C uando el k ernel se inicializa, inicia los dispositiv os con sus respectiv os
driv ers, monta el sistema de archiv os de root / en modo sólo lectura y ,
finalmente, inicia el proceso padre /sbin/init ( PID 1) al cual le pasa los
mismos parámetros que ha recibido el.
4. Una v ez iniciado el init, este lee la config uración del fichero /etc/inittab e
inicia los scripts contenidos en /etc/rc.d/ en el niv el de ejecución definido en
el /etc/inittab. Después inicia las consolas v irtuales y finalmente, inicia la
v entana X ( entorno g ráfico) si el sistema se ha iniciado en el niv el de
ejecución 5.

C onocer el funcionamiento del arranque del sistema es básico a la hora de resolv er

ciertos problemas. S i comprobamos que nuestro sistema no arranca deberemos
acceder en modo monousuario para comprobar que el bootloader esté funcionando
correctamente y que tanto el /etc/inittab como los scripts que este ejecuta estén
correctos.

E n el caso de que no podamos acceder al sistema en modo monousuario podemos

probar con lo que se llama un "Liv e C D" . Un Liv e C D, también conocido como Liv e
Distro es un sistema operativ o contenido en un medio extraíble que puede
ejecutarse sin necesidad de instalarlo en el disco duro y que utiliza la memoria R AM
el equipo como disco duro v irtual y el medio extraíble como sistema de archiv os.
Por lo tanto podremos utilizarlo para poder comprobar los problemas que hay an
surg ido durante el arranque del sistema en caso de que no podamos acceder en
modo monousuario.

Así pues, un g es tor de arranque o bootloader es un prog rama que administra el

proceso de arranque del sistema y le a ade funciones al mismo.

Administración de sistemas de software libre 68

E s posible que teng amos config urados en nuestro equipo dos sistemas operativ os
diferentes como son Linux y W indows, en tal caso, el g estor de arranque nos
permitiría eleg ir qué sistema operativ o deseamos iniciar.

E n los sistemas operativ os Linux, normalmente el g estor de arranque es o GR U B o

L I L O siendo el primero el más utilizado por la may oría de las distribuciones Linux
desde hace y a unos a os.

Una de las diferencias entre los dos sistemas es que Grub lee su archiv o de
config uración desde el disco duro cada v ez que arranca el sistema para ev itar que
el usuario escriba en el MBR . E n cambio en Lilo, cada v ez que se hace un cambio en
el archiv o de config uración, este escribe los cambios en el MBR y si esta operación
no se realiza correctamente, es posible que el sistema no pueda iniciarse.

Lilo tampoco tiene una interfaz de comando interactiv a a diferencia de Grub y no

puede leer las particiones ext2. A todo esto le a adimos que Grub es actualizado
con mucha frecuencia y que ha sido adoptado como el carg ador de arranque por
defecto de la may oría de las distribuciones Linux lo cual está haciendo que Lilo cada
v ez sea menos usado.

Administración de sistemas de software libre 69

 L e c ció n 2

Ges tor de arranque L I L O

LILO ( Linux Loader) fue desarrollado en un primer momento por W erner

Almesberg er y ahora se encuentra a carg o de J ohn C offman. Lilo permite arrancar
hasta 16 sistemas operativ os desde un equipo.

E l fichero de config uración de Lilo es / etc/ lilo.conf el cual, si no existe deberá ser
creado. C ada v ez que hag amos cambios en este fichero deberemos ejecutar el
comando lilo, de lo contrario el g estor no se enterará de los cambios introducidos y
por lo tanto será incapaz de realizarlos.

Alg unas de las opciones que se le pueden pasar son las sig uientes:

boot= ? Aquí es donde se define la partición en la que se v a a instalar Lilo.

Puede ser el sector de arranque de un disquete ( /dev /fd0) , el sector de
arranque de una partición raíz de linux ( /dev /hda1 con discos IDE o
/dev /sda1 con discos S C S I) o se puede instalar en el MBR ( /dev /hda para
discos IDE o /dev /sda para discos S CS I)
m es s ag e= ? Imprime el archiv o seleccionado al carg ar lilo.
m ap= ? Fichero en el cual estará el mapa de Lilo. E l mapa es un fichero
g enerado por Lilo que contiene punteros a cada uno de los sectores de
arranque del sistema operativ o. S i se omite, se tomará /boot/map por
defecto.
tim eout= ? Tiempo en décimas de seg undo que esperará Lilo a que el
usuario pulse una tecla antes de arrancar el sistema operativ o por defecto.
prom pt ? Muestra boot: en el arranque del sistema permitiendo que se le
puedan pasar comandos. S i se omite habrá que pulsar C trl, shift o alt para
poder sacar esta función.
default= ? Arrancará el sistema seleccionado por defecto.
im ag e= ? Donde se encuentra la imag en del kernel que queremos
arrancar.
label= ? E tiqueta que le queremos asig nar al sistema operativ o en
cuestión.
pas s w ord= ? Aquí asig naremos la clav e de acceso.
initrd= ? Aquí se define el fichero que se usará como el disco R AM inicial
para carg ar los módulos del kernel.
other= ? Aquí especificaremos las imág enes de otros sistemas operativ os
distintos de Linux.

S i simplemente v amos a tener un S .O en el equipo, lo habitual es instalar Lilo en la

partición raíz, en cambio si v amos a tener más de un S .O y deseamos que Lilo
g estione el arranque deberemos optar por instalarlo en el MBR .

Administración de sistemas de software libre 70

 ¡ P onte a prueba!
V amos a instalar LILO en nuestra máquina v irtual Ubuntu.

Una v ez instalado le pasaremos los parámetros de config uración sig uientes en

el fichero de config uración /etc/lilo. conf:

? Lilo se instalará en /boot/sda, es decir, en el MBR aunque no teng amos

más sistemas operativ os en el equipo.
? E l sistema de ficheros estará en /boot/sda2
? Deberá aparecer la línea boot: durante el arranque.
? La imag en del kernel a usar es /boot/v mlinuz- 2.6.35- 22- g eneric
? C omo etiqueta le asig naremos "Ubuntu Curso"
? C omo initrd le asig naremos /boot/initrd.img - 2.6.35- 22- g eneric
? Lo config uraremos en modo sólo lectura.

Podemos instalar lilo en la máquina v irtual ubuntu con el comando aptitude

ins tall lilo.

Una v ez instalado creamos el fichero / etc/ lilo.conf y a adimos el sig uiente

contenido:

Podemos conocer cómo están config uradas las particiones en nuestro equipo
mediante el comando fdis k - l:

Una v ez modificado el fichero de config uración, debemos ejecutar

el comando lilo como root.

Administración de sistemas de software libre 71

 E l comando lilo comprobará el contenido del fichero /etc/lilo.conf y creará el
mapa personalizado con los punteros a los sectores de arranque. S i hay alg ún
problema a la hora de ejecutar lilo nos av isará para que lo corrijamos.

E s importante solucionar los problemas que surjan debido a que si no los

dejamos resueltos es posible que el sistema no arranque.

E n nuestro caso símplemente arroja dos warning s que no tienen importancia y

por lo tanto no requieren de nuestra interv ención.

Ahora si reiniciamos el sistema mediante reboot nos aparecerá la sig uiente

pantalla:

Podremos eleg ir el sistema a arrancar mediante las flechas de dirección,

escribiendo su nombre y pulsando "enter" o escribiendo su letra asig nada, en
este caso la "U".

E n nuestro caso sólo tenemos un sistema a arrancar, escribimos el nombre del

sistema y le damos a enter con lo que arrancará:

Administración de sistemas de software libre 72

E s importante además, aplicar medidas de seg uridad a la hora de trabajar con los
g estores de arranque. S i no proteg emos el acceso a las particiones del sistema,
cualquiera que reinicie el equipo y teng a acceso a la línea de comandos podría
entrar en modo monousuario escribiendo "linux s ing le":

Una v ez en modo monousuario, tendría acceso a ficheros confidenciales e incluso

podría modificar la contrase a de root. Por ello debemos proteg er el acceso
mediante una contrase a que especificaremos también en el fichero de
config uración de Lilo /etc/lilo.conf

Además de proteg er el g estor mediante una contrase a deberemos cambiarle los

permisos también al fichero de config uración /etc/lilo.conf con el fin de que sólo
pueda leerlo root.

¡ P onte a prueba!

V amos a establecer una contrase a para restring ir el acceso a la línea de

comandos de Lilo. T ambién v amos a cambiarle los permisos al fichero
/etc/lilo.conf para que no todo el mundo pueda leerlo.

C omprobamos que el fichero /etc/lilo.conf puede leerlo cualquiera:

ls - l / etc/ lilo.conf

Modificamos los permisos de dicho fichero para que sólo root pueda leer y
escribir:

chm od 6 0 0 / etc/ lilo.conf

ls - l / etc/ lilo.conf

Ahora v amos a establecer una contrase a para lilo, accedemos al

fichero de config uración y le asig namos el parámetro password:

joe / etc/ lilo.conf

Administración de sistemas de software libre 73

 Dejamos el fichero así:

Ahora ejecutamos el comando lilo como root para hacer los cambios efectiv os:

lilo

Ahora v amos a reiniciar la máquina para comprobar los cambios que hemos
realizado:

reboot

Ahora cuando escribamos cualquier cosa en la línea de comandos nos pedirá la

contrase a que acabamos de establecer:

Administración de sistemas de software libre 74

 L e c ció n 3
Ges tor de arranque GR UB

GR UB ( Grand Unified Bootloader) fue desarrollado en un primer momento por el

prog ramador E rich S tefan Boley n como parte del trabajo en el arranque del
sistema operativ o GNU/Hurd, realizado por la Free S oftware Foundation. A partir de
1999, Yoshinori Okuji y Gordon Matzig keit hicieron de Grub un paquete oficial del
proy ecto GNU e hicieron que el desarrollo del g estor estuv iera abierto al público.

S e puede utilizar en una g ran cantidad de sistemas operativ os y es el g estor de

arranque por defecto de la may oría de las distribuciones linux.

Grub soporta los sig uientes tipos de sistemas de ficheros:

ext2/ext3/ext4
X FS
R eiserFS
UFS
FAT 16/FAT 32
NT FS
J FS
HFS

E ntre las principales características de Grub se encuentran las sig uientes:

Buena g estión de la memoria.

Multiplataforma.
Muy portable.
Interfaz g ráfica muy potente.

E l fichero de config uración de Grub es / boot/ g rub/ m enu.ls t en Centos, en el y ,

al ig ual que pasaba con Lilo, se le pueden especificar div ersos parámetros, entre los
que nombramos alg unos:

title ? A continuación de esta sentencia especificaremos el nombre que le

v amos a poner al S .O. C uando el sistema arranque y aparezca g rub, este
será el nombre que v eamos. Normalmente debajo de cada sentencia title,
aparecen los parámetros root, kernel, initrd…
root ? Indica el disco duro y la partición en la que se encuentra el S .O. Por
ejemplo, root ( hd0, 0) indica que el S .O se encuentra en el disco 0, en la
partición 0.
root ( hd2, 1) indica que el S .O se encuentra en el seg undo disco en la
partición 1.

Administración de sistemas de software libre 75

 kernel ? Indica dónde se encuentra la imag en del sistema operativ o.
initrd ? Aquí se define el fichero que se usará como el disco R AM inicial
para carg ar los módulos del kernel.
default ? S istema operativ o que se iniciará por defecto cuando se acabe el
tiempo definido en la v ariable timeout. S i le especificamos un 0, iniciará el
sistema operativ o que esté más arriba en el fichero de config uración, con un
1 el seg undo y así sucesiv amente…
tim eout ? Tiempo que esperará el g estor de arranque a que hag amos una
selección antes de iniciar el S .O por defecto.
s plas him ag e ? Aquí es donde definiremos la imag en que se utilizará como
fondo en Grub. T iene que tener unas medidas específicas y estar en un
formato dado o sino no funcionará. C oncretamente, la imag en no puede
tener más de 14 colores, debe ser tener una resolución de 640x480 y debe
estar en formato .xpm.
pas s w ord ? Podremos definir la contrase a para restring ir el acceso al
g estor de arranque y por lo tanto hacer que no puedan acceder en modo
monousuario.

Para poder introducir contrase as encriptadas en el fichero de config uración, g rub

incorpora una herramienta llamada g rub- md5- cry pt que conv ierte la contrase a
que se le pase por línea de comandos en una contrase a codificada en md5
haciendo que sea más seg ura.

S i v amos a utilizar esta contrase a deberemos poner - - md5 después del parámetro
password para que g rub lo entienda.

S i comprobamos el fichero /boot/g rub/menu.lst de nuestra máquina v irtual C entos

v eremos que el fichero de config uración está así:

E l S .O por defecto para arrancar es C entOS aunque ahora mismo no hay ning uno
más config urado. E sperará 5 seg undos antes de arrancar el sistema por defecto.

Administración de sistemas de software libre 76

La opción hiddenm enu esconde las particiones cuando iniciamos el sistema de
manera que para poder v erlas y cambiarlas deberemos presionar una tecla para
que aparezca.

E l S .O se encuentra en ( hd0, 0) . E s importante entender que Grub trata los

nombres de las particiones de manera diferente a como lo hace el sistema
operativ o, si hacemos un fdisk - l v eremos:

E n el sistema, la letra "a" de sda representa el primer disco y el número indica el

número de la partición, por lo tanto sda1 es la primera partición del primer disco, si
tuv iéramos sdc2, se referiría a la seg unda partición del tercer disco y así
sucesiv amente… Para Grub, sda1 sería ( hd0, 0) , sda2 sería ( hd0, 1) y así
sucesiv amente. S i tuv iéramos las particiones sdc1 y sdc2 por ejemplo, g rub las
interpretaría como ( hd2, 0) y ( hd2, 1) respectiv amente.

Así pues, debemos hacer un trabajo de adaptar los nombres de las particiones al
formato de Grub.

La opción rhg b es un modo g ráfico especial de los sistemas R ed Hat y la opción

quiet hace que no se muestren los errores que aparezcan durante el arranque por
pantalla.

Además de lo nombrado anteriormente, es importante al igual que pasaba con Lilo,

proteger la edición de las particiones en el gestor al arrancar el sistema mediante una
contrase a para evitar que estas sean manipuladas por cualquier usuario y por lo tanto
puedan acceder al sistema en modo monousuario con el riesgo que ello conlleva.

Para acceder en modo monousuario, durante los 5 seg undos que da g rub para
arrancar el sistema por defecto pulsaremos cualquier tecla y estaremos en la
sig uiente pantalla:

Administración de sistemas de software libre 77

Ahora si pulsamos la tecla "e" entraremos en la edición de la config uración de g rub
para la partición sobre la que estemos:

S i nos v amos a la línea del k ernel que usa ese sistema operativ o y la editamos
a adiendo un "1" al final, iniciaremos en ese niv el de ejecución, es decir, en modo
monousuario. Presionamos la "e" sobre la línea de kernel y lo a adimos:

Una v ez hecho el cambio, pulsaremos "enter" para g uardar el cambio y después la

tecla "b" para que arranque con esa config uración.

Una v ez hecho esto el sistema arrancará en modo monousuario y tendremos acceso

a cualquier recurso del sistema:

E sta tarea es de extrema utilidad cuando no conseg uimos hacer que el sistema
arranque. E ntraremos en este modo e intentaremos reparar los archiv os para que
v uelv a a iniciarse en modo normal. S i el sistema se encuentra inaccesible incluso en
modo monousuario deberemos pensar en intentarlo con un Liv e C d.

¡ P onte a prueba!

Debido al g ran riesg o que implica que otro usuario acceda al sistema en modo
monousuario, v amos a proteg er la edición de las particiones en g rub mediante
una contrase a. Para ello utilizaremos una contrase a encriptada mediante la
herramienta g rub- md5- cry pt y la a adiremos al fichero principal de
config uración de Grub.

Así pues, utilizamos la herramienta que incorpora Grub ( g rub- md5- cry pt) para
encriptar una contrase a que nosotros le v amos a pasar por la línea de
comandos:

g rub- m d5 - cry pt

Nos pedirá la contrase a a encriptar:

Administración de sistemas de software libre 78

 E scribimos "12345" por ejemplo y nos dev olv erá la contrase a encriptada:

Ahora debemos copiar la contrase a que nos ha dev uelto g rub e irnos al fichero
de config uración de este:

joe / boot/ g rub/ m enu.ls t

A adimos la línea con la contrase a encriptada con lo que el fichero de

config uración quedará así:

T ambién podríamos poner la contrase a en claro pero es más seg uro así y no
hace falta que modifiquemos los permisos del fichero.

E s importante decir que en el lug ar donde hemos puesto la contrase a,

afectaría a todos los S .O que estuv ieran config urados en el fichero. S i sólo
quisiéramos asig narle esa contrase a a un S .O en concreto colocaríamos la
orden justo debajo del title que le hubiéramos asig nado al S .O

Una v ez hechos los cambios y g uardados, reiniciamos la máquina v irtual

mediante reboot.

Ahora cuando aparezca esta pantalla:

Administración de sistemas de software libre 79

 V eremos que en la parte de abajo y a no nombra las opciones de editar entre
otras y únicamente nos deja iniciar el S .O tal y como está y presionar la tecla
"p" para introducir la contrase a que nos permita editar las opciones.

S i presionamos p:

Introducimos la contrase a y una v ez comprobado que es la correcta, nos

aparecerá la misma v entana pero ahora y a nos dejará editar:

Administración de sistemas de software libre 80

 Ca p ítulo 6

S erv icios d e com p a rtición d e a rc hiv os

Desde siempre, los usuarios de una red han necesitado tener acceso a los recursos
manejados por otros usuarios. Para satisfacer esa necesidad se crearon div ersos
protocolos que aportaban dicha funcionalidad a los usuarios de todo el mundo. E n
este capítulo v amos a aprender a config urar alg uno de esos serv icios.

Al finalizar el estudio de estas lecciones serás capaz de:

E ntender el protocolo ftp y config urar un ftp sencillo.

Conocer el protocolo NFS y config urarlo.

C onocer el serv icio S amba y config urarlo.

Administración de sistemas de software libre 81

 L e c ció n 1

E l s erv icio F T P

E l protocolo FTP ( File Transfer Protocol) es un protocolo de red que permite la

transferencia de archiv os entre sistemas conectados a la red y que se basa en un
modelo cliente- serv idor. Así pues, desde un equipo cliente podremos conectarnos a
un serv idor para descarg arnos la información que deseemos a trav és de la red.

E l serv icio ftp normalmente utiliza los puertos 20 y 21. E xisten dos modalidades de
uso del serv icio ftp: activ o y pas iv o.

E n cualquiera de los dos modos, el serv idor debe permitir conexiones entrantes al
puerto 21/tcp.

E n el modo activ o, el serv idor abrirá una seg unda conexión desde su puerto 20/tcp
a un puerto especificado por el cliente cada v ez que transfiera datos.

E n el modo pasiv o será el cliente el que abra una seg unda conexión a un puerto tcp
elev ado especificado por el serv idor cada v ez que se transfieran datos. E l modo
activ o no se utiliza mucho debido a que los serv idores suelen estar proteg idos por
un firewall que les impide conectarse a direcciones remotas si bien no impide que
los clientes se conecten a el.

E l modo pasiv o es más sencillo de usar sin embarg o conllev a un riesg o de

seg uridad al permitir que cualquier cliente se conecte al serv idor a trav és de
múltiples puertos, de ahí que para este tipo de transferencias se utilicen siempre
puertos elev ados.

E l protocolo ftp está pensado para ofrecer la máxima v elocidad pero se trata de un
protocolo muy inseg uro. T oda la información que se intercambia entre cliente y
serv idor se hace en texto plano, desde el usuario y la contrase a e incluy endo
cualquier fichero transferido haciendo que sea muy fácil que un atacante pueda
capturar ese tráfico y por lo tanto conseg uir acceso al serv idor y a los ficheros
transferidos.

Para solucionar este problema existen otros protocolos como scp o sftp que
permiten cifrar todo el tráfico que se g enera entre el equipo cliente y el serv idor
proporcionando esa protección de la que carece el protocolo ftp.

E xisten v arias formas de hacer ftp:

ftp anónim o: Cualquier persona puede acceder a un serv idor y descarg ar

contenido sin necesidad de proporcionar un usuario y una contrase a.
Normalmente, cuando solicite un usuario deberemos introducir "anony mous"
y lo mismo se aplica a la contrase a. No es recomendable config urarlo de
esta manera por el g ran problema de seg uridad que supone.
ftp autenticado: Para conectarse al serv idor es necesario proporcionar un
nombre de usuario y una contrase a v álida que permitirán subir y descarg ar
contenido.

Administración de sistemas de software libre 82

 ftp em bebido o bas ado en w eb: E s el que se realiza desde pág inas web a
trav és de un nav eg ador. E s un tipo de ftp anónimo.

T ambién hay que tener claros los conceptos de:

Cliente ftp: E s un prog rama o utilidad que se utiliza en el equipo del cliente
y emplea el protocolo ftp para conectarse con un serv idor y transferir
información bidireccionalmente. Normalmente todos los sistemas llev an un
cliente ftp integ rado, sin embarg o existen clientes como FileZ illa por ejemplo
que aportan una serie de funcionalidades extra http: //filezilla- project.org /.
E n W indows podemos utilizar el explorador de archiv os para esta tarea por
ejemplo.
S erv idor ftp: Un serv idor ftp es prog rama que se instala en una máquina
para permitir la transferencia de información entre ella y los clientes que se
conecten. E n el serv idor ftp podremos config urar una serie de opciones para
hacer más seg ura la transferencia, permitir el acceso sólo a los usuarios que
nosotros deseemos, etc.

E n linux existen una g ran cantidad de serv idores ftp, como por ejemplo v s ftpd.

¡ P onte a prueba!

V amos a instalar el paquete v sftpd en nuestra máquina v irtual Centos, con el

fin de prov eer este serv icio a los usuarios que accedan a nuestro equipo.

Buscamos el paquete v sftpd:

y um s earch v s ftpd

Lo instalamos en nuestra máquina:

y um ins tall v s ftpd

Una v ez instalado lo habilitamos de manera predeterminada:

chkconfig v s ftpd on

C omprobamos que está habilitado:

chkconfig - - lis t | g rep v s ftpd

Administración de sistemas de software libre 83

E l fichero de config uración principal de v sftpd es / etc/ v s ftpd/ v s ftpd.conf en el
cual se pueden cambiar muchos parámetros seg ún nuestras necesidades, como por
ejemplo:

anony m ous _ enable ? Permite hacer ftp a los usuarios anónimos si está
habilitado. Por defecto está a YE S .
E n un entorno de producción es importante no dejar acceder a los usuarios
anónimos debido al pelig ro que esto representa para la integ ridad de la
propia máquina.
local_ enable ? Permite a los usuarios creados en el sistema acceder al ftp.
chroot_ local_ us er ? Hace que los usuarios locales no puedan salir de su
directorio personal.
ftpd_ banner ? E stablece el mensaje que recibirán los usuarios que se
conecten al serv idor.
x ferlog _ file ? Fichero de log del serv icio ftp. Por defecto se utiliza
/v ar/log /xferlog .
w rite_ enable ? Habilita el modo escritura.

E l serv icio admite muchos más parámetros, lo mejor es acceder al fichero de

config uración y leer los comentarios que aparecen sobre cada uno de ellos o
consultar m a n v s ftpd.conf.

Además del fichero de config uración g eneral / etc/ v s ftpd/ v s ftpd.conf podemos
permitir o deneg ar el acceso a ciertos usuarios seg ún nuestras necesidades. S i la
opción us erlis t_ enable está puesta a YE S en el fichero de config uración g eneral
( por defecto debería estarlo) y la opción us erlis t_ deny está puesta a YE S ( por
defecto lo está) , los usuarios que aparezcan en el fichero / etc/ v s ftpd/ us er_ lis t
no podrán hacer ftp al serv idor.

Por el contrario, si la opción userlist_ deny está puesta a NO, sólo los usuarios del
fichero / etc/ v s ftpd/ us er_ lis t podrán acceder al serv idor.

A continuación se listan los usuarios que aparecen en / etc/ v s ftpd/ us er_ lis t y
que por lo tanto no tienen acceso al ftp por defecto:

cat / etc/ v s ftpd/ us er_ lis t

Administración de sistemas de software libre 84

A la hora de crear usuarios para que accedan v ía ftp a nuestra máquina lo haremos
creando cuentas normales pero haremos que no puedan log uearse en el sistema, es
decir, que su terminal sea / s bin/ nolog in

Para conectarnos a un serv idor ftp podemos utilizar el cliente lftp.

E l cliente es muy sencillo de utilizar, sólo hará falta especificarle la ip del serv idor al
que nos queremos conectar y una v ez hecho esto, nos pedirá el usuario y la
contrase a con los que acceder.

Una v ez estemos dentro del serv idor, nos aparecerá una línea de comandos como
la sig uiente:

E n dicha línea de comandos podremos especificar una serie de órdenes que nos
permitirán interactuar con el serv idor.

Además de las órdenes habituales como ls, cd, cat… se podrán ejecutar otras como:

put ? S ubirá el archiv o local al serv idor remoto

g et ? Descarg a el archiv o remoto al equipo local.
quit ? Nos desconecta el serv idor ftp.

Para más ordenes como siempre, consultar su pág ina m an lftp

T ambién podemos conectarnos mediante el comando ftp ip del s erv idor si no

queremos usar el cliente lftp.

Administración de sistemas de software libre 85

 L e c ció n 2

E l s erv icio NF S

NFS es un protocolo que permite a distintos sistemas conectados a una misma red,
acceder a los recursos remotos como si se trataran de recursos locales. Fue creado
en 1984 por S un Microsy stems y se caracteriza por ser independiente del sistema
operativ o en el que se ejecuta haciendo que una máquina con S .O W indows
comparta información con una máquina Linux.

Así pues, no es necesario que los equipos de una red local utilicen espacio en disco
para almacenar sus datos, estos datos se almacenan en el serv idor y el cliente
accede a ellos como si se tratara de su propia máquina.

E l serv icio nfs no es nada seg uro, en lug ar de utilizar un sistema basado en
usuarios y contrase as como S amba por ejemplo, utiliza una lista de acceso en la
que aparecen direcciones IP y nombres. C on el fin de tapar este ag ujero de
seg uridad, únicamente deberíamos habilitar nfs dentro de una red local y nunca
para que los usuarios accedan a los recursos del serv idor a trav és de la red.

¡ P onte a prueba!

V amos a instalar el serv icio NFS en nuestra máquina v irtual C entos y habilitarlo
por defecto.

Nos conectamos a nuestra máquina v irtual Centos mediante putty o utilizando

la propia terminal de la máquina.

Buscamos un paquete llamado nfs:

y um s earch nfs

De todos los paquetes que aparecen, el que nos interesa seg ún la descripción
es nfs - utils

Lo instalamos en nuestra máquina:

y um ins tall nfs - utils

Administración de sistemas de software libre 86

 Ya teníamos instalado el paquete en nuestra máquina y lo que hemos hecho ha
sido actualizarlo.

V amos a habilitar el serv icio por defecto cada v ez que arranque la máquina:

chkconfig nfs on

chkconfig - - lis t | g rep nfs

NFS depende de otro serv icio llamado portm ap. Portmap es un serv icio que se
encarg a de la tarea de mapear los puertos utilizados por alg unos serv icios en la
máquina donde se está ejecutando.

E l serv icio nfs incorpora dos scripts, / etc/ init.d/ nfs y / etc/ init./ nfs lock cada
uno de los cuales inicia una serie de serv icios.

E l script nfs se encarg a de iniciar los serv icios rpc.nfs d, rpc.m ountd y
rpc.rquotad.

rpc.nfs d se encarg a de iniciar los procesos nfs asociados con el k ernel.

rpc.m ountd g estiona las peticiones de montaje de los directorios.
rpc.rquotad g estiona la información del estado de las cuotas entre el
serv idor y los clientes.

E l script nfslock inicia los serv icios rpc.lockd y rpc.s tatd.

rpc.lockd prov ee la función de bloqueo de ficheros y reg istros.

rpc.s tatd se encarg a de recuperar el serv icio NFS después de un reinicio o
de un fallo en el serv icio nfs.

Mountd, statd, lockd y rquotad pueden ser config urados para que utilicen siempre
un puerto asig nado por nosotros en / etc/ s y s config / nfs de tal forma que no
dependan de portmap y por lo tanto sea más sencillo config urar el firewall.

E l fichero principal de config uración del serv icio nfs es / etc/ ex ports , ahí se
pueden definir qué directorios exportar por nfs.

E l formato de dicho fichero debe seg uir el sig uiente patrón:

directorio a ex portar a quien s e lo ex portam os ( opciones )

Administración de sistemas de software libre 87

Podemos exportar los directorios a un equipo o a todos los equipos que se
encuentran en un determinado dominio o red. Un ejemplo de cómo podría quedar el
fichero:

/v ar/ftp 10.0.0.10( ro, sy nc)

/v ar/documentos 10.0.0.0/255.255.255.0( ro)

/home/pepe *.info.com( rw, sy nc)

E n la primera línea estamos exportando el directorio /v ar/ftp a la máquina con ip

10.0.0.10 con las opciones ro y sy nc.

E n la seg unda línea exportamos /v ar/documentos a todos los equipos comprendidos

en las ips 10.0.0.0- 10.0.0.255

E n la tercera línea, exportamos /home/pepe a todos los equipos pertenecientes al

dominio info.com.

Nota

T ambién podemos poner un "? " para indicar un solo carácter en

lug ar del "*" que indica todo.

E ntre las opciones que se pueden especificar se encuentran las sig uientes:

rw ? Permite leer y escribir en la unidad exportada.

s y nc ? S ólo responde a las peticiones después de que los cambios se hay an
g uardado en la unidad.
ro ? S ólo permite leer la unidad exportada.
root_ s quas h ? E v ita que los usuarios que se conecten como root desde el
equipo cliente teng an priv ileg ios de root en el equipo serv idor.

Por defecto, si no se le asig na ning una opción a la ruta que estamos exportando, se
le asig nan las opciones ro, sy nc y root_ squash.

E xisten una serie de utilidades imprescindibles a la hora de trabajar con nfs.

C on el comando ex portfs podemos comprobar qué estamos exportando en todo

momento. Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- v ? Nos muestra qué estamos exportando y las opciones asig nadas a cada
exportación.

Administración de sistemas de software libre 88

 - u ? S irv e para dejar de exportar el directorio seleccionado.
- i ? Ig nora las opciones que aparecen en el fichero /etc/exports de forma
que sólo se hag a caso a las opciones por defecto y a las pasadas por línea
de comandos.
- r ? V uelv e a carg ar el fichero /etc/exports aplicando las opciones que se
hay an a adido. E sta opción nos ev ita tener que reiniciar el serv icio nfs
cuando hag amos cambios en fichero de config uración lo cual resulta muy útil
en entornos de producción.

Otro comando útil es s how m ount que permite v isualizar los directorios exportados
por una máquina remota. C on la opción - e muestra la lista de exportaciones del
serv idor seleccionado.

Podemos ag reg ar las unidades exportadas desde un serv idor nfs modificando el
fichero / etc/ fs tab, ahí a adiremos una línea para especificar el serv idor y la ruta a
montar. Por ejemplo:

10.0.0.20: /v ar/ftp /mnt/prueba nfs defaults 0 0

E n el ejemplo anterior estaríamos montando la unidad /v ar/ftp del serv idor

10.0.0.20 en la ruta local /mnt/prueba. Le tenemos que indicar que es de tipo nfs.

Alg unas de las opciones que se le pueden especificar en el fichero /etc/fstab para
montar unidades nfs son:

initr ? Permite interrumpir las peticiones nfs si el serv idor deja de ser
accesible.
nolock ? Desactiv a el bloqueo de archiv os.
s oft ? Cualquier prog rama que utilice un archiv o del serv idor nfs reportará
un error si el serv idor nfs deja de estar disponible pero seg uirá
ejecutándose.
hard ? Cualquier prog rama que utilice un archiv o del serv idor nfs se
detendrá inmediatamente si el serv idor nfs deja de estar disponible.

También podemos montarlas mediante el comando m ount si sólo queremos que

las unidades exportadas estén disponibles de manera temporal. Utilizando el
ejemplo del /etc/fstab, haríamos lo sig uiente:

mount 10.0.0.20: /v ar/ftp /mnt/pruebas

Una v ez hecho esto, cuando accedamos a /mnt/pruebas v eremos la ruta /v ar/ftp

del equipo remoto.

Administración de sistemas de software libre 89

 L e c ció n 3

E l s erv icio S a m b a

S amba es una implementación libre del protocolo de archiv os compartidos de

Microsoft W indows para sistemas tipo Unix que permite administrar y compartir
recursos en redes con W indows.

E l protocolo S MB fue creado en 1985 por IBM y actualmente se le conoce también

con el nombre C IFS .

Más tarde, en 1991, Andrew Tridg ell, utilizando un sniffer

( prog rama que captura el tráfico de red) , usó ing eniería
inv ersa para capturar el tráfico g enerado por el protocolo
S MB y así consig uió implementarlo en un sistema Unix. Así,
su serv idor Linux apareció como un serv idor de archiv os
dentro de su red W indows.

Andrew no pudo utilizar el nombre S MB debido a que este

y a estaba siendo usado por lo que tuv o que buscar otro.
Para eleg irlo, hizo una búsqueda en el diccionario de su
sistema unix de la sig uiente forma:

g rep - i 's.*m.*b' /usr/dict/words Andrew T ridg ell

Obteniendo los resultados: salmonberry samba sawtimer y scramble

Así fue como su implementación del protocolo S MB pasó a llamarse S am ba .

S amba permite, entre otras cosas:

C ompartir impresoras instaladas en el serv idor.

Autenticar a los clientes que se log ueen en un dominio W indows.
C ompartir los sistemas de archiv os de un S .O.

S amba es compatible con casi todas las v ersiones de W indows como 2000, X p,
S erv er 2003 además de ser compatible con los equipos que ejecutan Linux.

Para instalar S amba en nuestra máquina v amos a necesitar los paquetes:

s am ba : E s el propio serv idor S amba.

s am ba- client: S on un conjuntos de prog ramas clientes para operar con
S amba.
s am ba- com m on: Ficheros comunes a la parte cliente y a la parte serv idor
de samba.

Administración de sistemas de software libre 90

E l serv icio samba necesita tener abiertos cuatro puertos de NetB ios : 137/udp,
138/udp, 139/tcp y 445/tcp.

NetBios es un protocolo de red utilizado por S amba para prov eer ciertos serv icios
como son: el serv icio de nombres, el serv icio de paquetes y el serv icio de sesión.

E l s erv icio de nom bres permite asig narle un nombre a un determinado equipo de
una red de manera que se pueda asociar la ip de un equipo con su nombre.

E l s erv icio de paquetes permite env iar paquetes en una red.

E l s erv icio de s es ión permite establecer una conexión entre dos equipos de una
red dada.

C uando se inicia samba se inician dos serv icios: smbd y nmbd. S m bd es el serv icio
que proporciona las funcionalidades del cliente y serv idor samba. Nm bd es el
serv icio que se encarg a de todo lo relacionado con las funcionalidades de netbios.

¡ P onte a prueba!
V amos a instalar S amba en nuestra máquina v irtual, para ello instalaremos los
paquetes samba, samba- client y samba- common y comprobaremos que el
serv icio quede habilitado por defecto.

Nos conectamos a nuestra máquina v irtual Centos mediante putty o utilizando

la propia terminal de la máquina.

Buscamos el paquete samba mediante y um:

y um s earch s am ba

Instalamos los paquetes con la opción - y para que no nos pida confirmación:
y um - y ins ta ll s a m ba s a m ba - client s a m ba- com m on

Administración de sistemas de software libre 91

 Ahora que lo hemos instalado v amos a hacer que el serv icio quede habilitado
por defecto en los niv eles de ejecución 3, 4 y 5:

chkconfig s m b on

chkconfig - - lis t | g rep s m b

E l fichero de config uración principal de S amba es / etc/ s am ba/ s m b.conf, el cual

está div idido en tres secciones especiales:

[ g lobal] ? T odos los parámetros especificados en esta sección se aplican al

serv idor en g eneral.
[ hom es ] ? E sta sección se utiliza para otorg ar acceso a los usuarios a su
directorio personal. S i no se define la ruta de acceso al personal de un
usuario aquí, S amba buscará en el fichero que contiene las contrase as de
los usuarios y si se ha introducido correctamente montará automáticamente
su directorio personal.
[ printers ] ? Aquí se definen los parámetros que afectarán al acceso a los
recursos de impresión.

E xisten una g ran cantidad de parámetros para pasarle a S amba y todos ellos se
encuentran documentados en su pág ina man ? m an 5 s m b.conf

E n el fichero /etc/samba/smb.conf es donde se definen también los directorios que

queremos compartir a trav és de la red y las limitaciones de seg uridad que
ag reg amos para ev itar el mal uso de estos recursos.

E n el propio fichero /etc/samba/smb.conf aparecen v arios ejemplos sobre cómo

config urar estos directorios compartidos, como por ejemplo el sig uiente:

E n el ejemplo anterior se define un "share" o recurso compartido cuy a sección de

parámetros comienza inmediatamente debajo de [ public] .

Administración de sistemas de software libre 92

Alg unos de los parámetros que se pueden especificar a la hora de compartir
directorios en samba son:

com m ent ? S e define una frase que identifique al share en cuestión.

path ? R uta del directorio que queremos compartir a trav és de la red.

public ? S i está puesto a "y es" permitirá el acceso a este recursos a usuarios
anónimos y v icev ersa.

w ritable ? S i está puesto a "y es" permitirá modificar contenido del recurso
compartido y v icev ersa.

printa ble ? S i está puesto a y es, entonces el recurso se trata como una
impresora, si se pone a no, se trata de un recurso de lectura/escritura.

read only ? S i está puesto a y es sólo se podra leer el recurso y no podrá ser
modificado y v icev ersa.

w rite lis t ? S e define que usuarios pueden modificar contenido del recurso.

Nota

Aunque se especifique el parámetro "read only = y es", los usuarios

que aparezca dentro de write list tendrán permisos de lectura y
escritura.

g roup ? T odas las conexiones que se establezcan al recurso que está siendo
compartido utilizarán el g rupo definido en este parámetro como su g rupo primario.

brow s eable ? C ontrola si el share en cuestión es v isto o no cuando se solicita la

lista de shares disponibles en una máquina.

create m as k ? E stablece la máscara que se aplica a los archiv os que se creen

dentro del recurso compartido.

s ecurity ? E ste es uno de los parámetros más importantes que se pueden

config urar en el fichero principal de S amba. Mediante el parámetro security se
determina la forma de autenticar a los usuarios que intenten acceder al recurso
compartido en cuestión.

La opción por defecto es "secutiry = user" pero se puede modificar para que teng a
los v alores: share, domain o serv er en función de nuestras necesidades.

Administración de sistemas de software libre 93

E l modo de autenticación us er requiere proporcionar credenciales de un usuario
v álido existente en la máquina local o un usuario que pueda ser traducido a uno de
la máquina local en el fichero / etc/ s am ba/ s m bus ers . S i se da cualquiera de los
dos casos anteriores, hará falta ejecutar el comando s m bpas s w d con el fin de
g estionar los datos de acceso a los shares de cada usuario local.

S i especificamos s hare, el usuario que intente acceder al recurso compartido en

cuestión deberá proporcionar credenciales adecuados definidos en el propio recurso
que se está compartiendo.

C uando le asig namos el v alor dom a in a la v ariable security , la máquina que esté
ejecutando S amba deberá estar incluida dentro de un dominio W indows NT y por lo
tanto, para autenticar a los usuarios, comprobará el usuario y la contrase a que
tienen asig nadas en ese dominio.

C on el v alor s erv er activ ado, el serv idor S amba pasará los datos de acceso a otro
serv idor S MB para comprobar si el usuario y la contrase a son correctos.

Nosotros nos centraremos en la opción por defecto de security = user. C uando

queremos darle acceso a un recurso compartido a un usuario mediante este
sistema, una v ez comprobado que el usuario tiene una cuenta en el equipo local
( /etc/passwd) deberemos ejecutar el comando s m bpas s w d para config urar su
contrase a de smb.

Alg unos de los parámetros que se le pueden pasar a este comando son:

- a ? Mediante este parámetro se incluy e al usuario en el fichero de usuarios

de S amba y se cambia su contrase a de S amba. S i el usuario y a existe en
ese fichero, se le cambiará la contrase a.
- x ? E limina al usuario especificado del fichero de usuarios de S amba.
- d ? Deshabilita el usuario especificado del fichero de usuarios de S amba.
- e ? Habilita el usuario especificado del fichero de usuarios de S amba.

Una v ez modificado el fichero de config uración de S amba, podemos comprobar que

esté correcto mediante el comando tes tparm .

Podemos comprobar si cualquier equipo remoto puede acceder a los recursos

compartidos en el serv idor S amba utilizando la sig uiente sintaxis:

tes tparm fichero de config uración nom bre equipo rem oto ip equipo rem oto

Por ejemplo si quisiéramos comprobar si la máquina v irtual ubuntu puede acceder a

alg uno de los recursos compartidos del serv idor Centos, en mi caso sería así:

tes tparm / etc/ s am ba/ s m b.conf ubuntu 1 0 .0 .0 .7 2

Administración de sistemas de software libre 94

C omprobamos que al equipo ubuntu se le permitiría el acceso a los recursos homes
y printers del serv idor S amba en Centos.

Con la opción - v , testparm dev olv erá todos los parámetros incluy endo los
parámetros por defecto que no se han especificado en el fichero
/etc/samba/smb.conf

Desde un equipo cliente, podemos conectarnos a un serv idor S amba mediante el

comando s m bclient indicando el recurso de la sig uiente forma / / s erv idor/ ruta
al recurs o

Alg unos de los parámetros que se le pueden pasar a smbclient son los sig uientes:

- L ? Lista los recursos disponibles en un serv idor remoto.

- U ? Intenta la autenticación con un serv idor S amba remoto mediante el
usuario especificado.
- p ? E specifica el puerto del serv idor remoto al cual queremos conectarnos.
- A ? C on este parámetro se le puede especificar al serv idor remoto un
fichero de config uración del cual leerá el usuario y la contrase a con el que
conectarse.

Una v ez que el usuario consig ue acceder al serv idor, puede utilizar el cliente S amba
ig ual de manera similar al cliente ftp.

T ambién es posible a adir los recursos compartidos al fichero /etc/fstab con el

objetiv o de que se monten automáticamente cuando iniciemos sesión en el sistema.

Por ejemplo, si quisiéramos montar el recurso /v ar/prueba del serv idor S amba en
/mnt/prueba del equipo local autenticándonos con el usuario fernando, a adiríamos
la sig uiente línea:

/ / centos / v ar/ prueba / m nt/ prueba cifs us erna m e= ferna ndo,

uid= fernando, noauto 0 0

Debemos especificarle que es un recurso de tipo cifs para que entienda S amba. La
opción noauto se a ade con el propósito de que no monte el recurso nada más
arrancar el equipo y por lo tanto, que no hay a que introducir la contrase a del
usuario para que termine de arrancar.

Administración de sistemas de software libre 95

Otra forma de a adir el recurso en /etc/fstab es diciéndole que coja los datos para
autenticarse del fichero de texto que nosotros le indiquemos. Así pues,
suprimiríamos la parte "username= fernando, uid= fernando, noauto" y a adiríamos:

credentials = / etc/ s am ba/ acces o.tx t

E l fichero acceso.txt debería tener el sig uiente formato para que todo funcione
correctamente:

username=

password=

E s posible administrar S amba mediante un entorno g ráfico instalando el paquete

s y s tem - config - s am ba

Una v ez instalada, esta herramienta resulta extremádamente sencilla de utilizar si

bien, no es tan completa como la línea de comandos.

Podemos lanzarla ejecutando sy stem- config - samba:

Podemos a adir un nuev o recurso compartido pulsando el botón con el mismo

nombre tras lo cual aparecerán una serie de opciones:

Administración de sistemas de software libre 96

E n directorio especificaremos la ruta que queremos conv ertir en recurso
compartido. Debajo especificaremos el nombre que le queremos asig nar a este
recurso compartido y una descripción que se ajuste a lo que ofrece dicho recurso.

Más abajo aparece dos checks para permitir escribir a los usuarios y hacer que el
recurso compartido pueda ser v isto por los equipos remotos.

S i nos v amos a la pesta a "acceso" podremos eleg ir a qué usuarios queremos darle
acceso al recurso que hay amos creado.

E n la pantalla principal de la herramienta, si accedemos a la sección preferencias,

podremos config urar tanto nuev os usuarios como cambiar alg unos parámetros del
serv idor S amba.

Administración de sistemas de software libre 97

 Ca p ítulo 7

S erv icios d e im p res ión

E n cualquier red es importante prov eer a los usuarios de una serie de serv icios que
les aporten alg ún tipo de función. Uno de esos serv icios básicos es el de impresión
mediante el cual, una impresora conectada a un equipo podrá ser utilizada por
todos los usuarios de la red.

Al finalizar el estudio de estas lecciones serás capaz de:

Conocer el sistema de impresión CUPS .

C onfig urar una impresora local utilizando la herramienta web.

C onfig urar una impresora mediante la línea de comandos.

Ag reg ar una impresora remota como si se tratara de una local.

Administración de sistemas de software libre 98

 L e c ció n 1

E l s is tem a C U P S

C UPS ( C ommon Unix Printing S y stem) es un

sistema de impresión para S .O de tipo Unix que
permite a un equipo actuar como serv idor de
impresión. Así pues, un equipo cliente podrá
env iar tareas de impresión a este serv idor el
cual se encarg ará de g estionarlas para
satisfacer las necesidades del cliente.

E l desarrollo de cups comenzó en 1997 de

la mano de Michael S weet. Michael recurrió
al protocolo IPP ( Internet Printing Protocol)
para el desarrollo de cups. No pasó mucho
tiempo hasta que cups fue adoptado por la
may oría de distribuciones linux como su sistema de
impresión por defecto. E n 2002, Apple Inc comenzó a utilizar cups también como su
sistema de impresión por defecto y en 2007 compró el códig o fuente de cups.

E n cups, la información es env iada a un planificador o spooler, desde ahí, el trabajo

se env ía a un sistema de filtros que conv ierten el trabajo a un formato que entiende
la impresora y , finalmente, se env ían los datos a un backend el cual se trata de un
filtro especial que env ía los datos traducidos al formato que entiende la impresora,
a un periférico que será el encarg ado de la impresión en sí.

Desarrollándolo más profundamente, el proceso de imprimir implica los sig uientes

pasos:

1. Un usuario o un prog rama env ía un trabado de impresión.

2. E l trabajo se almacena en una cola de impresión ( concretamente en
/v ar/spool/cups) y ahí se crean dos archiv os para cada trabajo de impresión.
Uno de los archiv os son los propios datos a imprimir y el otro contiene
div ersa información sobre qué usuario ha mandado ese trabajo a imprimir
entre otras cosas.
3. E l planificador se encarg a de env iar los trabajos de impresión al sistema de
filtros para conv ertirlos a un formato que entienda la impresora.
4. E l sistema de filtros realiza la conv ersión de los trabajos determinando: el
tipo de datos utilizados por los trabajos, el número de pág inas que se v an a
imprimir, la resolución a la que se v a a imprimir, tama o de la hoja…
5. Una v ez hecha la conv ersión, los trabajos son env iados al backend o filtro
especial que se encarg a de pasárselos a la impresora que esté conectada al
equipo.
6. Una v ez que los trabajos han sido transmitidos a la impresora, el
planificador los elimina de la cola de impresión.

Administración de sistemas de software libre 99

E l fichero principal de config uración es / etc/ cups / cups d.conf. La sintaxis que
utiliza ese fichero es similar a la utilizada por el serv idor web apache. Alg unos de
los parámetros que podemos utilizar en dicho fichero son:

L og L ev el ? E stablece el tipo de información que aparecerá en los log s de

cups. Por defecto presenta el v alor info. S e le pueden pasar otros v alores
como: none, emerg , error, debug … en función de las necesidades que
teng amos.
L is ten ? E specifica el puerto en el cual atenderá peticiones el serv icios
cups. Por defecto utiliza el puerto escucha en localhost: 631.
B row s ing ? Muestra o no las impresoras disponibles dentro de la red. Por
defecto su v alor es On.
Max clients ? E specifica el número máximo de clientes que puede atender
el serv idor de manera simultánea.
A llow F rom ? E specifica a quien le permite el acceso a la zona declarada.
S i asig namos All, cualquiera podrá entrar. T ambién podemos especificar la ip
o el nombre de equipo de quien queramos que acceda.

E l fichero también tiene definidas zonas en las cuales se establecen sus propios
parámetros. E stas zonas empiezan con < Location> y acaban con < /Location> y los
parámetros que aparecen dentro sólo afectan a la ruta especificada junto a
Location.

Para más opciones lo mejor es consultar su pág ina man ? m an cups d.conf.

E l fichero / etc/ cups / printers .conf contiene la lista de las colas de impresión que
están config uradas en el equipo. C ada impresora aparece en una sección que
empieza con < nombre de la impresora> y acaba con < /Printer> Las opciones que
queramos aplicar a cada impresora deberán ir dentro de esas dos sentencias.
Alg unas de las opciones que se le pueden pasar son:

A ccepting ? S e le puede asig nar el v alor y es o no dependiendo de si

queremos que la impresora en cuestión acepte nuev os trabajos o no.
A llow U s er ? E specifica la lista de usuarios a los que se les permitirá utilizar
la impresora.
D eny Us er ? E specifica la lista de usuarios a los que se les deneg ará el uso
de la impresora en cuestión.
S hared ? E specifica si la impresora se comparte en la red o no
dependiendo de si se le asig na el v alor y es o no respectiv amente.

Para poder manejar todo lo relacionado con la impresión tenemos una serie de
comandos. E stos comandos pueden seg uir dos patrones: el estilo Berkeley o el
estilo S y stem V . Aquí nos v amos a centrar en el S y stem V con el objetiv o de no
complicar mucho esta sección y no mezclar los dos estilos.

Administración de sistemas de software libre 100

Com andos de g es tión de cups

Mediante el comando lp podemos g enerar nuev os trabajos de impresión. Al

comando lp se le especifican una serie de opciones y parámetros sobre el trabajo
que se v a a imprimir y se le asig na una cola de impresión para poder sacar esos
trabajos.

Alg unos de los parámetros que se le pueden pasar son:

- u ? E specifica el usuario con el cual se conectará al serv idor de impresión.

- d ? E specifica la impresora a la que se mandarán los trabajos de
impresión.
- i ? E specifica el job- id de un trabajo y a existente para modificar alg unas
de sus opciones.
- n ? Número de copias que queremos que nos saque del trabajo o trabajos.
- t ? Asig na un nombre al trabajo.

Alg unas de las opciones que se le pueden pasar son:

- o m edia = ta m a ño ? S e le asig na el tama o de pág ina.

- o cpi= N ? E n N especifica el número de caracteres a imprimir por pulg ada.
Por defecto son 10.
- o s caling = núm ero ? E scala los archiv os de imag en de tal forma que los
ajusta al porcentaje de la pág ina especificado en número para que se
impriman en una sola hoja o en v arias.

Para cancelar trabajos de impresión se utiliza el comando cancel.

Los parámetros que se le pueden pasar son los sig uientes:

- E ? Fuerza que la comunicación con el serv idor se

realice encriptada.
- U ? E specifica el usuario con el que conectarse con el
serv idor.
- a ? C ancela todos los trabajos en el destino
seleccionado o todos los trabajos en todos los destinos si no se le pasa
ning uno.
- h ? E lije un serv idor alternativ o.
- u ? C ancela los trabajos cuy o propietario sea el usuario especificado.

Administración de sistemas de software libre 101

Para mostrar información sobre los trabajos env iados a una cola de impresión entre
otras cosas, se utiliza el comando lps tat.

Alg unos de los parámetros que se le pueden pasar a lpstat son los sig uientes:

- l ? Muestra un listado de impresoras, clases y trabajos.

- p ? Muestra las impresoras y si tienen o no habilitada la impresión. S i no
se especifica ning una impresora se muestra todas.
- r ? Muestra si el serv icio cups está corriendo o no.
- u ? Muestra una lista de trabajos de impresión ordenados por el nombre
de usuario.
- d ? Muestra la cola de impresión por defecto.
- t ? Muestra toda la información de estado.

Podemos config urar impresoras y clases mediante el comando lpadm in. Una clase
es un conjunto de impresoras.

Alg unos de los parámetros que se le pueden

pasar a lpadmin son:

- c ? A ade la impresora especificada a la

clase que le dig amos. S i la clase no
existe la creará.
- r ? E limina la impresora seleccionada
de la clase que le dig amos. S i la clase
queda v acía se elimina también.
- v ? E stablece el "dev ice- uri" esto es la
cadena de conexión con la impresora.
Aquí se le especificará si se conecta por usb, v ía http, etc…
- D ? Muestra información detallada sobre la impresora seleccionada.
- E ? Habilita la impresora de manera que pueda aceptar trabajos.

C on el comando lpoptions podemos mostrar o establecer opciones de una

impresora.

Alg unos de los parámetros que se le pueden pasar son:

- l ? Lista las opciones específicas de la impresora y las opciones

establecidas.
- r ? E limina la opción seleccionada de la config uración de la impresora.
- o ? E specifica una nuev a opción para la impresora seleccionada.

Administración de sistemas de software libre 102

Ges tión de cups m ediante el interfaz w eb

La forma más sencilla de administrar cups es utilizando la interfaz web. E sta

interfaz es muy intuitiv a por lo que resulta muy sencillo config urar nuev as
impresoras, clases…

S e puede acceder a la interfaz web mediante http: //localhost: 631. Por defecto las
conexiones a dicha pág ina de administración desde un equipo que no sea en el que
está instalado cups no están permitidas.

¡ P onte a prueba!

V amos a modificar la config uración del serv idor cups de tal forma que permita
administrar el serv idor cups desde cualquier equipo de nuestra red.

Para permitir el acceso a la administración del serv idor cups mediante su

interfaz web debemos modificar el contenido del archiv o de config uración
/etc/cups/cupsd.conf. E n dicho fichero deberemos modificar lo sig uiente:

L is ten localhos t: 6 3 1 se modificará por L is ten * : 6 3 1

C on esto conseg uimos que escuche peticiones desde cualquier dirección ip en

el puerto 631

< L ocation / > < L ocation / >

O rder allow ,deny se modificará por O rder allow ,deny

< / L oca tion> A llow F rom 1 0 .0 .0 .0 / 2 4

< / L oca tion>

Permitimos el acceso a la raíz del sitio / a todos los equipos de la red

10.0.0.0/24 ( modifica esta red por la que teng as config urada o también puedes
asig nar el v alor All para permitirlo a todo el mundo.)

< L ocation / adm in> < L ocation / adm in>

E ncry ption R equired se modificará por E ncry ption R equired

O rder allow ,deny O rder allow ,deny

< / L oca tion> Allow From 1 0 .0 .0 .0 / 2 4

< / L oca tion>

Administración de sistemas de software libre 103

 Permitimos el acceso a /admin a todos los equipos de la red 10.0.0.0/24
( modifica esta red por la que teng as config urada o también puedes asig nar el
v alor All para permitirlo a todo el mundo.)

Una v ez hechos estos cambios, g uardamos el fichero, reiniciamos el serv icio

cups y y a podremos acceder a la interfaz web desde nuestro equipo físico.

/ etc/ init.d/ cups res tart

La interfaz web presenta el sig uiente aspecto. C omo se comprueba en la imag en,
está div idida en div ersas secciones muy descriptiv as que nos permiten implementar
todas las funciones. E sta imag en se corresponde con la sección "Inicio" que aparece
arriba en la cual se nos presentan una serie de controles.

S i pulsamos en "A y uda" v eremos como en la parte

derecha de la pág ina nos aparecen una serie de enlaces
a pág inas que nos explican cómo realizar div ersas
config uraciones. E sta ay uda se encuentra en ing lés pero
es la mejor que podemos encontrar y a que está
realizada por las personas que se encarg an del proy ecto
cups. S i desconocemos cómo realizar una config uración
específica, este es el sitio que deberíamos consultar
primero.

Administración de sistemas de software libre 104

S i pinchamos en "añadir clas e", podremos crear una nuev a clase en la que asig nar
impresoras, asig narle una descripción…

S i eleg imos la opción "añadir im pres ora" primero nos aparecerán una serie de
campos a rellenar con el nombre que le queramos asig nar a la impresora, la
ubicación donde se sitúa dicha impresora y la descripción que queramos asig narle.

E n el sig uiente paso se nos dará a eleg ir el tipo de conexión que se establece con el
dispositiv o.

Administración de sistemas de software libre 105

S i eleg imos un puerto serie, cups interpretará que la impresora está directamente
conectada a nuestro equipo y aparecerá el sig uiente menú en el cual se nos
permitirá config urar alg unos parámetros del puerto serie en cuestión.

E n el sig uiente menú se nos pedirá el modelo de la impresora y , si disponemos de

el, un archiv o PPD que funciona como un controlador de dispositiv o y permite
utilizar todas las características de una determinada impresora.

Después de este último paso, nos pedirá la cuenta de un usuario autorizado como
root para poder completar el proceso de a adir la impresora.

E n la sección "adm inis tra r cla s es " si tenemos alg una clase con una o v arias
impresoras config uradas nos permitirá modificar una serie de opciones que se
aplicarán a las impresoras que pertenezcan a dicha clase

Aquí podemos hacer que las impresoras de la clase no acepten trabajos, cancelar
los trabajos que estén en curso en cualquiera de las impresoras config uradas en
esta clase o no publicar las impresoras que pertenezcan a esta clase de manera que
no sean v istas por los usuarios de la red.

S i nos v amos a la opción "adm inis tra r im pres oras " tendremos las mismas
opciones que en "administrar clases" pero sólo se aplicarán a la impresora
seleccionada.

Administración de sistemas de software libre 106

Por último, si nos v amos a "adm inis trar s erv idor" tendremos todas las opciones
nombradas anteriormente además de un panel a la derecha con div ersas opciones:

Desde ese panel podremos modificar el fichero de config uración

/etc/cups/cupsd.conf directamente, v er los log s de errores del serv idor, el reg istro
de acceso…

Ges tión de cups m ediante s y s tem - config - printer

Hay otra forma de administrar el serv idor cups y es a trav és de la herramienta

g ráfica s y s tem - config - printer

Accedamos a "impresora nuev a" o a "clase nuev a" las opciones son similares a las
que aparecen en la interfaz web. La administración de cups mediante este método
no estará disponible en serv idores de producción al no tener estos entornos g ráficos
en la may oría de los casos.

S i pinchamos en "Impresora nuev a" podremos, al ig ual que en la interfaz web,

asig nar el nombre, la descripción y la ubicación de la nuev a impresora.

Administración de sistemas de software libre 107

E n la sig uiente pantalla nos dejará eleg ir el tipo de conexión que v a a usar la
impresora junto al dev ice- uri.

Después nos dejará eleg ir el tipo de impresora que v amos a utilizar o, si lo

tuv iéramos podríamos especificarle el archiv o PPD con los driv ers apropiados para
nuestra impresora.

Administración de sistemas de software libre 108

S i no hemos proporcionado los driv ers mediante la selección de un archiv o PPD, en
la sig uiente pantalla nos pedirá que elijamos los más adecuados desde una lista.

C on estos pasos y a habremos creado la nuev a impresora. Una v ez creada, nos

permitirá ajustar las opciones sobre esa impresora ig ual que si lo hiciéramos desde
la interfaz web.

También podemos administrar ciertas opciones del serv idor como por ejemplo
mostrar o no las impresoras config uradas a otros equipos o permitir a cualquier
usuario cancelar cualquier trabajo aunque no sea suy o.

Administración de sistemas de software libre 109

 Ca p ítulo 8
S erv icios w eb

Uno de los serv icios más importantes que podemos prov eer desde un equipo Linux
es el serv idor web. Mediante este, podremos ofrecer a los clientes y usuarios un
medio para subir sus pág inas web y que estas sean v istas desde todo el mundo.

Al finalizar el estudio de estas lecciones serás capaz de:

E ntender el protocolo HT T P.

S aber cómo funciona el serv idor web Apache.

C onfig urar el serv idor web Apache en base a las necesidades de los
usuarios.

Administración de sistemas de software libre 110

 L e c ció n 1
E l p rotocolo http

E l protocolo http ( hy pertext transfer protocol) es el método de

intercambio de información más común en la W orld W ide W eb.
E s un protocolo con modelo cliente- serv idor que posibilita el
intercambio de información entre los clientes y los serv idores
http o web.

Fue creado en 1990 en el CE R N como método para compartir

datos a niv el internacional. Aparece descrito en una serie de
R FC ( R equest For C omments) , es decir, unas notas que se utilizan para describir
nuev os protocolos de internet, siendo la v ersión R FC 2616 la más utilizada por
incluir esta la v ersión 1.1 del protocolo http.

E l hipertexto es el contenido de las pág inas web y el protocolo de transferencia es

el método se utiliza para env iar una petición a una pág ina web y la respuesta de la
web cuando se establezca la conexión. Así pues, este protocolo se puede utilizar
para env iar información bidireccionalmente entre un cliente y un serv idor web.

E l protocolo http es un protocolo s in es tado. E sto quiere decir que no se g uarda

ning una información sobre las conexiones realizadas de manera que cuando se ha
terminado de transmitir datos, la conexión se cierra y no se almacena ning ún tipo
de información.

A v eces es interesante que este no sea el comportamiento por defecto y es por lo

que aparecieron las llamadas cookies . Las cookies son unos ficheros que se
g eneran al acceder a ciertos sitios web y que se almacenan en el equipo del cliente
de manera que g uarden cierta información sobre la conexión establecida
posibilitando que, cuando el cliente v uelv a a acceder al sitio web, este reconozca al
usuario y pueda ofrecerle un mejor serv icio. E ste papel también lo asumirían las
llamadas s es iones . Una sesión es la secuencia de pág inas que un usuario ha
v isitado en un sitio web y cumple la misma función que la de las cook ies:
proporcionar un mejor serv icio al cliente la próxima v ez que acceda al sitio web.

C uando solicitamos que se nos sirv a una determinada pág ina web necesitaremos
especificar lo sig uiente:

Protocolo ( normalmente será http)

Dirección ip o nombre del host. Por ejemplo: www.g oog le.es
Puerto para la petición
Objeto solicitado. Por ejemplo: http: //www.g oog le.es/index.html

Como norma g eneral, el serv idor web al que nos conectemos serv irá unos v alores
por defecto. Como puerto el v alor por defecto es el 80 pero esto se puede modificar
en la config uración del serv idor web. C omo objeto solicitado, el serv idor buscará el
index.* del sitio a serv ir por defecto.

Administración de sistemas de software libre 111

E l proceso de una transacción http sería el sig uiente:

E l usuario accede a una UR L ( Uniform R esource Locator) a trav és del cliente

web o nav eg ador.
E l cliente web descodifica la información y la seg menta en partes ( protocolo,
puerto…)
S e establece una conexión TC P/IP con el serv idor y se realiza la petición
env iando el comando necesario ( GE T, POS T, HE AD…)
E l serv idor env ía la información solicitada al cliente.
E l cliente interpreta la información recibida de manera que sea
correctamente v isualizada en el nav eg ador por el usuario.
S e cierra la conexión TCP.

Un nav eg ador w eb es un prog rama que interpreta

la información solicitada a un serv idor web y la
muestra en pantalla de manera que el usuario
pueda interactuar con la misma. E ntre los
nav eg adores más utilizados se encuentran: Internet
E xplorer, Mozilla Firefox, Goog le Chrome, Opera o
S afari.

E l m ens aj e que el us ua rio env ía al serv idor web con el fin de

obtener la información solicitada sig ue un determinado formato
div idido en v arias secciones:

La primera línea que aparece se corresponde con el tipo de m ens aje. Para
peticiones aparecerá R equest y para respuestas R esponse.
Líneas de encabez ado. S on una serie de líneas opcionales que permiten
especificar información adicional sobre la solicitud env iada o sobre el cliente
( S .O utilizado, nav eg ador…) E stas líneas acaban con < crlf> ( retorno de
carro)
E l cuerpo del m ens aje empieza con una línea en blanco y después se
especifica lo que solicitamos al serv idor mediante una serie de comandos:
GE T : S olicita un recurso a una UR L del serv idor web.
H E A D : S olicita el encabezado de un recurso del serv idor web. E s
similar a g et pero sin el cuerpo de la respuesta.
P O S T : E nv ía datos a un prog rama de una UR L especificada del
serv idor web.
P U T : S ube un recurso especificado al serv idor web.
D E L E T E : Borra un recurso de la UR L del serv idor web.

Administración de sistemas de software libre 112

La res pues ta del s erv idor también está compuesta de v arias secciones:

La línea inicial tiene tres campos separados por un espacio y se

corresponden con: la v ers ión del protocolo, el códig o de res pues ta y el
m ens aj e. Por ejemplo, HT T P 1.0 220 OK . E xisten div ersos tipos de
respuestas del serv idor seg ún se produzca una situación u otra:
1 X X I nform ativ a: S e ha recibido la petición y se continúa con el
procesamiento de la misma.
2 X X E x itos a: La petición se recibió, se entendió y se aceptó.
3 X X R edirección: Para completar la solicitud deberá llev ar a cabo
otras acciones.
4 X X E rror de cliente: La solicitud contiene una sintaxis incorrecta o
no se puede llev ar a cabo.
5 X X E rror de s erv idor: E l serv idor no puedo atender una solicitud
aparentemente v álida.
Líneas de encabez ado que permiten especificar información sobre el
serv idor o sobre la propia respuesta.
E l cuerpo del m ens aj e contiene la información a transmitir o el mensaje
de error en el caso de que la transmisión hay a fallado.

Administración de sistemas de software libre 113

 L e c ció n 2
E l s erv idor a pa che

Apache es un serv idor web de códig o abierto que nació en 1995 y es utilizado en
sistemas Unix, Microsoft W indows y Macintosh. Al principio se basaba en el códig o
del serv idor web NC S A httpd pero más tarde se reescribió su códig o
completamente. Actualmente es el serv idor web más utilizado en el mundo por
delante del IIS de Microsoft. E sta situación ha sido propiciada por tratarse Apache
de un prog rama de códig o abierto pero también por una serie de características que
le aportan v alor como son:

F acilidad de config uración: Todos los parámetros del serv idor web se
pueden modificar mediante la edición del fichero de texto correspondiente.
Multipla taform a: E stá disponible para la may oría de S .O existentes.
Modularidad: E xiste la posibilidad de a adirle ciertos módulos que
permiten la utilización de nuev as opciones con el v alor que esto aporta al
serv idor.
P opula ridad: Al ser utilizado por mucha g ente es muy sencillo conseg uir
ay uda cuando tenemos alg ún problema.
H os ts v irtuales : Podemos serv ir muchos sitios web desde una sola
dirección ip.

¡ P onte a prueba!

E l serv idor Apache debería estar instalado en nuestra máquina v irtual C entos
por defecto. V amos a hacer que el serv icio se inicie por defecto a partir de
ahora y v amos a comprobar que funciona correctamente.

Lo primero v amos a hacer que el serv idor Apache se inicie por defecto las
próximas v eces que reiniciemos la máquina:

chkconfig httpd on

Lo comprobamos:

chkconfig - - lis t | g rep httpd

Comprobamos si el serv icio está funcionando:

/ etc/ init.d/ httpd s tatus

Administración de sistemas de software libre 114

 Iniciamos el serv idor web:

/ etc/ init.d/ httpd s tart

E l mensaje que aparece es normal y a que no disponemos de un nombre de

dominio que asociar con nuestras máquinas.

Ahora para comprobar que el serv idor web funciona correctamente podemos
acceder en un nav eg ador a la ip de nuestra máquina v irtual C entos y v eremos
la pág ina por defecto de Apache para C entos:

Ya hemos v isto en el ejercicio que el serv icio se llama httpd. Los puertos utilizados
por Apache por defecto son el 80 para peticiones http normales y el 443 para
peticiones de pág inas seg uras o https.

Los ficheros de config uración del serv idor se encuentran en /etc/httpd siendo el
fichero de config uración principal el / etc/ httpd/ conf/ httpd.conf en el cual
pueden aparecer, entre otros, los sig uientes parámetros:

L is ten ? E specifica el puerto o puertos en los que Apache atenderá las

peticiones de sitios web.
A cces s F ileNam e ? E specifica el fichero que se leerá de los directorios de
las webs en busca de opciones que se apliquen a ese sitio web.
L oadModule ? Permite carg ar un módulo especial de apache. E stos
módulos se encuentran en la ruta / etc/ httpd/ m odules .
E rrorLog ? R uta al fichero en donde se reflejarán los problemas que
existan con el serv idor web. E ste es el log que deberemos consultar cuando
teng amos alg ún problema.
L og L ev el ? Aquí se le puede especificar al serv idor la cantidad de
información que queremos que se refleje en los log s. Los niv eles que se
pueden establecer son en orden: debug , info, notice, warn, error, crit, alert
y emerg siendo debug el que más información mostraría. Por defecto el
v alor está a warn.
S erv erR oot ? La ruta raíz en la que se encuentran los ficheros de
config uración, de error y de log del serv idor Apache. Por defecto es
/etc/httpd.

Administración de sistemas de software libre 115

 D irectory I ndex ? Lista de las posibles pág inas de inicio que podrán utilizar
los sitios web config urados. E s útil cuando no se preg unta por un objeto en
concreto del serv idor sino por un directorio, así el serv idor sabría que fichero
serv ir.
T im eout ? T iempo máximo de v ida de una conexión entre cliente y
serv idor en la cual no se ha producido ni env ío ni recepción de información.
S i ha pasado este tiempo y no se ha transmitido información se cierra la
conexión. Por defecto se establece un timeout de 120 seg undos.
K eepA liv e O n/ Off ? E stablece si se permiten conexiones persistentes en
el serv idor o no. Las conexiones persistentes son las que solicitan v arios
pedidos httpd a trav és de la misma conexión.
Ma x K eepA liv eR eques ts ? Número máximo de peticiones que se permiten
durante una conexión persistente. S i se establece 0 entonces el número es
ilimitado. Por defecto su v alor es 100.
K eepA liv eT im eout ? Tiempo máximo entre peticiones dentro de una
conexión persistente antes de que esta se cierre. Por defecto es 15
seg undos.
I nclude ? T odos los ficheros que le especifiquemos a esta sentencia serán
tenidos en cuenta a la hora de ejecutar Apache.
D ocum entR oot ? Directorio desde el cual se serv irán los ficheros
pertenecientes a los diferentes sitios web.
A lias ? E specifica una ruta la cual será redirig ida a la ruta absoluta del
serv idor que nosotros le indiquemos.
A ddD efaultChars et ? E specifica la codificación por defecto que utilizarán
los diferentes sitios web. Por defecto se utiliza UT F- 8.
< I fModule ( nom bre del m ódulo) > < / I fModule> ? E specifica opciones
que sólo se aplicarán si un módulo en cuestión está carg ado.

Para consultar todas las directiv as y parámetros lo mejor es acudir directamente a

la pág ina de Apache http: / / httpd.apache.org / docs / 2 .2 /

Cuando modificamos cualquier fichero de config uración de Apache es recomendable

comprobar que la sintaxis sea correcta antes de reiniciar el serv icio puesto que si
no es correcta, el serv icio no arrancará y tendremos el serv icio detenido con el
problema que eso supone para los usuarios.

Con el fin de poder comprobar errores existe un script proporcionado por Apache
que se inv oca de la sig uiente forma:

/ etc/ init.d/ httpd config tes t o apachectl config tes t

S i nos dev uelv e un "S y ntax OK " es que no ha encontrado errores en la sintaxis y ,
por lo tanto podemos reiniciar el serv icio sin problemas. S i hubiera cualquier tipo de
problema, nos indicaría en qué fichero y en qué línea ha encontrado el defecto con
el fin de ay udarnos a solucionarlo.

Administración de sistemas de software libre 116

Por defecto, todos los ficheros .conf que se encuentren en la ruta
/ etc/ httpd/ conf.d/ son los que contienen la config uración de cada sitio en
concreto. E stos ficheros pueden llev ar asociados los sig uientes parámetros:

< V irtualhos t> ip: puerto< / V irtualhos t> ? S e utiliza para crear sitios
v irtuales. Dentro se config urarán los parámetros referentes a un sitio v irtual
en concreto. S e especifica la ip y el puerto en las que atenderá peticiones
ese host v irtual en concreto y después, mediante un S erv erName podemos
especificar el nombre del sitio web que estará config urado en ese host
v irtual.
S erv erNam e ? E s el nombre al que responderá el sitio web, es decir, el
encabezado del sitio.. E s muy útil cuando tenemos v arios sitios definidos en
la misma ip.
S erv erA lias ? Nombres alternativ os o encabezados adicionales a los cuales
responderá un determinado sitio web.
Na m eV irtua lH os t ? Aquí se especifica la ip en la cual el serv idor web
recibirá las peticiones de los hosts o sitios v irtuales.
< D irectory ( directorio del s itio w eb) > < / D irectory > ? S e define el
directorio del sitio web sobre el que se aplicarán las opciones especificadas a
continuación entre las dos sentencias Directory .
< F iles ( nom bre del fichero) > < / F iles > ? Las directiv as que aparezcan
debajo se aplicarán únicamente si existe el directorio especificado en la ruta
en la cual se encuentra la web.
A llow Ov erride ? C on este parámetro se especifican las directiv as que se
pueden sobreescribir de la config uración del serv idor.

S i en el sitio web en cuestión hay un fichero .htaccess con opciones diferentes a las
que aparecen en /etc/httpd/conf/httpd.conf, con este parámetro le especificaremos
qué opciones se podrán modificar mediante el fichero .htaccess
independientemente de las que teng a config uradas el serv idor. S e pueden
establecer v arios niv eles de permisiv idad: None, FileInfo, AuthC onfig , Indexes, All,
etc. Por motiv os de seg uridad es aconsejable establecer este parámetro a None en
la config uración g lobal del serv idor y , si alg ún sitio necesita una config uración
especial modificarlo sólo para ese sitio.

D eny from ? S e impedirá el acceso al cliente/s especificado. Podemos

especificar una ip o incluso poner un all si no queremos que acceda nadie.
A llow from ? S e permite el acceso al cliente/s especificado. Podemos
especificar una ip o incluso poner un all si queremos que acceda todo el
mundo.
O rder ? E specifica el orden en el que se comprobarán las sentencias Allow
y Deny . Por ejemplo con Order Allow, Deny se comprobarían primero las
sentencias Allow.
Options ? Podemos especificar una serie de opciones que se aplicarán a los
directorios de la web e cuestión. E xisten v arios tipos de opciones como por
ejemplo:
I ndex es ? S i está habilitada, cuando el usuario solicite un directorio
en el cual no exista ning una de las pág inas de inicio especificadas en

Administración de sistemas de software libre 117

 Directory Index se le dev uelv e una lista de los objetos que se
encuentran en ese directorio.
F ollow S y m L inks ? S e permiten seg uir los enlaces simbólicos desde
el directorio especificado. Por defecto no se sig uen estos enlaces.
MultiV iew s ? S i está activ o, cuando el usuario solicite un objeto y
este no exista, el serv idor neg ociará con el y le serv irá uno con
nombre parecido.
A ll ? S e incluy en todas las opciones salv o Multiv iews.

S i existe un directorio sobre el que se aplican v arias opciones se usan siempre las
más específicas a no ser que pong amos un "+ " o un "- " delante para indicar que
queremos o no que se apliquen a ese directorio. Por ejemplo si tenemos lo
sig uiente:

< Directory /v ar/www/dominio>

Options Indexes Multiv iews

< /Directory >

< Directory /v ar/www/dominio/prueba>

Options FollowS y mLinks

< Directory >

E l directorio /v ar/www/dominio/prueba sólo tendría la opción FollowS y mLinks. E n

cambio si tuv iéramos:

< Directory /v ar/www/dominio>

Options Indexes Multiv iews

< /Directory >

< Directory /v ar/www/dominio/prueba>

Options - Indexes + FollowS y mLinks

< Directory >

E n este caso las opciones aplicadas a /v ar/www/dominio/prueba serían Multiv iews y

FollowS y mLink s.

A lias ? C on este parámetro se puede especificar un directorio orig en y uno

destino de manera que cuando alg uien solicite el contenido del orig en se le
mostrará el del destino.

Administración de sistemas de software libre 118

E n la carpeta / etc/ httpd/ log s se encuentran los archiv os de log de apache.
E xisten dos ficheros principales, el acces s _ log y el error_ log . S i deseamos
comprobar quién ha accedido a un sitio web en concreto deberemos consultarlo en
el access_ log mientras que si estamos teniendo problemas con un sitio web debido
a que hay alg o que no nos funciona deberemos consultar el fichero error_ log para
depurar los fallos.

La carpeta / etc/ httpd/ m odules contiene los módulos de apache que hay
instalados en nuestro sistema. E l hecho de que estén en esta carpeta no implica
que estén activ os y a que para activ arlos es necesario que exista una entrada
LoadModule en /etc/httpd/conf/httpd.conf. Así pues, podemos instalar nuev os
módulos y posteriormente activ arlos mediante LoadModule.

Ges tión de la s eg uridad

Podemos config urar la seg uridad del serv idor de manera que limitemos el acceso a
un determinado recurso mediante un usuario y contrase a. Para ello existen una
serie de directiv as:

A uthT y pe ? Indica el tipo de autenticación que usará Apache.

Normalmente se prov ee el tipo basic el cual se basa en un fichero que
contiene una lista de usuarios y contrase as que se han g enerado
prev iamente con el comando htpas s w d . También se le puede asig nar
autenticación de tipo dig est pero el nav eg ador debe soportar esta modalidad
para poder llev arse a cabo.
A uthNa m e ? E s el mensaje que se presentará al usuario en el momento en
que se le solicite introducir las credenciales apropiadas para g anar acceso al
recurso.
A uthU s erF ile ? Aquí se especifica la ruta en la que se encuentra el fichero
que contiene los datos de los usuarios y las contrase as asig nadas con la
forma usuario: contrase a. E s importante limitar el acceso a este fichero
para g arantizar la máx ima seg uridad para el sitio. Como y a se ha dicho
anteriormente, este fichero se g enerará mediante el comando htpasswd.
A uthGroupF ile ? Funciona exactamente ig ual que AuthUserFile pero aquí
se le pueden definir listas de g rupos en lug ar de usuarios indiv iduales.
R equireU s er ? Aquí especificaremos los usuarios que queremos que
accedan cog iéndolos del fichero de autenticación. Para especificar que
queremos que accedan todos los que aparezcan en el fichero,
especificaríamos v alid- user.
R equireGroup ? E s exactamente ig ual que R equireUser pero se utiliza para
los g rupos contenidos en el fichero. Al ig ual que R equiereUser, si
quisiéramos que accedieran todos los g rupos listados en el fichero
seleccionaríamos v alid- user.

Administración de sistemas de software libre 119

E l comando htpasswd se suele usar seg uido de la opción - c, la ruta del fichero que
g enerará y finalmente el nombre de usuario. Una v ez hecho esto, nos preg untará la
contrase a. Por defecto sacará la contrase a encriptada en md5.

S i se v an a usar g rupos, hará falta g enerar un seg undo fichero de texto plano que
tendrá el sig uiente formato:

g rupo1: usuario1, usuario2…

g rupo2: usuario3, usuario5…

Además, en la config uración del sitio web en cuestión hará falta a adir
AuthGroupFile y también AuthUserFile para que sepa de dónde cog er los usuarios
pertenecientes a cada g rupo.

También podemos prov eer al serv idor de más seg uridad mediante el uso de HTTPS .
Https es una combinación del protocolo https y el S S L o TLS lo cual posibilita que
las comunicaciones entre cliente y serv idor se hag an de la manera más seg ura
posible.

Así pues, S S L son una serie de protocolos que utilizan v arios mecanismos de
encriptación, certificados dig itales y firmas dig itales con el objetiv o de que la
comunicación entre cliente y serv idor sea lo más seg ura posible.

Los mecanismos de encriptación que utiliza son:

S im étrica o de clav e com partida ? La clav e es conocida tanto por el

emisor como por el receptor con lo que resulta muy rápido y eficiente pero
ambos deben conocer la clav e pública.
A s im étrica o de clav e pública ? E n este método se utilizan dos clav es,
una pública y una priv ada. La clav e pública es conocida por todo el mundo
mientras que la clav e priv ada es conocida únicamente por el receptor. Así
pues, un emisor mandará el mensaje encriptado con la clav e pública y el
receptor lo desencriptará mediante la clav e priv ada. E ste procedimiento es
más seg uro pero también más lento y necesita que el emisor dispong a de un
certificado firmado por una entidad certificadora que demuestre que la clav e
pública del emisor es realmente suy a.

Para poder hacer uso del protocolo S S L deberemos instalar el paquete m od_ s s l

Una v ez que el módulo esté instalado y activ o, lo primero será g enerar una clav e
priv ada para lo cual se utilizará el comando opens s l de la sig uiente forma:

openssl g enrsa - rand / var/ log / messag es 1 0 2 4 > w w w .dominio.com.key

Lo que hacemos con esto es g enerar la clav e priv ada cog iendo caracteres aleatorios
del fichero /v ar/log /messag es. Lo sig uiente que hay que hacer es g enerar el C S R
( C ertificate S ig ning R equest) de la sig uiente manera:

openssl req - new - key w w w .dominio.com.key > w w w .dominio.com.csr

Administración de sistemas de software libre 120

Ahora se nos pedirán una serie de datos que deberemos rellenar de manera precisa
cuando se trate de un dominio real. S e nos pedirá un códig o de dos letras para el
país, el estado o prov incia, la ciudad, el nombre de la empresa, nombre de la
unidad, nombre exacto del host, dirección de correo y , opcionalmente, se podrá
a adir una clav e de acceso.

Una v ez g enerado el C S R , este debería ser env iado a una entidad certificadora
como V erisig n para que comprueben que todo está bien y , después de pag ar, nos
env íen el certificado para que podamos config urarlo en nuestro sitio web.

S i no queremos env iar el C S R a ning una entidad, podemos autoconfirmar el

certificado nosotros mismos. Para ello lo haremos de la sig uiente forma:

opens s l x 5 0 9 - req - day s 3 6 5 - in w w w .dom inio.com .cs r - s ig nkey

w w w .dom inio.com .key - out w w w .dom inio.com .crt

Así crearemos un certificado con estructura x509 y que tendrá una v alidez de un
a o.

Ahora habrá que hacer que Apache escuche también en el puerto 443 cambiando el
parámetro Listen en /etc/httpd/conf/httpd.conf y , a la hora de config urar el sitio
web, habrá que poner:

< V irtua lhos t * : 4 4 3 >

Y a adir las sig uientes directiv as:

S S L E ng ine O n

S S L CertificateF ile ( ruta al certificado)

S S L CertificateK ey F ile ( ruta a la clav e priv ada del certificado)

Administración de sistemas de software libre 121

 Ca p ítulo 9

S erv icios d e red

E n este capítulo se v an a estudiar tres de los serv icios más importantes, el serv icio
dns, el serv icio dhcp y el serv icio proxy . E l serv icio dns es probablemente el más
importante de entre todos los serv icios relacionados con internet debido a que el
resto de serv icios dependen de el.

Al finalizar el estudio de estas lecciones serás capaz de:

E ntender el funcionamiento de la resolución de nombres de dominio.

C onfig urar un serv idor dns de manera que se puedan resolv er ciertos
nombres de dominio.

E ntender el funcionamiento del serv icio de asig nación dinámica de host

( dhcp)

C onfig urar un serv idor dhcp de manera que pueda prov eer a sus clientes sus
parámetros de red.

E ntender las funciones de un serv idor proxy .

C onfig uración de un serv idor proxy para que los clientes lo usen como
intermediario y poder g estionar la seg uridad y los accesos.

Administración de sistemas de software libre 122

 L e c ció n 1

D NS

DNS ( Domain Name S erv er) es un serv icio que permite asociar un nombre a
cualquier equipo conectado a la red. E n los primeros días de internet había muy
pocos equipos conectados a la red por lo que se usaba un fichero de texto que
contenía las correspondencias entre equipos e ips. A medida que internet se fue
extendiendo y más equipos pasaron a formar parte de la red, este sistema se hizo
inv iable y de ahí nació el sistema dns.

Así pues, el sistema dns es una enorme base de datos distribuida y jerárquica que
contiene la información de los equipos conectados a la red. Para la g ente es mucho
más sencillo acordarse de un nombre que de una ip.

E l serv icio está compuesto de:

Un cliente dns : E s un prog rama que se ejecuta en el equipo de un

determinado cliente y que g enera peticiones a un serv idor dns para que este
le transforme un nombre de un dominio determinado en la ip asociada con
el. Así pues, si le preg untamos al serv idor dns por www.g oog le.es, nos
transformará la petición en una dirección ip para saber en qué máquina en
concreto se encuentra alojada dicha web.
Un s erv idor dns : Los serv idores dns son los encarg ados de responder las
peticiones de los clientes dev olv iéndoles la ip asociada con el nombre del
dominio que hay an solicitado. E n caso de no disponer de la respuesta, son
capaces de reenv iar la petición a otro serv idor dns que sepa resolv er la
consulta.

E l sistema dns es una estructura jerárquica en forma de árbol:

La raíz del sistema dns se representa con un "." C ada nodo representa una
etiqueta.

Administración de sistemas de software libre 123

Así pues, del nodo raíz cuelg an los T L D ( T op Lev el Domains) o dominios de niv el
superior. E xisten una serie de T LD g enéricos como son el com, el org , el net… y
lueg o un TLD específico de dos letras que se corresponde con cada país: es para
E spa a, uk para R eino Unido…

Los niv eles inferiores se corresponden con etiquetas que sirv en para nombrar un
subdominio y la etiqueta que está más abajo normalmente se usa para identificar
una máquina en concreto.

Así, cuando alg uien solicita la resolución de un determinado nombre de dominio se

g enera una petición que se dirig e al serv idor DNS que teng a config urado. S i el
serv idor dns al que se ha preg untado dispone de la información necesaria para
responder a la petición la contestará. S i no es así, el serv idor dns pasará la petición
a otro serv idor que sí pueda responder a esa consulta.

E stas peticiones que se realizan a los serv idores dns pueden ser de dos tipos:

R ecurs iv as : S e requiere que el serv idor dns hag a una consulta con la
solicitud del cliente y , una v ez encontrada la respuesta se la dev uelv a al
cliente por lo tanto la carg a de trabajo recae sobre el serv idor.
I terativ as : E l serv idor dns le proporciona al cliente la información de la que
dispong a además de una lista de serv idores adicionales que el cliente podrá
utilizar para completar la información solicitada de tal forma que la carg a de
trabajo recae sobre el cliente.

C on el objetiv o de hacer todo este proceso de una manera más eficaz, entra en
jueg o la llamada caché. C uando un serv idor dns realiza una consulta y obtiene una
respuesta, se almacena en su caché de manera que cuando un usuario v uelv a a
hacer la misma consulta sabrá responderla utilizando los datos de la caché y por lo
tanto no se perderá tiempo intentando resolv erla por los cauces normales.

C uando se ha conseg uido resolv er un nombre de dominio y se tienen todos los

nodos que forman parte del mismo hasta la raíz se obtiene lo que se llama un
F QD N ( Fully Qualified Domain Name)

Todo lo comentado anteriormente se refiere a la traducción de un nombre de

dominio en una ip, pero también podemos solicitar lo contrario: conv ertir una ip
dada en un nombre de dominio lo que es conocido como res olución inv ers a.

E l responsable tanto del dominios raíz como de los

dominios de primer niv el ( TLD) es el I CA NN
( Internet C orporation for Assig ned Names and
Numbers) . E l IC ANN es una org anización encarg ada
de g estionar estos dominios así como de conceder
nuev os dominios y direcciones ips. T ambién poseen
13 serv idores dns distribuidos por el mundo ( TNS :
Top Name S erv er) que poseen la información
replicada de todos los dominios de seg undo niv el
( 2LD) del mundo.

Administración de sistemas de software libre 124

T ipos de s erv idores dns

Antes de conocer los tipos de serv idores dns es necesario saber el concepto de
zona. Una z ona es la parte de un dominio que g estiona una org anización. Así pues,
nosotros sólo podremos g estionar los datos de las zonas sobre las que teng amos
autoridad.

E xisten v arios tipos de serv idores dns seg ún la función que desempe en:

P rim ario: S e encarg a de serv ir la información referente a una determinada

zona y tiene autoridad sobre ella.
S ecundario: Un serv idor dns secundario es aquel que tiene autoridad sobre
una zona específica pero la información no la g enera el sino que la obtiene
un dns primario a trav és de un proceso conocido como "transferencia de
zona". C ada v ez que el serv idor primario realiza un cambio en la
config uración se la transmite al secundario para que ambos se encuentren
sincronizados.
T ambién se les puede llamar "maestro" y "esclav o".
Para poder transferir un fichero de zona a un serv idor esclav o, el serv idor
esclav o debe aparecer como serv idor dns en el fichero de zona que está
config urado en el maestro.
Caché: Un serv idor dns con la función de cache no tiene autoridad sobre
ning una zona y lo que hace es que cuando recibe una consulta por parte de
un cliente la reenv ía a un serv idor que pueda responderla y , una v ez
obtenida la respuesta la almacena en su base de datos de manera que si se
v uelv e a realizar la misma consulta, el serv idor conocerá la respuesta.
R eenv ío: E s un serv idor que no tiene autoridad sobre ning una zona y , por
lo tanto, cuando recibe una petición de un cliente la reenv ía a un serv idor
que sí pueda resolv erla.

T ipos de reg is tros dns

Las zonas de autoridad que poseen los serv idores dns suelen almacenarse en un
fichero que contendrá alg uno o todos los sig uientes reg istros:

A ( A ddres s ) : R eg istro que contiene la dirección ip asociada a un

determinado nombre de host.
CNA ME ( Canonical Na m e) : E s un tipo de reg istro utilizado como alias para
apuntar un determinado subdominio a otra entrada dns. T anto el orig en
como el destino deben ser nombres.
NS ( Nam e S erv er) : S e especifican los serv idores dns que almacenan la
información del dominio en cuestión.
S OA ( S ta rt O f A uthority ) : Aquí se especifica el serv idor dns principal con
autoridad sobre la zona.

Administración de sistemas de software libre 125

 MX ( Mail E x chang e) : Aquí se especifica el nombre del serv idor de correo
que se utilizará cuando se env íen emails al dominio en cuestión. S e pueden
tener v arios reg istros MX dependiendo del número de serv idores de correo
que se utilicen. A estos serv idores se les puede asig nar una prioridad de
manera que cuando se env íe un correo se elija siempre el serv idor con
may or prioridad ( siendo 1 la prioridad may or) .
P T R ( P ointer) : S e utiliza para realizar la resolución inv ersa por lo que
funcionan al rev és que los reg istros de tipo A. S e especifica una ip y se
apunta al nombre que necesitemos.

E xisten más reg istros dns como txt, loc, wks… pero los anteriores son considerados
los más importantes.

Podemos comprobar el correcto funcionamiento de la resolución de nombres

además de con el comando ping mediante el comando dig :

La sintaxis de dig es la sig uiente:

dig @ s erv idor dns nom bre del hos t opciones tipo

Así pues, podemos eleg ir el serv idor dns al que preg untar por un cierto nombre de
dominio poniendo la "@ " delante.

E n "tipo" introduciremos la entrada por la que deseemos preg untar: MX , A,

C NAME …

Por ejemplo, si quisiéramos preg untar por la entrada MX de g oog le.es al serv idor
dns de telefónica 80.58.0.33 lo haríamos de la sig uiente forma:

dig @ 8 0 .5 8 .0 .3 3 g oog le.es MX

Administración de sistemas de software libre 126

Nos dev uelv e todos los reg istros MX de g oog le.es que son cuatro, con la prioridad
de todos ellos ( 10) y más abajo resuelv e la ip de cada uno de ellos. Debajo aparece
el tiempo de resolución de la consulta ( 97 ms) , esto es importante porque puede
ay udarnos a determinar cuál es el serv idor dns más adecuado para nosotros.

S i v olv emos a hacer la misma preg unta comprobaremos que el tiempo de

resolución baja considerablemente al encontrarse esta en cache:

T ambién podemos preg untar por un reg istro inv erso con la opción - x

Para un uso más av anzado de la herramienta, lo mejor es consultar su pág ina man.

S erv idor dns B ind

Aunque existen otros serv idores dns como puedan ser MaraDns o PowerDns entre
otros, Bind ( Berkeley Internet Name Domain) es actualmente el más usado en
internet. Actualmente se encuentra en su v ersión 9.7.3.

¡ P onte a prueba!

V amos a instalar Bind en nuestro máquina C entos, para ello instalaremos el

paquete bind y bind- utils y v amos a hacer que esté habilitado por defecto
siempre que se arranque el S .O.

Instalamos los paquetes bind y bind- utils en nuestra máquina centos:

y um ins tall bind bind- utils bind- chroot caching - nam es erv er

Una v ez instalado el serv idor dns procedemos a dejarlo habilitado por defecto
para los sig uientes arranques del sistema. E l demonio de bind se llama named:

chkconfig nam ed on

C omprobamos que el serv icio está activ ado en los respectiv os

niv eles correctamente:

chkconfig - - lis t | g rep nam ed

Administración de sistemas de software libre 127

E l paquete bind- chroot prov ee una forma automatizada de prov eer un entorno
"chroot" para el serv idor dns. Para ello, coloca todos los archiv os que necesita bind
en un árbol de directorios ( por defecto /v ar/namd/chroot) de manera que no puede
acceder a ning ún archiv o o fichero que se encuentre fuera de esa ruta y haciéndolo
mucho más seg uro. Cualquier fichero referenciado en el archiv o de config uración de
bind deberá estar en esa ruta o de lo contrario no funcionará.

Para habilitar este entorno "chrooteado" bastaría con ejecutar bind- chroot- adm in
-e

E l paquete caching - nam es erv er a ade una config uración por defecto a bind de tal
forma que hace que se comporte como un serv idor de caché, es decir, que hag a las
consultas a otros serv idores dns y una v ez que teng a la respuesta la almacena en
la caché para las sig uientes consultas.

Los archiv os principales de bind están en / v ar/ nam ed/ chroot/ etc/ y
/ v ar/ nam ed/ chroot/ v ar/ nam ed.

E n /v ar/named/chroot/etc se encuentran los archiv os principales de config uración

en los cuales se declaran las zonas y se definen las opciones. T odas las líneas
acaban con un "; ", a modo de ejemplo aparece el fichero nam ed.ca ching -
nam es erv er.conf por lo que lo mejor es echarle un v istazo con un editor de texto:

Administración de sistemas de software libre 128

A continuación se incluy en alg unas opciones que podemos especificar en la
config uración de estos archiv os:

lis ten- on ? especifica el puerto y la ip en la que estará escuchando el

serv idor dns. Por defecto aparece lo sig uiente: lis ten- on port 5 3 {
1 2 7 .0 .0 .1 ; } ; lo cual indica que se escuchará en el puerto 53 en la ip
127.0.0.1, es decir, la propia máquina donde se está ejecutando.
directory ? E specifica el directorio de trabajo del serv idor dns. Por defecto
utiliza /v ar/named ( es una ruta relativ a, la ruta absoluta sería
/ v ar/ nam ed/ chroot/ v ar/ nam ed/
s tatis tics - file ? Define el fichero donde se reflejarán las estadísticas de
bind. Aquí se especificará la ruta relativ a.
allow - query { } ? E specifica los hosts autorizados a pedir una resolución de
nombres al serv idor dns. Por defecto sólo se permite a localhost.
forw a rders { } ? E specifica los serv idores dns a los que preg untará el
nuestro en caso de que necesite resolv er un nombre de dominio.
forw ard ? Indica la manera en la que el serv idor dns g estionará las
peticiones con los otros serv idores que teng a definidos en la v ariable
forwarders. S i se establece el v alor firs t, el serv idor dns preg untará a los
serv idores definidos en forwarders y si no son capaces de resolv er la
consulta, la intentará resolv er el mismo. S i se establece el v alor only , se
preg untará a los serv idores dns config urados en forwarders y , si no son
capaces de resolv er la consulta, el serv idor dns no intentará resolv erla.
acl " nom bre de la acl" { } ? Define una lista de direcciones ip o nombres
que se utilizarán más tarde para config urar opciones específicas para cada
acl.
Por defecto v ienen config uradas las sig uientes acls:
- any ? E n esta acl se incluy e cualquier host.
- none ? Ning ún host.
- loca lhos t ? Cualquier dirección ip del serv idor dns.
- loca lnets ? Cualquier host o equipo que se encuentre en las
subredes en las que está el serv idor dns.
allow - recurs ion{ } ? E specifica los hosts autorizados para realizar
consultas recursiv as.
allow - trans fer{ } ? E specifica el host o hosts a los cuales se autoriza la
transferencia de zonas.
v iew " nom bre de la v is ta " { } ? E specifica una v ista en la que se incluirá
la información que querremos que v ean ciertos usuarios.
- m atch- clients { } ? E specifica los usuarios a los que se les aplicará
la v ista.
z one " nom bre de z ona " { } ? E specifica el nombre de la zona que v amos
a declarar. A la hora de declarar una zona de resolución inv ersa lo haremos
inv irtiendo el orden de los tres primeros octectos de la ip y a adiendo in-
addr.arpa. Por ejemplo, con la red 192.168.19.0, la zona quedaría así:
z one " 1 9 .1 6 8 .1 9 2 - in- a ddr.arpa " {

Administración de sistemas de software libre 129

 - ty pe ? E specifica el tipo de zona que se declara. Los tipos más
usados son master y slav e. S i se declara una zona de tipo m a s ter, el
serv idor dns leerá la información de esa zona directamente desde su
almacenamiento local y prov eerá respuestas de esa zona para otros
serv idores cuando le preg unten.
S i la zona es de tipo s lav e, los datos los cog erá del fichero de zona
que le hay a transferido el serv idor maestro si ese fichero se encuentra
correctamente sincronizado.
- m as ters { } ? E specifica el serv idor maestro del cual se transferirá la
zona al serv idor esclav o.
- file " fichero de z ona " ? E specifica el nombre del fichero del cual se
leerá la información de la zona en cuestión.
log g ing { } ? E n esta sección se describe todo lo relacionado con los log s
que se mostrarán sobre el serv idor dns.
- channel nom bre del canal{ } ? E sta sentencia v a dentro de
log g ing { } y declara el nombre de un nuev o canal de log que llev ará
asociado sus propias opciones permitiéndonos config urar diferentes
canales en función de la cantidad de información que queramos que
saque cada uno.
- file " fichero de log " ? Aquí se define el fichero de log que
será usado por el canal que se acaba de declarar.
- s ev erity ? E specifica el niv el de los mensajes que se v erán
reflejados en el fichero de log siendo de más sev eros a menos:
critical, error, warning , notice, info, debug , dy namic. S e
reflejarán todos los mensajes de niv el ig ual o superior al
especificado.
- print- tim e y es / no ? Indica si en el fichero de log se debe
mostrar el día y la hora.
- print- s ev erity y es / no ? Indica si en el fichero de log se debe
mostrar el parámetro sev erity .
- categ ory nom bre del ca nal{ } ? Indica la categ oría de los
mensajes que se v an a imprimir en el fichero de log como pueden ser:
defaults, queries, clients…
La estructura del log g ing sería la sig uiente:
log g ing {
channel nombre del canal {
R uta al fichero
severity (critical | error | warning | notice |info | debug [ level ] | dynamic );
[ print- categ ory y es | no;
[ print- sev erity y es | no;
[ print- time y es | no;
};
categ ory tipo de categ oría {
nombre del canal;
};
...
};

Administración de sistemas de software libre 130

Ahora v amos a fijarnos en la sintaxis de los ficheros de zona los cuales se
encuentran por defecto en / v ar/ nam ed/ chroot/ v ar/ nam ed y tienen la sig uiente
forma:

T T L : E l T T L especifica el tiempo de v ida de los reg istros que definamos en el

fichero. Podríamos definir un T T L para cada reg istro si quisiéramos pero
colocándolo en la parte superior del fichero se aplica g lobalmente a todos los
reg istros que aparecen en el. E l tiempo de v ida determina el tiempo máximo
que deben mantener otros serv idores ese reg istro en caché antes de
solicitarlo de nuev o. S e especifica en seg undos.
C on la @ nos referimos al propio dominio que estamos config urando. S i
estamos config urando el archiv o de zona del dominio cursosl.com, la @ se
referiría a cursosl.com
Después de S O A ( S tart of Authority ) se especifica el nombre del serv idor
dns al cual pertenece la zona.
A continuación aparece el nom bre del us uario ( puede ser una cuenta de
correo) encarg ado de administrar el serv idor dns.
s erial ? E specifica el número de v ersión del fichero de zona. Cuando se
hag a cualquier modificación en el fichero de zona se deberá incrementar el
v alor del serial. Lo ideal es asig nar este v alor sig uiente la notación
AAAAMMDD de manera que sabremos el día exacto en el que se hizo una
modificación sobre el fichero de zona y de esa forma, el número siempre
será may or. C ada cierto tiempo, los serv idores dns secundarios solicitan al
primario el serial y , si comprueban que este ha cambiado, actualizan la
información que poseen sobre dicha zona. Así pues, incrementando este
número conseg uiremos que los demás serv idores dns hag an eco de las
modificaciones realizadas sobre una determinada zona.
refres h ? E specifica el tiempo que esperan los serv idores secundarios
antes de solicitar de nuev o el reg istro S OA al serv idor dns primario.
retry ? Tiempo que esperarán los serv idores dns secundarios antes de
v olv er a pedir información sobre una zona al serv idor primario cuando la
comunicación hay a fallado.
ex piry ? E specifica el tiempo que tardarán los serv idores dns secundarios
antes de descartar la información sobre una zona del dns primario cuando
no han podido contactar con el.

Administración de sistemas de software libre 131

E n la parte de debajo se empiezan a especificar los reg istros. E n todos los reg istros
se sobreentiende que llev an el nombre de la zona detrás. Por ejemplo, si
estuv iéramos config urando la zona dominio.com y quisiéramos a adir una entrada
para el reg istro www de tipo CNAME que apuntase a g oog le.es sería de la sig uiente
forma:

www IN C NAME g oog le.es

S i quisiéramos hacer la resolución inv ersa de la ip 20 de la red mencionada

anteriormente ( 192.168.19.0) para que mostrara el reg istro web.dominio.com en el
fichero de zona 19.168.192- in- addr.arpa quedaría de la sig uiente forma:

20 IN PTR web.dominio.com.

E s importante comentar que cualquier nombre que aparezca en el fichero de zona

se considera abs oluto si acaba en "." E n el caso de que no acabe en punto, se
considerará rela tiv o y por lo tanto se le a adirá el nombre del dominio al final del
mismo.

Una v ez que modifiquemos los ficheros de config uración de bind deberíamos

chequear que estén correctos mediante la herramienta na m ed- checkconf S i se ha
modificado todo de manera correcta, la herramienta no dev olv erá nada y si por lo
contrario hay alg o en la sintaxis que está equiv ocado nos av isará para que
podamos correg irlo.

La mejor pág ina para consultar la información sobre bind es la oficial:

http: / / w w w .bind9 .net/ m anua ls

T ambién podemos consultar la documentación que v iene a la hora de instalar el

paquete en / us r/ s hare/ doc/ bind- nº v ers ión/ s a m ple/ en el cual aparecen
ejemplos de config uraciones que sirv en de mucha ay uda. Muchas v eces los
problemas con bind se producen por permisos incorrectos por lo que es aconsejable
rev isarlos.

Administración de sistemas de software libre 132

 L e c ció n 2

DHCP

DHC P ( Dy namic Host C onfig uration Protocol) - protocolo de config uración dinámica
de host fue creado en el a o 1993 y se trata de un protocolo de red que permite a
los clientes obtener su config uración de red automáticamente. Así pues, se trata de
un protocolo cliente/serv idor en el cual el serv idor prov ee a los clientes de una
config uración específica de red cuando la necesitan y g estiona los tiempos de
concesión para que el serv icio esté siempre disponible para el resto.

E l protocolo dhcp utiliza los puerto 67/udp ( serv idor) y 68/udp ( cliente) . Utilizando
dhcp conseg uimos ahorrar tiempo debido a que nos ev ita tener que asig nar la
config uración de red manualmente en todos los equipos de una red.

E l protocolo dhcp permite config urar la asig nación automática de:

Dirección ip.
Máscara de red.
Puerta de enlace.
Tiempo de concesión ( lease time) .
Tiempo de renov ación ( renewal time) .
S erv idores dns
S erv idor smtp
…

A la hora de asig nar direcciones ip, dhcp utiliza tres métodos distintos:

A s ig nación es tática: Asig na una dirección ip a una máquina determinada.

A s ig nación dinám ica: E l serv idor dhcp tiene config urado un rang o de ips
que son las que asig nará a los clientes que se conecten. Así pues, cuando
una máquina de la red se conecta, se le asig na una ip del rang o config urado
en el serv idor.
A s ig nación autom ática: S e asig na una dirección ip de forma permanente a
una máquina que se conecta al serv idor dhcp y se la deja hasta que el
cliente la libera.

La conexión que realiza el cliente con el serv idor dhcp se realiza de la sig uiente
sig uiendo los sig uientes pasos:

1. D H CP D is cov ery : S e hace una petición de parámetros de red por parte del
cliente. Para ello se difunde una petición con dirección orig en 0.0.0.0 y de
dirección destino 255.255.255.255. E sta petición la atenderá un serv idor
dhcp que se encuentre en la misma red que el cliente.

Administración de sistemas de software libre 133

 2. D H CP Offer: E l serv idor dhcp responde al cliente env iándole sus parámetros
de red ( dirección ip, máscara de red, puerta de enlace…)
3. D H CP R eques t: E l cliente acepta los parámetros ofrecidos por el serv idor y
env ía un mensaje de aceptación a trav és de la red para ev itar que otros
serv idores dhcp le hag an otra propuesta.
4. D H CP A ck: E l serv idor dhcp env ía un mensaje al cliente diciendo que ha
recibido su mensaje dhcp request y por lo tanto, el cliente y a puede utilizar
los parámetros de red proporcionados y el serv idor se encarg ará de nos
asig narlos a otro cliente que hag a una petición.

E s posible que el serv idor dns indique al cliente que los datos proporcionados y a no
son v álidos y por lo tanto no puede asig nárselos. E n ese caso el serv idor env iaría
un D H CP Na ck

C uando el cliente libera la config uración de red proporcionada por el serv idor env ía
un mensaje D H CP R eleas e para que esos parámetros puedan ser usados por otro
cliente.

C uando se ag ota el 50% del tiempo de concesión de los parámetros de red al

cliente, este debe realizar nuev amente una petición dhcp al serv idor.

C uando un cliente no es capaz de contactar con un serv idor dhcp, se utiliza la

llamada asig nación "APIPA" que consiste en la asig nación de una dirección ip de la
red 169.254.0.0

S erv idor y cliente D H CP

¡ P onte a prueba!

V amos a instalar el serv idor dhcp en nuestra máquina v irtual centos y v amos a
hacer que arranque automáticamente cuando se inicie el sistema.

S i ejecutamos un y um s ea rch dhcp v eremos que el paquete que nos interesa

son es el sig uiente:

Procedemos a instalarlo:

y um ins tall dhcp

Una v ez instalado el serv idor dhcp, hacemos que se inicie

siempre con el arranque del sistema:

chkconfig dhcpd on

Administración de sistemas de software libre 134

 Finalmente comprobamos que esté habilitado:

chkconfig - - lis t | g rep dhcpd

E l fichero principal de config uración del serv idor dhcp es / etc/ dhcpd.conf. La
config uración de dicho fichero se realiza utilizando declaraciones y pará m etros .
C ada línea acaba con un "; "

Las declaraciones se utilizan para describir redes, máquinas o conjuntos de

máquinas.

Los parám etros especifican la forma de la que funcionará el serv idor dhcp. E stos
parámetros pueden set tanto g lobales ( afectan a todo el serv idor) o locales ( afectan
sólo a la declaración en cuestión. Los parámetros que se especifican incluy endo la
palabra option delante son parámetros que describen la información proporcionada
al cliente por el serv idor. Los que no llev an option delante especifican
características del propio protocolo dhcp.

Como declaraciones estarían las sig uientes:

s ubnet ip de la red/ m ás cara de red{ } ? S e declara una subred a la que

se aplicarán las opciones especificadas en este bloque.
s hared- netw ork { } ? S e declara una subred compartida. Aquí se
especifican todas las subredes que comparten la misma red física.
hos t { } ? S e declara una máquina sobre la que se aplicarán las opciones
que especifiquemos.
g roup { } ? S e declara un g rupo de subredes, máquinas… sobre el que se
aplicarán una serie de opciones especificadas debajo.

A continuación se exponen alg unos de los parámetros config urables:

rang e ip com ienz o ip fina l ? S e define un rang o de direcciones ip que se

asig narán a los clientes que soliciten la asig nación de sus parámetros de red.
default- leas e- tim e ? E specifica el tiempo en seg undos que se mantendrá
la config uración asig nada a un cliente siempre que el propio cliente no
especifique otra cosa.
m ax - leas e- tim e ? S e especifica el tiempo máximo en seg undos que se
mantendrá la config uración facilitada a los clientes.
s erv er- nam e ? Nombre del serv idor que se le proporcionará al cliente
cuando se conecte al serv idor dhcp para solicitar una asig nación.

Administración de sistemas de software libre 135

 option dom ain- nam e- s erv ers ? Aquí se especifica el nombre de los
serv idores dns.
option dom ain- nam e ? Nombre del dominio que se le proporciona al
cliente.
ddns - update- s ty le ? Define el método de actualización automática de los
dns. S e pueden especificar los v alores interim y none. C on none ( v alor por
defecto) no se tiene en cuenta el serv idor dns y con interim es al contrario.
option ntp- s erv ers ? S e especifican los serv idores de tiempo a asig nar.
E sto es útil cuando queremos que todos los equipos de una red usen el
mismo serv idor de hora y por lo tanto se encuentren sincronizados.
option dom ain- nam e- s erv ers ? S e definen los serv idores de nombres
que se aplicarán a la config uración.
option routers ? S e definen los routers o puertas de enlace que usará el
cliente para la salida a internet.
option hos t- nam e " " ? S e especifica el nombre de host que se le asig nará
al cliente. No se modifica si y a existe un nombre de host en el cliente.
fix ed- addres s ? C on esta opción se define la dirección estática a asig nar a
un determinado host.
hardw are tipo ? E specifica la dirección mac de un cliente de tal forma que
este sea reconocido por el serv idor dhcp. Puede ser de tipo ethernet o token
ring .

Para más opciones lo mejor es acudir a su pág ina man: m an dhcpd.conf. T ambién
se puede consultar la documentación que se encuentra en /usr/share/doc/dhcp-
v ersión.

Podemos comprobar la sintaxis del fichero de config uración mediante un

/ etc/ init.d/ dhcpd config tes t porque si encuentra alg ún problema, el serv icio no
se lev antará.

Por motiv os de seg uridad, es posible que queramos forzar que el serv idor dhcp
atienda peticiones de otros hosts a trav és de una determinada interfaz de red.
Podemos modificar esta config uración en el fichero /etc/sy sconfig /dhcpd y modificar
el parámetro DHCPDAR GS = "interfaz de red"

E n la parte del cliente, se utiliza la herramienta dhclient a la cual se le pasa la

interfaz de red que queremos config urar por dhcp. T ambién se le pueden pasar
parámetros alg unos de los cuales son:

- p ? E specifica el puerto a trav és del cual el cliente dhcp escuchará

conexiones y las transmitirá.
- T ? E specifica el timeout. E l timeout es el tiempo que esperará el cliente
dhcp cuando no puede contactar con un serv idor dhcp antes de desistir en el
intento de conexión.
- s ? E specifica el serv idor dhcp del cual intentará conseg uir los datos de
config uración de red.

Administración de sistemas de software libre 136

E stas opciones pueden ser config uradas por defecto en el fichero
/ etc/ dhclient.conf de tal forma que no hag a falta especificar los parámetros a la
herramienta dhclient cada v ez que queramos obtener los datos de un serv idor
dhcp. Alg unos de los parámetros que se pueden establecer son:

tim eout ? E specifica el timeout al ig ual que con la opción - T .

retry ? E specifica el tiempo que debe pasar desde que el cliente determina
que no puede contactar con el serv idor dhcp para v olv er a intentarlo de
nuev o.
leas e ? E specifica la interfaz que sobre la que se aplicará la config uración
de red obtenida del serv idor dhcp.
renew ? E specifica el tiempo que debe pasar antes de que el cliente solicite
renov ar los datos de red obtenidos.
reject ? R echaza las ofertas prov enientes de los serv idores dhcp declarados
aquí.

Para más opciones lo mejor es consultar m an dhclient.conf.

T odas las asig naciones recibidas se almacenan en /v ar/ lib/ dhcpd/ dhcpd.leas es

S i el serv idor dhcp no arranca después de haberlo config urado es posible que no
hay amos incluido alg una de las opciones requeridas por el mismo para lev antarse.
Para comprobar si todo está correcto lo mejor es acudir a /v ar/log /messag es y v er
el error que aparece.

Administración de sistemas de software libre 137

 L e c ció n 3

P roxy

Un serv idor proxy es un serv idor que actúa como intermediario a la hora de
g estionar las conexiones de sus clientes. Cuando un cliente quiere realizar una
conexión con un serv idor externo, la hace a trav és del proxy y es este el que realiza
la propia conexión con el serv idor externo. Al ser el serv idor proxy un intermediario
en las conexiones de los clientes, se pueden alterar dichas conexiones,
redirig iéndolas a otro lug ar, deneg ar el acceso a ciertos sitios…

Otra de las funciones útiles de un serv idor proxy es la de actuar como caché. Al
salir todos los usuarios a internet a trav és de el, la información que recopila se
almacena en la caché y por lo tanto las sucesiv as consultas de los usuarios se
aceleran por encontrarse la información en dicha caché.

También es importante destacar la seg uridad que brinda un serv idor proxy de cara
a accesos externos. Al actuar el serv idor prox y como intermediario, las conexiones
externas no sabrán qué cliente de la red interna ha realizado la conexión
exactamente aunque este aspecto también puede ser neg ativ o si el acceso al
recurso externo requiere que el usuario sea identificado.

C omo serv idor proxy v amos a trabajar con squid. S quid es un serv idor proxy de
software libre muy robusto y muy extendido que aporta todas las funciones
nombradas anteriormente.

¡ P onte a prueba!

V amos a instalar el serv idor proxy squid en nuestra máquina v irtual centos.
Después nos aseg uraremos de dejarlo habilitado por defecto.

Procedemos a instalar squid en nuestra máquina centos:

y um ins tall s quid

Una v ez instalado el serv icio, procedemos a dejarlo habilitado por defecto para
sucesiv os inicios del sistema:

chkconfig s quid on

y lo comprobamos:

chkconfig - - lis t | g rep s quid

Administración de sistemas de software libre 138

E l fichero principal de config uración de squid es /etc/squid/squid.conf en el cual se
pueden config urar entre otros los sig uientes parámetros:

http_ port ? Determina el puerto en el que escuchará peticiones squid. Por

defecto utiliza el puerto 3128.
v is ible_ hos tnam e ? Nombre del serv idor que aparecerá a la hora de
realizar una petición. S i el serv idor donde se ejecuta squid no tiene un FQDN
especificado, es decir, un nombre de equipo seg uido del dominio, será
necesario establecer esta opción para que squid funcione.
cache_ m em ? Cantidad de memoria que se asig nará al almacenaje de los
datos de la caché.
acl nom bre de la a cl tipo de acl a quién s e aplica ? E stablecemos una
acl que se aplicará a todo lo que definamos después de tipo de acl. E xisten
div ersos tipos de acl:
- s rc dirección ip/ m ás cara de red ? E stablece las direcciones ip de
orig en a las que se aplicará la acl. También se puede establecer un
fichero del cual cog erá las ips de los usuarios.
- ds t dirección ip/ m ás cara de red ? E stablece las direcciones ip de
destino a las que se aplicará la acl. T ambién se puede establecer un
fichero del cual cog erá las ips de los usuarios.
- s rcdom ain nom bre dom inio ? E stablece el nombre de dominio de
orig en al que se aplicará la acl.
- ds tdom ain nom bre dom inio ? E stablece el nombre de dominio de
destino para el que se aplicará la acl.
- port puertos ? E stablece los puertos de destino a los cuales se
aplicará la acl.
- tim e día de la s em a na hora s ? E stablece un horario en el cual se
aplicará la acl que definamos. Los días se establecen de la sig uiente
forma:
Lunes: M
Martes: T
Miércoles: W
J uev es: H
V iernes: F
S ábado: A
Doming o: S

Las horas se establecen en el formato 00: 00, así para marcar las
nuev e escribiríamos 09: 00. Para marcar un interv alo, por ejemplo de
09: 00 a 13: 00 sería:
09: 00- 13: 00.
- url_ reg ex " fichero" ? S e especifica un fichero que contiene
palabras clav e que se comprobarán en las urls que se soliciten
impidiendo el acceso a las mismas.

Administración de sistemas de software libre 139

 http_ acces s allow / deny acl ? E stablece a quién se le permite el acceso y
a quién no. Por defecto se denieg a todo el tráfico a trav és del proxy .
E s importante mencionar que el orden en el que aparezca esta sentencia
importa. S i en la parte de arriba del documento estamos deneg ando todo el
tráfico a trav és del proxy y en la parte de abajo especificamos que se
permite el acceso desde una cierta ip, esa ip no podrá acceder.
acces s _ log "" ? E stablece el directorio en el cual se reg istrarán todos los
accesos al serv idor proxy .

Para más opciones lo mejor es consultar el propio fichero de config uración de

squid: / etc/ s quid/ s quid.conf.

Para que los usuarios salg an a trav és del proxy es necesario config urarlo en el
nav eg ador. E n mozilla firefox podemos hacer esto accediendo a herramientas/
opciones ( También puede aparecer en editar/preferencias) . A continuación pinchar
en la pesta a red ( en la sección av anzado) , después en config uración… y por último
marcando "config uración manual de proxy " podremos establecer la ip del serv idor
proxy que queramos usar.

Administración de sistemas de software libre 140

 Ca p ítulo 1 0

S erv icios d e correo electrónico

Hoy en día la may oría del mundo depende de un sistema de correo que permita
poder comunicarse con el resto de la g ente y a sea por motiv os laborales como por
motiv os personales. Al usuario, el proceso de env iar un correo electrónico se le
presenta de manera transparente y sencilla pero lo cierto es que para llev ar a cabo
ese proceso interv ienen un g ran número de mecanismos que v eremos en este
capítulo.

Al finalizar el estudio de estas lecciones serás capaz de:

E ntender cómo funciona el sistema de correo.

E ntender los distintos protocolos que interv ienen en la transmisión de

correo.

E ntender cómo funciona postfix y config urarlo.

C onfig urar serv icios adicionales como Dov ecot o Thunderbird para completar
a postfix.

Administración de sistemas de software libre 141

 L e c ció n 1

E l s is tem a d e correo

E l serv icio de correo electrónico permite a los usuarios env iarse

mensajes de una manera rápida y eficaz mejorando por lo tanto
lo comunicación entre ellos.

C uando env iamos un correo electrónico, interv ienen una serie

de serv icios que se detallan a continuación:

MU A ( Ma il U s er A g ent) : Un MUA es un cliente de

correo electrónico utilizado por el usuario para escribir correos electrónicos y
leerlos. E stos clientes, normalmente llev an incluidas muchas opciones no
directamente relacionadas con el env ío y recepción de correo como puedan
ser por ejemplo el calendario y la ag enda. Alg unos de los MUAs más
conocidos son Microsoft Outlook en sus div ersas v ersiones o Mozilla
T hunderbird y mutt que son software libre.
Una v ez escrito mensaje, este se env ía a un serv idor ( MT A) que se
encarg ará de el.
Normalmente los MUAs incluy en clientes IMAP o POP3 para poder recog er el
correo del serv idor correspondiente.
MT A ( Mail T rans fer A g ent) : Un MT A se encarg a de recibir el correo
prov eniente de los usuarios y determinar si ese correo es para el y por lo
tanto debe entreg arlo a los usuarios locales o si debe env iarlo a otro MT A
para que este lo entreg ue a sus usuarios.
Así pues, el MTA recibirá los correos de los usuarios escuchando
normalmente en el puerto 25/tcp y determinará si ese usuario puede env iar
a trav és de el. S i no puede env iar a trav és de el, se env iará una notificación
de error al usuario que env ió el correo y este no se entreg ará. S i por el
contrario el usuario sí puede env iar a usando ese MT A, se encarg ará de
entreg ar el correo a quien corresponda.
C omo MTAs más conocidos estarían "sendmail" y "postfix"
MD A ( Mail D eliv ery A g ent) : C uando un correo lleg a al MT A del
destinatario, se le pasa al MDA el cual se encarg a de g uardar el correo en la
cuenta del usuario dentro del serv idor. E ste mensaje se g uarda en el
almacén de correos del serv idor esperando a que el usuario final se conecte
por medio de su MUA y se lo descarg ue.
MA A ( Mail A cces s A g ent) : E l MAA es un serv idor POP3/IMAP utilizado por
el MUA del usuario para acceder al lug ar de almacenaje de los mensajes.
Alg unos MAA muy conocidos son Dov ecot y C y rus IMAP.

Administración de sistemas de software libre 142

E n el diag rama anterior se describe el proceso que se produce a la hora de env iar
un correo.

1. E l emisor redacta un correo utilizando un cliente MUA y lo env ía a su

serv idor MTA utilizando el protocolo S MTP y conectándose al puerto 25/tcp.
2. E l serv idor MT A preg unta a un serv idor DNS por el reg istro MX del dominio
asociado con el destinatario del correo ( lo que v a después de la @ ) . E n el
caso de que aparezcan múltiples reg istros MX , el correo se entreg a al que
teng a más prioridad de ellos o, si todos tienen la misma prioridad, al
primero que se resuelv a por DNS .
S i no existiera ning ún reg istro MX para el dominio, se buscaría el reg istro de
tipo A asociado con el dominio para su entreg a.
3. E l MT A del emisor env ía el correo al MT A del destinatario utilizando el
protocolo S MT P puerto 25/tcp y pueden ocurrir dos cosas:
S i el MTA remoto acepta el correo, ahora será él el responsable de
entreg ar dicho correo al destinatario.
S i el MT A remoto rechaza el correo, el MT A orig inal deberá mantenerlo
en la cola de mensajes e intentar reenv iarlo por si se trata de un error
puntual del MT A remoto o dev olv érselo al emisor indicándole que se
trata de un fallo de entreg a permanente y , por lo tanto, el correo no
puede ser entreg ado.
4. S i el MTA remoto acepta el mensaje se lo pasa al MDA para que lo entreg ue
localmente. E l MDA se encarg a de depositar el mensaje en el almacén de
correos hasta que este sea entreg ado.

Administración de sistemas de software libre 143

 5. E l destinatario final del correo utiliza su MUA para acceder a su correo
almacenado en el serv idor.
6. E l MAA recog e el mensaje del almacén de correos utilizando el protocolo
POP3 o IMAP y se lo pasa al MUA del usuario para que este pueda leerlo.

A la hora de env iar correos se hace uso de una serie de protocolos los cuales se
describen a continuación:

S MT P ( S im ple Mail T rans fer P rotocol) : E l protocolo S MTP permite la

transferencia de correos entre un emisor y un receptor ( el serv idor)
utilizando una conexión punto a punto.

La comunicación entre el emisor y el serv idor de correo al cual nos estemos

conectando se realiza mediante una serie de comandos. A cada comando
especificado por el usuario le sig ue una respuesta del serv idor. Por defecto
utiliza el puerto 25.

S i nos conectamos al puerto 25 de un serv idor de correo mediante el

comando "telnet" lo primero que aparecerá será el banner de la máquina en
cuestión. Después, deberemos "saludar" al serv idor mediante el comando
"ehlo" separado de un texto que se utiliza para especificar el nombre del
dominio de nuestro equipo aunque también se puede poner cualquier texto.

Después especificaremos el comando "m ail from : " seg uido de la dirección
de correo desde la que queramos env iar el mensaje. E l serv idor responderá
con un OK si se ha hecho de manera correcta.

A continuación se escribe el comando "rcpt to: " seg uido de la dirección de

correo a la que env iaremos el mensaje y el serv idor responderá nuev amente
OK si todo ha ido bien.

Después escribimos "data" y pulsamos enter. Ahora podremos escribir el

cuerpo del mensaje y , una v ez que hay amos finalizado de escribirlo
pondremos un punto para indicar que y a hemos acabado. Una v ez hecho
esto, el serv idor debería encolar el mensaje para env iarlo.

Después de especificar cada comando debemos presionar enter para

confirmar y pasar al sig uiente.

Una v ez hay amos terminado podemos usar el comando "quit" para

desconectarnos del serv idor.

P O P 3 ( P os t O ffice P rotocol) : E l protocolo POP3 se utiliza para descarg ar

los correos electrónicos almacenados en un serv idor de correo. Por defecto
utiliza el puerto 110. Mediante POP3 un usuario se conecta al serv idor donde
tiene almacenados los mensajes, los descarg a en su cliente de correo o MUA
y se eliminan del serv idor.

Administración de sistemas de software libre 144

 Normalmente los MUAs tienen una opción cuando se utiliza POP3 para dejar
una copia de los mensajes descarg ados en el serv idor para que puedan ser
descarg ados desde otras ubicaciones. E xiste una v ersión más seg ura de
pop3 llamada pop3s que utiliza el puerto 995.

C uando se establece una conexión con el serv idor POP3 los comandos
utilizados son distintos a los usados en una conexión S MT P. A continuación
se muestran alg unos de ellos:
us er ( nom bre de us uario) ? E specifica el usuario con el que nos
conectamos.
pas s ( contras eña) ? E specifica la contrase a asociada al usuario
con el que pretendemos conectarnos.
lis t ? Muestra los mensajes del usuario en cuestión con su long itud.
retr ( núm ero de m ens aje) ? Muestra el mensaje que nosotros le
especifiquemos.
dele ( núm ero de m ens aj e) ? Borra el mensaje especificado.
quit ? S irv e para desconectarse del serv idor pop3.

I MA P ( I nternet Mes s ag e A cces s P rotocol) : E l protocolo IMAP permite el

acceso a los mensajes de correo almacenados en un serv idor remoto sin
necesidad de descarg arlos como sucede con pop3. Por defecto utiliza el
puerto 143. Así pues, a diferencia de POP3, el correo permanece en el
serv idor hasta que el usuario decide eliminarlo. Imap también permite crear
carpetas en el propio serv idor y permite consultar el correo desde diferentes
equipos.

Para que muchos equipos puedan acceder a un mismo buzón de correo,

imap incorpora una serie de se ales que se almacenan en el serv idor y que
sirv en para conocer el estado de los mensajes en todo momento. Así, si un
correo ha sido leído por un usuario, cualquier otro usuario que utilice la
misma cuenta sabrá que esto es así y en el MUA que utilice le marcará el
correo como leído.

E xiste una v ersión más seg ura del protocolo imap llamada imaps que utiliza
el puerto 993.

Administración de sistemas de software libre 145

 L e c ció n 2

E l s erv id o r p o s tfix

Postfix es un MTA escrito por W ietse V enema sencillo de config urar y administrar,
seg uro y que no sobrecarg a el equipo al hacer uso de los módulos indispensables
en cada momento seg ún los v ay a necesitando.

Así pues, como principales características de postfix estarían:

S eg urida d: La premisa que ha marcado el desarrollo de postfix desde sus

comienzos ha sido la seg uridad. Postfix prov ee mecanismos efectiv os que
ev itan los ataques al serv idor, el uso del serv icio por parte de usuarios no
autorizados y también mecanismo que combaten el env ío de spam o correo
no deseado.
A lto rendim iento: E l funcionamiento de todo el serv icio se produce de una
manera muy rápida. Postfix es capaz de g estionar los correos encolados de
manera muy efectiv a.
Modula rida d: E l funcionamiento del serv icio postfix depende a su v ez de
div ersos procesos que se comunican entre sí lo cual aporta una serie de
v entajas como por ejemplo que si falla alg uno de esos procesos será más
sencillo identificar cual es o que podemos desactiv ar alg unos si no los
necesitamos ahorrando así recursos en el equipo.
F acilidad de config uración: A diferencia de sendmail, los parámetros
config urables en postfix son fácilmente entendibles debido a que usan un
nombre que concuerda con la función que realizan.

Así pues, como v entajas de postfix sobre sendmail estarían la sencillez de manejo y
config uración, postfix es más seg uro que sendmail y funciona de forma más rápida.

W ietse V enema

Administración de sistemas de software libre 146

 ¡ P onte a prueba!

V amos a instalar postfix en nuestra máquina v irtual centos y v amos a hacer

que el serv icio arranque por defecto.

Procedemos a instalar postfix:

y um ins tall pos tfix

Una v ez que está instalado, hacemos que se inicie por defecto con el
arranque del sistema:

chkconfig pos tfix on

Lo comprobamos:

chkconfig - - lis t | g rep pos tfix

Lo primero que se debe hacer a la hora de config urar el serv idor de correo es
deshabilitar sendmail puesto que v iene integ rado en el sistema por defecto e
interferiría en el funcionamiento de postfix o cualquier otro MT A que instalásemos
en el sistema.

Para cambiar de un MT A a otro de manera efectiv a existe una herramienta llamada

alternativ es . C on alternativ es - - s et m ta / us r/ s bin/ s endm ail.pos tfix
haremos que postfix sea nuestro mta por defecto. Podemos v er el mta por defecto
que está config urado en el equipo mediante alternativ es - - dis play m ta

Antes de ejecutar el comando alternativ es será necesario detener el serv icio

sendmail completamente mediante /etc/init.d/sendmail stop

Los dos ficheros principales de config uración de postfix son

/ etc/ pos tfix / m as ter.cf y / etc/ pos tfix / m ain.cf.

E n m a s ter.cf se config uran los procesos de postfix que deben ejecutarse así como
el número de cada uno de esos procesos que pueden estar ejecutándose en un
mismo momento. De todo esto se encarg a el demonio master que es el encarg ado
de ejecutar el resto de procesos definidos en master.cf. Normalmente este fichero
sólo suele editarse si queremos integ rar un antiv irus o usar un sistema alternativ o
de entreg a de correo por ejemplo.

Administración de sistemas de software libre 147

Alg unos de los procesos que aparecen en este fichero serían:

s m tpd: S e encarg a de estar escuchando en el puerto 25/tcp esperando que

entre alg ún correo y cuando eso sucede, le pasa el correo al proceso
cleanup que lo "limpia" y lo deja en la cola de entrada.
cleanup: S e encarg a de "limpiar" los mensajes antes de dejarlos en la cola
de entrada. A ade las partes del mensaje que faltan, los corrig e para que
estén en un formato adecuado…
qm g r: Procesa los mensajes que se encuentran en la cola de entrada, la
activ a o la diferida y los procesa para env iarlos, entreg arlos localmente o
rebotarlos si se existe alg ún fallo.
local: Guarda los mensajes que tiene que entreg ar localmente en el
directorio apropiado de cada usuario.

Por su parte, el fichero m ain.cf se encarg a de definir cómo se v a a comportar

postfix. S e trata de un fichero con muchos comentarios y con nombres de
parámetros muy claros por lo que su config uración resulta sencilla. Al ig ual que con
otros serv icios, el orden en el que aparecen los parámetros es importante por lo
que habrá que tener cuidado con eso.

Lo que v a detrás de "# " se trata de un comentario.

A continuación se comentan alg unos de los parámetros:

m y hos tnam e= ? C on este parámetro se especifica el nombre que se

mostrará en internet de la máquina en la que se está config urando postfix.
Por defecto, si no se config ura esta opción, cog erá el nombre de host del
equipo mediante g ethostname( ) .
m y dom a in= ? C on este parámetro se especifica el nombre de dominio de
la máquina en donde se está config urando postfix. S i no se especifica
ning uno cog erá el v alor de $my hostname ( el símbolo $ especifica que se v a
a cog er el v alor del parámetro que le sig ue) quitándole el primer
componente antes del punto, es decir, si my hostname= centos.cursosl.com,
my domain tomaría como v alor cursosl.com.
m y orig in= ? E ste parámetro se utiliza para especificar el nombre de
dominio que aparece a la hora de env iar correo desde la máquina donde se
está config urando postfix. E l v alor de my orig in también se utiliza para
a adirlo a cualquier correo que se env íe a una dirección a la que no se ha
a adido un nombre de dominio detrás. Por defecto toma el v alor
$my hostname.
m y des tination= ? Con este parámetro se especifican todos los dominios
para los cuales se acepta la entreg a de correo en esta máquina. Por defecto
toma los v alores $my hostname, localhost.$my domain y localhost.
m y netw orks = ? Aquí se especifican las ips de las máquinas que pueden
env iar correo a trav és del serv idor postfix. S i se especifica el parámetro
my networks_ sty le se ig nora my networks y v icev ersa.

Administración de sistemas de software libre 148

 m y netw orks _ s ty le= ? E ste parámetro admite tres posibles parámetros:
class, subnet y host. S i especificamos clas s , postfix permitirá env iar a todas
las ips de la misma clase que la propia en la que está config urada el
serv idor( A/B/C ) . S i especificamos s ubnet, postfix permitirá env iar a todos
los clientes que se encuentren en la misma subred que la máquina en la que
está instalado postfix.
Por último, si especificamos hos t, sólo se permitirá env iar a la propia
máquina en la que está instalado pos tfix
E s importante permitir env iar únicamente a nuestros usuarios debido a que
si no se hace de esa forma se pueden producir problemas de seg uridad y
env ío de correo no deseado.
inet_ interfaces = ? E specifica las direcciones ip de las interfaces en las
cuales debería escuchar el serv icio smtp de postfix. S i queremos que
escuche en todas las interfaces le asig naríamos el v alor all.
queue_ directory = ? Aquí se especifica el directorio donde se encontrará la
cola de postfix.
alias _ m aps = ? S e define el fichero donde se encontrarán los alias de
correo. Un alias es una dirección de correo que apunta a otra. S i tenemos un
alias root: fernando , todos los correos que lleg arían a root pasarán a lleg arle
a fernando.
Por defecto postfix tiene asig nado el v alor hash: /etc/aliases lo cual quiere
decir que cog erá la lista de alias que se encuentran en el fichero
/ etc/ alias es . C ada v ez que ag reg uemos un nuev o alias, deberemos utilizar
el comando new alias es para que postfix indexe el contenido del fichero y
g enere un fichero .db que sea más fácilmente accesible por él.
s m tpd_ banner= ? Define el mensaje que aparecerá a los clientes que se
conecten v ía smtp con el serv idor postfix. E s necesario que al principio de
dicho mensaje aparezca $my hostname por especificaciones del propio
protocolo. E l resto del mensaje es opcional y podremos poner lo que
queramos.
m ail_ s pool_ directory = ? Indica la ruta en la cual se dejarán los correos
env iados a los distintos usuarios. E l v alor que toma depende del sistema en
el que esté instalado postfix y en centos es /v ar/spool/mail
hom e_ m ailbox = ? E specifica el sistema de buzones que se utilizará en el
serv idor. Puede tomar los v alores "Mailbox" o "Maildir/" La diferencia entre
ambos sistemas de correo es que mailbox g uarda los mensajes en un único
fichero y maildir g uarda los mensajes en una estructura de ficheros y
directorios con lo que este último resulta más ordenado.

E stos son los parámetros más utilizados e indispensables para config urar un
serv idor de correo, para conocer el resto de parámetros lo mejor es acudir al propio
fichero de config uración main.cf.

C on el fin de no tener que localizar cada parámetro en el fichero y ahorrando por lo

tanto tiempo, podemos usar el comando pos tconf. postconf es un comando que se
utiliza para editar las opciones del fichero main.cf sin necesidad de acceder a él.

Administración de sistemas de software libre 149

Alg unos de los parámetros que se le pueden pasar son los sig uientes:

- d ? Muestra los parámetros por defecto en lug ar de los parámetros que

están config urados en main.cf.
- e ' '? E dita el fichero de config uración de postfix main.cf. Aquí podemos
especificar los parámetros que queremos asig nar al fichero ev itando así
tener que acceder al mismo y buscarlo.
- n ? Muestra el v alor de los parámetros que no han sido dejados con su
v alor por defecto.

S i escribimos símplemente pos tconf se mostrarán todas las opciones que están
config uradas actualmente en el serv idor. Para más parámetros lo mejor es
consultar m an pos tconf

Todos los mensajes de correo que se env ían desde el serv idor o se reciben en el, se
reflejan en el log / v ar/ log / m aillog . Así pues, es ahí donde debemos acudir para
seg uir la traza de los correos o para rev isar los posibles errores que hubiera si
comprobamos que un determinado correo no está lleg ando a su destino.

Podemos comprobar los mensajes encolados mediante el comando m ailq. Al hacer

un mailq se nos presentarán los mensajes que están esperando para ser env iados o
los mensajes con los que está habiendo alg ún tipo de problema a la hora de
entreg arlos y por lo tanto no han salido del serv idor todav ía.

S e nos presentará el id del mensaje, la fecha del mismo, el emisor y una brev e
descripción del correo o del problema que está habiendo.

E stos mensajes pueden ser administrados mediante la herramienta pos ts uper al

cual se le pueden pasar entre otros, los sig uientes parámetros:

- d id del m ens aj e/ A L L ? E limina el mensaje seleccionado de la cola de

correo. S i especificamos ALL se eliminarán todos los mensajes que estén en
la cola.
- p ? Muestra la cola de correo.
- h id del m ens aj e? Pone en mensaje en espera indefinidamente haciendo
que no se intente env iar hasta que se cancele.
- H id del m ens aj e ? V uelv e a poner en la cola de env ío un mensaje que se
había puesto prev iamente en espera.

Para intentar env iar los correos que están en la cola podemos usar el comando
pos tqueue - f

Administración de sistemas de software libre 150

 L e c ció n 3

Otros com ponentes del s is tem a de correo

Además de tener instalado el mta postfix, hacen falta el resto de componentes del
sistema de correo para ofrecer un serv icio completo.

D ov ecot

Dov ecot es un serv idor IMAP y POP3 que

puede desempe ar las funciones de
MDA y MAA. S u dise o se basó en todo
momento en la seg uridad por lo que
resulta muy robusto. Fue desarrollado por Timo S irainen
en el a o 2002. Otra de sus características es que es muy
sencillo de implementar y de config urar.

S oporta los formatos de buzones más utilizados: mbox y

maildir.

T imo S irainen
El fichero principal de configuración es / etc/ dovecot.conf.
E ste fichero al ig ual que el main.cf de postfix está muy comentado y por lo tanto
resulta sencillo de config urar. Alg unos de los parámetros que se pueden config urar
son los sig uientes:

protocols = ? S e especifican los protocolos que se serv irán en el serv idor.

Admite pop3 e imap así como las v ersiones seg uras de estos: pop3s e
imaps.
s s l_ dis able= y es / no ? E specifica si se debe o no deshabilitar el protocolo
S S L/T LS .
s s l_ cert_ file= ? Indica el certificado que se utilizará para env iar la
información cifrada.
s s l_ key _ file= ? Indica la ubicación de la clav e priv ada que se utilizará
para cifrar las comunicaciones.
m ail_ location= ? E specifica la ruta en la que se encontrarán los correos y
el sistema de buzones que se v a a utilizar.

Alg unos ejemplos serían:

mail_ location = maildir: ~ /Maildir

mail_ location = mbox: ~ /mail: INBOX = /v ar/mail/% u

mail_ location = mbox: /var/mail/% d/% 1n/% n: INDEX = /var/indexes/% d/% 1n/% n

Administración de sistemas de software libre 151

siendo:

% u= usuario

% n= La parte del nombre del usuario en una cuenta del tipo usuario@ dominio.

% d= La parte del dominio en una cuenta del tipo usuario@ dominio.

% h= Directorio home.

Podemos g enerar una clav e priv ada y un certificado que se utilizarán para cifrar las
conexiones que realizar dov ecot mediante la herramienta m a ke. Con el sig uiente
comando g eneraríamos las dos cosas en el directorio /v ar/certificates:

m ake - C / v ar/ certificates / dov ecot.pem

Al ig ual que pasaba a la hora de g enerar un csr en el tema de apache, se nos

pedirán una serie de datos como son la población y el nombre entre otros.

E l archiv o dov ecot.pem sería usado como certificado y como clav e priv ada por
dov ecot para cifrar las comunicaciones.

Moz illa T hunderb ird

Mozilla T hunderbird es un cliente de correo electrónico ( MUA)

muy extendido entre los usuarios de correo y es software libre.

E n el panel de arriba de thunderbird tenemos todo lo

necesario para desarrollar las funciones más habituales como
son redactar un correo o recibir el mismo:

E n Herramientas ? Opciones podremos config urar las opciones del g estor de correo
usando la misma interfaz existente en mozilla firefox. E n Herramientas ?
C onfig uración de las cuentas, podremos cambiar los parámetros de las cuentas que
teng amos config uradas.

Las secciones más importantes de este menú son

Config uración del s erv idor donde modificaremos los
parámetros del serv idor de correo entrante y S erv idor
de salida ( S MTP) donde modificaremos los parámetros
del serv idor de correo saliente.

Administración de sistemas de software libre 152

 Ca p ítulo 1 1

F irew a lling

E n cualquier org anización, uno de los temas más importantes a tener en cuenta es
la seg uridad lig ada a los sistemas informáticos. Una mala securización de los datos
o de los serv icios puede causar que se produzcan ataques contra nuestros sistemas
y por lo tanto que estos se v ean expuestos. E n este capítulo aprenderemos a
implementar un firewall para proteg er nuestro sistema ante posibles ataques.

Al finalizar el estudio de estas lecciones serás capaz de:

E ntender la necesidad de securizar los sistemas.

C onocer v arios mecanismos de seg uridad.

C onocer lo que es un firewall y qué función desempe a.

C onfig urar un firewall utilizando iptables.

Administración de sistemas de software libre 153

 L e c ció n 1

Neces id a d d e la s eg urid a d

A diferencia de hace unos a os, hoy en día todo se muev e a trav és

de internet. Lo que antes se hacía de manera presencial como
comprar ciertos objetos o por ejemplo, reserv ar habitación en un
hotel se hace hoy por hoy a trav és de internet. E ste hecho tiene
sus v entajas y sus inconv enientes.

C omo v entajas estaría la rapidez y la facilidad para desempe ar estas

tareas a trav és de la red y como desv entaja fundamental estaría el hecho de que
nuestros datos se pueden v er comprometidos si no se toman una serie de
precauciones.

E s ahí donde entra en jueg o la seg uridad. Para que los usuarios se sientan seg uros
a la hora de realizar esas tareas debemos aseg urar que sus datos no v an a ser
accedidos por terceros o de lo contrario nadie querría realizar esas tareas a trav és
de la red y por lo tanto las empresas perderían mucho dinero.

Por eso está tan en aug e la seg uridad dado que si podemos g arantizar a los clientes
que toda acción que realicen en nuestros serv idores no se v a a v er comprometida,
se sentirán cómodos solicitando estos serv icios y eso se traduce en más dinero para
cualquier empresa.

Linux se ha mostrado como un sistema muy estable y seg uro a lo

larg o de los a os mostrando muchas menos v ulnerabilidades que los
sistemas W indows, sin embarg o, al ig ual que cualquier sistema
operativ o tiene fallos que pueden ser explotados por terceros para
comprometer la seg uridad del mismo.

Cada día que pasa se descubren nuev as v ulnerabilidades en los

sistemas operativ os y en las conexiones de red ante las cuales la
única medida eficaz es la prev ención. E s importante comentar que
no existe ning ún sistema conectado a la red que sea seg uro al 100% y a que
internet es inseg uro por definición, así pues, el único sistema seg uro sería uno que
no estuv iera conectado con el resto del mundo.

No todos los usuarios que utilizan un sistema operativ o como Linux necesitan
g randes medidas de seg uridad. Un usuario doméstico no necesita implementar
g randes mecanismos para g arantizar su información pero si hablamos de bancos o
empresas multinacionales los cuales alberg an datos de miles de usuarios, entonces
la seg uridad se conv ierte en una prioridad y cualquier nuev a medida que se tome
es perfectamente justificable.

Así pues, podemos definir la s eg uridad como aquellos mecanismos o medidas que
se toman para proteg er un sistema frente a ataques externos.

Administración de sistemas de software libre 154

Una de las formas más eficaces de g arantizar la seg uridad es estar informado de
las principales v ulnerabilidades que aparecen cada día en la red, aunque si eres el
primero al que le toca sufrir esa v ulnerabilidad ni siquiera eso sirv e.

Implementar de forma efectiv a un sistema de seg uridad no es tarea sencilla debido

a que a may or seg uridad, más bloqueos y restricciones se ponen a la utilización de
los serv icios y esto puede acarrear alg ún problema a más de un usuario.

Una característica de Linux que hace que sea tan seg uro es que su códig o fuente, al
ig ual que el de muchas de las aplicaciones que funcionan sobre él, es abierto. E sto
aseg ura una comunidad de usuarios dispuestos a solucionar las v ulnerabilidades
que hay an surg ido, además, con tantos usuarios modificando el códig o fuente, se
trata de un sistema en continuo av ance y por lo tanto cada v ez más seg uro.

Administración de sistemas de software libre 155

 L e c ció n 2

Meca nis m os d e s eg urid a d en L inux

T CP W rappers

Muchos serv icios config urables en Linux incorporan sus propios mecanismos de
seg uridad que en la may oría de ocasiones son mucho más complejos que los que
puede aportar tcp wrappers, sin embarg o, este mecanismo también resulta
altamente seg uro y es una manera práctica de tener todas las políticas de
seg uridad sobre el resto de serv icios definidas en un único lug ar facilitando así su
administración.

T cp wrappers, también conocido como la librería libwrap.so es un software

desarrollado por W ietse V enema ( desarrollador del software postfix) prov ee un
mecanismo basado en la implementación de acls que permiten el filtrado del tráfico
de red que se produce entre los clientes y los serv icios que se están ejecutando en
un determinado sistema.

C uando un cliente se conecta a alg ún serv icio que aparece en tcp_ wrappers se
examinan los ficheros /etc/hosts.allow y /etc/hosts.deny en busca de reg las que
permitan o denieg uen el acceso a ese cliente. La config uración se realiza
independientemente para cada serv icio y suele estar determinada por las ips de los
clientes que intentan acceder.

S E L inux

Ante la creciente cantidad de amenazas para los sistemas que estaban surg iendo,
el g obierno de los E stados Unidos de América asig nó a la Ag encia Nacional de
S eg uridad el trabajo de crear una serie de reg las y políticas que el resto de
org anizaciones utilizarían para preserv ar la información confidencial.

E sta ag encia se basó en otros ataques y v ulnerabilidades que había habido antes y
determinó que una de las causas principales que prov ocaban fallos en la seg uridad
eran los propios usuarios haciendo uso indebido de las herramientas que se les
proporcionaban. Muchos usuarios tenían problemas con alg ún mecanismo de
seg uridad que no le permitía realizar alg una función y lo solucionaban
deshabilitando ese mecanismo.

Para solucionar este problema, la Ag encia Nacional de S eg uridad determinó que lo

óptimo sería implementar un mecanismo conocido como MAC ( Mandatory Access
C ontrol) . E l MAC lo componen una serie de políticas que determinan qué acciones
puede realizar un proceso y cuáles no. A cada proceso o serv icio se le permiten una
serie de cosas y todo lo que no esté definido implícitamente se denieg a por defecto.

Administración de sistemas de software libre 156

E stas políticas se implementan haciendo uso del núcleo del
sistema por lo que un sistema de códig o abierto se
antojaba necesario para poder despleg arlo
completamente. Así fue como se fijaron en Linux y
sacaron una serie de parches para implementar MAC
en el sistema, parches que más tarde se conocerían
como S E Linux ( S ecurity E nhanced Linux)

S elinux aplica un "contexto" a cada archiv o y proceso del

sistema. E se contexto define los límites para ese archiv o o
proceso de tal forma que se denieg a cualquier v iolación de
dichos límites. E sto hace de S elinux un mecanismo de seg uridad
muy robusto y a que se limita lo que puede cada archiv o puede hacer en el sistema.

Así pues, S elinux resulta muy seg uro pero también tiene una serie de
inconv enientes. Uno de esos inconv enientes es que es bastante complejo de
config urar, de hecho existen especialistas cuy o único trabajo consiste en asesorar a
otras empresas sobre cómo deben config urar S elinux.

S eg undo, si no se config ura correctamente puede lleg ar a conv ertirse en un

auténtico quebradero de cabeza para cualquier administrador de sistemas debido a
lo estricto de sus políticas. De hecho es muy probable que si no se ha config urado
correctamente S elinux para que se implemente con un serv icio, este no funcione.

Para intentar facilitar esta labor, S elinux incorpora tres modos que podemos activ ar
o desactiv ar a nuestro antojo: enforcing , permissiv e o disabled. E n modo enforcing ,
S elinux bloqueará todos los intentos por parte de los archiv os o procesos de salirse
de sus límites.

E n modo permissiv e, S elinux permitirá a los archiv os o procesos saltarse esos

límites pero informará al administrador de tal forma que sepa que los límites han
sido v iolados. Por último, disabled deshabilita por completo S elinux.

S elinux se implementa de tal forma en el núcleo del sistema que si queremos pasar
de permissiv e o enforcing a modo disabled sería necesario reiniciar el sistema.

F irew alls

Un firewall o cortafueg os es un tipo de software o de hardware que se ocupa de

analizar las conexiones que se intentan establecer con un sistema, limitando el
acceso al mismo. E l uso más frecuente de un firewall es el de ev itar que los
usuarios conectados a internet teng an accedan a redes priv adas conectadas a
internet.

Un firewall además de poner barreras a las conexiones tiene otra serie de funciones
como son cifrar y descifrar el tráfico o modificar la información de las conexiones
que recibe. Así pues, un firewall recibe una conexión y , en base a una serie de
reg las definidas por el administrador, la acepta, la modifica o la rechaza
directamente proporcionando una capa de seg uridad extra.

Administración de sistemas de software libre 157

C omo y a se ha comentado, un firewall puede ser un software específico que
implemente las reg las descritas o bien puede ser un hardware con su propio
sistema operativ o que filtra el tráfico T C P, UDP, ICMP… Así pues, un firewall filtra
las conexiones que se producen entre v arias redes, dos como mínimo por lo que es
necesario que teng a como mínimo dos tarjetas de red.

A continuación se muestra un esquema con la topolog ía básica que suele seg uir una
red que implementa un firewall:

E n el esquema anterior, se ha implementado un firewall para proteg er la red lan

local de los posibles ataques que se puedan producir desde internet. Todas las
estaciones de trabajo se concentran en el hub o switch y después estaría el firewall,
el cual debe colocarse entre la red local y el router. E l firewall debe conectarse al
router con un único cable para preserv ar la seg uridad.

Otro esquema muy común en cualquier estructura de red de cualquier org anización
sería el sig uiente:

Administración de sistemas de software libre 158

E n el esquema anterior se ha a adido una DMZ o zona desmilitarizada. Una dmz es
una red local ubicada entre la red interna de una org anización y la red externa. C on
una dmz lo que se quiere conseg uir es que se permitan las conexiones desde la red
externa ( internet) y la red interna a la dmz pero que los equipos de la dmz sólo se
puedan conectar a equipos de la red externa.

Normalmente en una dmz se colocan serv idores que se requieren para prov eer una
serie de serv icios como son el correo, las webs, etc y por lo tanto es necesario que
se acceda desde el exterior.

E s esta premisa de que se pueda acceder desde el exterior la que hace que sea
necesario separar la dmz de la red interna, así si un atacante quiere conectarse a la
red interna de una org anización, no podrá saltar desde la dmz a la misma, de ahí
que se considere un callejón sin salida.

Así pues, un firewall se encarg a de filtrar las conexiones para decidir si se permiten
o no. E xisten v arios protocolos a la hora de realizar una conexión que deben ser
contemplados por los firewalls:

P rotocolo T CP ( T ra ns m is s ion Control P rotocolo) : E l protocolo tcp es un

procotolo orientado a conex ión. Un protocolo orientado a conexión
requiere que se establezca una conexión entre cliente y serv idor antes de
que se produzca el env ío de datos.
E n el protocolo tcp, cuando dos equipos establecen una conexión, se
controla el estado de la transmisión en todo momento. Para controlar el
estado de la transmisión utiliza lo que se llama acus e de recibo.
Mediante el protocolo tcp, el emisor ( cliente) y el receptor ( serv idor)
establecen una comunicación en la cual, se env ían los datos en peque os
bloques ag rupados con un encabezado. C ada v ez que se env ía uno de esos
bloques o seg mentos, se v incula con un número de secuencia y cuando le
lleg a al receptor este le dev uelv e un seg mento con el número de secuencia
que le había env iado a adiéndole un 1 delante para indicar que se trata de
un ACK ( ack nowledg e) o acuse de recibo.
De esta forma, se g arantiza que los datos transferidos entre el emisor y el
receptor han lleg ado a este último de manera ínteg ra y ordenados
correctamente.
E l protocolo tcp es utilizado por muchas aplicaciones y serv icio en internet
como puedan ser: http, smtp, ssh o ftp.
P rotocolo U D P ( U s er D a tag ram P rotocol) : E l protocolo udp es un
protocolo de red no orientado a conex ión. E sto sig nifica que, a diferencia
de los protocolos orientados a conexión, para que se produzca un env ío de
datos del emisor al receptor no es necesario que se establezca una conexión
entre ellos prev iamente.
Así pues, mediante el protocolo udp, un equipo env ía a otro datag ramas
( paquetes de datos) y estos datag ramas contienen tanto los datos que se
quieren transmitir como información necesaria para poder contactar con el
equipo receptor.

Administración de sistemas de software libre 159

 A diferencia de tcp, no incorpora ning ún mecanismo que aseg ure que los
datos están lleg ando correctamente al receptor ni en el orden adecuado.
E l protocolo udp suele usarse para protocolos como dhcp, dns, etc en los
cuales el v olumen de datos solicitados es muy alto.
P rotocolo I CMP ( I nternet Mes s ag e P rotocol) : S e trata de un protocolo
que se usa para prov eer control y para la notificación de errores del
protocolo ip. E ste protocolo no es directamente utilizado por aplicaciones
para realizar conexiones. E s utilizado por las herramientas ping y traceroute
de tal forma que se env ían mensajes a un host remoto y se recibe
información sobre ese host está disponible o no.

O tros m odos de proporcionar s eg uridad

Además de los mecanismos expuestos anteriormente, existen una serie de pautas

que pueden resultar de ay udar a la hora de proteg er un sistema de los ataques
externos:

Correcta g es tión de us ua rios y perm is os : E n cualquier

sistema es necesario conocer en todo momento qué
usuarios tenemos creados y qué permisos le estamos
concediendo a cada uno. Una mala g estión de los
usuarios o de los permisos puede desembocar en
auténticos problemas de seg uridad.
Por encima de todo hay que tener mucho cuidado a la
hora de establecer los permisos del g rupo "otros".
Otorg ar permiso de escritura a dicho g rupo sig nifica
darle priv ileg ios de escritura a cualquier usuario del
sistema y por lo tanto sig nifica dejar un ag ujero g rande
de seg uridad.
Correcto us o de la cuenta root: E n un sistema linux, el usuario root tiene
permiso para modificar cualquier cosa. E sto tiene la v entaja de permitirnos
realizar cualquier proceso sin ning ún tipo de restricción pero esa misma
v entaja se puede conv ertir en desv entaja.
Al tener priv ileg ios para modificar cualquier aspecto del sistema, es posible
que con alg ún comando mal ejecutado o la modificación de alg ún fichero
crítico para el sistema operativ o dejemos inutilizada nuestra máquina.
Así pues, la cuenta de root debería ser utilizada con mucha responsabilidad
y con el may or de los cuidados y por supuesto no proporcionársela a
cualquier usuario.
Una buena práctica es intentar hacer las modificaciones en el sistema con
cualquier otro usuario que no sea root y si v emos que no nos funciona
utilizar la cuenta de root.

Administración de sistemas de software libre 160

 Com plej ida d de las contra s eñas : E n este curso hemos utilizado
contrase as como "12345" al tratarse de un entorno no expuesto y no ser
un sistema de producción. S in embarg o, si estuv iéramos trabajando con
serv idores reales que proporcionasen serv icio a los usuarios de internet y ,
por lo tanto, expuestos a sus ataques, deberíamos establecer una política de
contrase as para ev itar que un usuario no autorizado descifrase nuestras
contrase as.
Para g arantizar la seg uridad, a la hora de establecer contrase as conv iene
utilizar letras y números, may úsculas y minúsculas, alg ún carácter especial y
que teng a una long itud mínima de 8 caracteres.
También es más que aconsejable establecer una política que requiera el
cambio de las contrase as de una forma periódica.

Administración de sistemas de software libre 161

 L e c ció n 3

I ptables

Iptables se basa en Netfilter para funcionar.

Netfilter es un framework que aparece en el
núcleo de Linux que permite filtrar y modificar
los paquetes de red.

Así pues, iptables es una herramienta basada en netfilter que permite construir
reg las para filtrar, modificar, descartar… determinados paquetes de red. E n iptables
las reg las se ag rupan en cadenas. E n cada cadena aparecen una serie de reg las que
se utilizan para diferenciar cada paquete y al final de la cadena se decide qué se
hace con el paquete.

Así pues, un paquete lleg a a nuestra máquina y es ahí donde se aplican las reg las
de iptables. Al lleg ar dicho paquete, se comprueban una a una todas las reg las que
hay amos establecido en orden de arriba abajo. S i el paquete cumple alg una de las
reg las escritas ( hace m atch) se le aplican las operaciones escritas al final de la
propia reg la. S i el paquete no hace match con ning una de las reg las escritas,
entonces para ese paquete se tomará la acción definida en la política por defecto.

S i la política por defecto es descartar las conexiones, si el paquete no ha hecho

match en ning una de las reg las escritas, el paquete será rechazado. S i por el
contrario, la política por defecto es aceptar los paquetes, el paquete será aceptado
en el sistema.

E l sistema incorpora tres tablas:

T abla filter: La tabla filter, tal y como indica su nombre, se

encarg a del filtrado de los paquetes. E n esta tabla es
donde se permite o se bloquea un determinado paquete.
La tabla filter tiene las sig uientes cadenas:
Cadena I NP U T : Aquí es donde se establecen las
reg las para los paquetes que tiene como destino el
propio sistema en donde se están config urando.
Cadena F O R W A R D : Aquí se establecen las reg las para todos los
paquetes que utilizan nuestro sistema como enlace para lleg ar a su
destino final.
Cadena OU T P U T : Aquí se establecen las reg las que se aplicarán a
los paquetes orig inados en nuestro sistema con destino cualquiera.
T abla na t: E n esta tabla se especifican reg las que se encarg an de la
modificación de las direcciones ip o puertos de los paquetes. Así pues,
podemos especificar que un paquete que v eng a de un cierto orig en y v ay a a
un determinado destino, cambie su destino final. E n la tabla nat aparecen
las sig uientes cadenas por defecto:
Cadena P R E R OU T I NG: E sta cadena se aplica a los paquetes antes
de que accedan al sistema y se utilice la tabla filter.

Administración de sistemas de software libre 162

 Cadena P OS T R OU T I NG: Aquí se especifican reg las que afectan a los
paquetes que v an a abandonar el sistema.
Cadena OUT P UT : Funciona igual que la cadena output de la tabla filter.

T abla m a ng le: E sta tabla se utiliza para marcar los paquetes o modificar
ciertas características de los mismos que afectan a la calidad del serv icio
( QOS ) . T odos los paquetes pasan por esta tabla. E n esta tabla aparecen
todas las cadenas nombradas anteriormente:
Cadena I NP U T
Cadena F OR W A R D
Cadena OUT P U T
Cadena P R E R OU T I NG
Cadena P OS T R OU T I NG

Normalmente sólo se utilizarán las tablas filter y nat.

A continuación se presenta un esquema de cómo entran en funcionamiento las cadenas:

Así pues, la cadena prerouting se utiliza para determinar las reg las sobre paquetes
justo antes de que entren en el sistema. S i el paquete v a destinado al propio
sistema, se utilizan las cadenas input y output mientras que si el paquete utiliza el
sistema como paso hacia otras redes se filtra en la cadena forward.

Finalmente, se pueden establecer reg las para los paquetes justo antes de que
abandonen el sistema mediante la cadena postrouting .

Debe quedar claro que cuando un paquete lleg a al sistema:

S e aplican las reg las del firewall de arriba abajo en orden. Por eso es tan
importante aseg urarnos de que la reg la que insertemos se encuentra en la
posición adecuada.
Los paquetes se comprueban con todas las reg las hasta que encuentra una
con la que hace match.
S i el paquete no hace match con ning una reg la, se le aplicará la política por
defecto de la cadena.

Administración de sistemas de software libre 163

Cuando un paquete hace match con una reg la, en la propia reg la se especifica la
acción a tomar con dicho paquete. Alg unas de estas acciones son las sig uientes:

A CCE P T : C on esta acción se determina que el paquete debe ser aceptado.

E sta acción depende de la cadena en la que se encuentre, por ejemplo, si se
encuentra en la cadena input, el mensaje será aceptado en el sistema. S i el
encuentra en la cadena output, al mensaje se le permitirá abandonar el
sistema…
R E J E CT : S e rechaza el paquete en cuestión. C uando se especifica la acción
reject, además de rechazar el paquete, se le manda un mensaje al emisor
de dicho paquete para indicarle que su paquete ha sido rechazado. S e le
puede especificar detrás el parámetro - - reject- with para indicar el motiv o
exacto por el que se rechaza. Por defecto - - reject- w ith utiliza siempre el
motiv o icmp- port- unreachable pero también se pueden especificar los
sig uientes motiv os:
icm p- net- unreachable
icm p- hos t- unreachable
icm p- port- unreachable
icm p- proto- unrea cha ble
icm p- net- prohibited
icm p- hos t- prohibited
icm p- a dm in- prohibited
D R O P : E l firewall descarta el paquete en cuestión. A diferencia de reject,
drop no env ía ning ún mensaje al emisor del paquete. E l paquete
símplemente desaparece y al emisor le da un timeout en la conexión por lo
que no sabe si el sistema de destino existe o no.
Utilizar drop en lug ar de reject tiene dos g randes v entaj as : la primera es
que al no saber el emisor si el sistema destino existe, se cons ig ue g ana r
s eg uridad, la otra v entaja es que al no dev olv er un mensaje al emisor no
s e des perdicia a ncho de ba nda. S i config uramos un firewall que hag a
reject y un atacante intenta hacer conexiones no permitidas de manera
masiv a puede ralentizar considerablemente nuestro sistema.
L OG: S e determina que se debe v olcar en un fichero de log la información
sobre la conexión del paquete que cumple la reg la en cuestión
S NA T - - to ip: puerto : Mediante esta acción se determina que la dirección
y /o el puerto de orig en del paquete deben ser modificados por otros.
D NA T - - to ip: puerto : S e determina que la dirección y /o el puerto de
destino del paquete deben ser modificados por otros.

Observ amos un ejemplo de una reg la del firewall:

iptables - t filter - A I NP U T - s 1 9 2 .1 6 8 .1 .1 - j A CCE P T

E n el ejemplo anterior, se a ade a la tabla filter, a la cadena INPUT una reg la por la
cual, cualquier paquete con orig en la ip 192.168.1.1 será aceptado.

Administración de sistemas de software libre 164

A continuación se exponen alg unos parámetros del comando ipta bles :

- t tabla ? Indica la tabla a la cual se a adirá la reg la. Por defecto si no se

especifica este parámetro, se a ade a la tabla filter.
- A ca dena? S e a ade una nuev a reg la a la cadena que nosotros
especifiquemos.
- I cadena ( pos ición) ? S e inserta una nuev a reg la al principio de la
cadena en cuestión. También podemos especificarle la posición en la que
queremos insertar la reg la.
- D cadena pos ición ? S e borra la reg la situada en la posición que nosotros
le indiquemos.
- P cadena acción? E stablece la política por defecto a tomar por una
cadena cuando el paquete no hace match con ning una reg la.
- N nom bre cadena ? S e crea una nuev a cadena con el nombre que
nosotros especifiquemos.
- X nom bre ca dena ? E limina la cadena especificada.
- L ( cadena) ? S e listan todas las reg las pertenecientes a una determinada
cadena. S i no se especifica ning una cadena, se listan todas las reg las de
todas las cadenas de la tabla por defecto ( filter) .
- v ? S e muestra información detallada sobre las reg las de una tabla.
- n ? S e muestran todos los v alores de las reg las en numérico. Por defecto
se intentaría mostrar el nombre de host entre otras cosas.
- - line ? Muestra el número de línea de cada reg la. E sto nos permite saber
en qué posición debemos insertar una nuev a reg la o qué número de reg la
debemos eliminar.
- s ip/ m ás cara ? S e especifica el orig en de un determinado paquete para
que sea analizado.
- d ip/ m ás cara ? S e especifica el destino de un determinado paquete para
que sea analizado.
- i interfaz de red? S e especifica la interfaz de red por la que se debe
recibir un paquete para que se cumpla la reg la.
- o interfaz de red ? S e especifica la interfaz de salida por la que debe salir
un paquete para que cumpla la reg la.
- p protocolo ? E specifica el protocolo de red que debe usar el paquete
para cumplir la reg la.
- - s port puerto ? E specifica el puerto de orig en que debe usar el paquete
para que cumpla la reg la.
- - dport puerto ? E specifica el puerto de destino que debe usar el paquete
para que cumpla la reg la.

Administración de sistemas de software libre 165

S i a adimos "! " delante de cualquiera de los patrones, se nieg an los mismos. Por
ejemplo:

iptables - A I NP U T ! - s 1 9 2 .1 6 8 .1 .1 - j R E J E CT

E n la reg la anterior se rechazan todos los paquetes cuy o orig en no sea la ip

192.168.1.1.

Para más opciones lo mejor es consultar su pág ina man ? m an ipta bles

Para config urar un buen firewall, es importante realizar el seg uimiento de las
conexiones. E n iptables se puede llev ar este seg uimiento mediante el módulo s tate
el cual admite los sig uientes estados:

NE W : Un paquete establece una nuev a conexión con el sistema.

E S T A B L I S H E D : S e trata de paquetes que pertenecen a una conexión activ a
con el sistema.
R E L A T E D : Paquetes relacionados con una conexión existente pero que no
forman parte de ella directamente.
I NV A L I D : Paquetes que no se pueden identificar. Normalmente deberían
ser descartados.

E s importante que la primera reg la de un firewall sea que toda conexión con estado
R E LATE D o E S TABLIS HE D se deje pasar y a que esto ahorra el tener que buscar en
el resto de reg las y por lo tanto se aceleran las conexiones. T ambién posibilita que
las conexiones iniciadas por la máquina que estamos config urando y que necesiten
respuesta por parte de un host remoto sean aceptadas.

C on - m indicamos el módulo que queremos usar en la reg la, en este caso state y
con - - s ta te indicamos los estados del paquete.

E l serv icio iptables se utiliza ig ual que cualquier otro serv icio. C on
/etc/init.d/iptables stop/start podemos detener o iniciar el serv icio. Mediante
/ etc/ init.d/ iptables s av e g uardamos las reg las que hay amos escrito en
/ etc/ s y s config / iptables . Así pues, podemos escribir las reg las mediante
comandos en la shell o bien podemos editar el fichero en cuestión y a a adir las
reg las mediante un editor de texto.

Administración de sistemas de software libre 166

 Ca p ítulo 1 2

T roub les hooting

E n este capítulo se v an a estudiar div ersas técnicas para la resolución de

problemas. C uando el sistema tiene un problema es importante saber qué debemos
comprobar en cada caso para intentar aportar una solución lo más rápidamente
posible.

Al finalizar el estudio de estas lecciones serás capaz de:

C onocer div ersos problemas que pueden surg ir en el sistema.

Utilizar métodos g enéricos de resolución de problemas.

Administración de sistemas de software libre 167

 L e c ció n 1

T ip os d e p rob lem a s

P roblem as con las cuentas de los us uarios

E s posible que alg ún usuario nos informe de que tiene problemas con su cuenta del
sistema. Los errores pueden ser div ersos como por ejemplo: falta de permisos en
un cierto directorio, imposibilidad de hacer log in en el sistema…

Las causas de estos problemas pueden ser v arias por lo que es importante rev isar
los sig uientes puntos:

E l fichero / etc/ pas s w d

E ste fichero contiene información sobre los usuarios del sistema. E l formato del
fichero es similar al sig uiente:

E s importante que recuerdes qué representa cada columna:

1. Nombre de la cuenta del usuario.

2. C ontrase a del usuario codificada. No nos serv iría de nada intentar modificar
la contrase a del usuario aquí y a que lo único que conseg uiríamos es que la
cuenta quedara bloqueada. La x hace referencia también a que se está
usando el archiv o / etc/ s hadow .
3. E l número del identificador de usuario ( UID)
4. E l número del identificador del g rupo al que pertenece el usuario ( GID)
5. E l comentario que le hay amos asig nado al usuario. S i no le hemos asig nado
ning ún comentario, este campo quedará v acío.
6. E l directorio de trabajo del usuario al cual se conectará por defecto al iniciar
sesión en el sistema.
7. La shell o intérprete de comandos que utilizará el usuario al iniciar sesión en
el sistema.

Así pues, debemos aseg urarnos de que la cuenta del usuario en cuestión que esté
teniendo problemas exista en este fichero. Además, si queremos que el usuario
acceda al sistema deberemos comprobar también que tiene asig nada una shell o
intérprete de comandos distinta a /bin/false o /sbin/nolog in porque si tiene
asig nada cualquiera de esas dos no podrá acceder al sistema.

Administración de sistemas de software libre 168

S i el usuario está teniendo problemas porque accede al sistema y no se le sitúa en
el directorio habitual de trabajo deberemos comprobar que en este fichero dicho
parámetro esté config urado correctamente.

E s importante acordarse que con el comando us erm od podemos cambiar los

parámetros citados anteriormente para cada usuario.

E l fichero / etc/ s hadow

E n este fichero aparecen las contrase as de los usuarios encriptadas pero también
aparece otra información sobre las cuentas muy útil a la hora de correg ir fallos. E l
formato del fichero es el similar al sig uiente:

E l sig nificado de cada columna es el sig uiente:

1. Nombre del usuario.

2. C ontrase a cifrada. E n el caso de que aparezca "*" la cuenta no puede
iniciar sesión.
3. Número de días transcurridos desde el 1 de enero de 1970 hasta la fecha en
la que la contrase a fue cambiada por última v ez.
4. Número de días hasta que la contrase a se pueda cambiar.
5. Días en los que expira la contrase a y por lo tanto hay que cambiarla.
6. Días antes de la expiración de la contrase a a partir del cual se le env iarán
notificaciones al usuario para que la cambie.
7. Número de días después de que expire la contrase a tras los cuales se
inhabilitará.
8. Día en el que caduca la cuenta. S e cuenta a partir del 1 de enero de 1970.

E n este fichero es importante fijarse que no aparezca un "*" en la cuenta del

usuario que está teniendo problemas para hacer log in porque si aparece ese
símbolo, sig nifica que el usuario no tiene contrase a y por lo tanto no puede iniciar
sesión.

También es importante fijarse en que la contrase a no hay a expirado aunque eso

se puede v isualizar de una manera más clara con el comando chag e.

Mediante el comando chag e podemos v er información sobre las fechas de

expiración de las contrase as de un determinado usuario y también podemos
cambiar dichas fechas mediante la opción adecuada.

Administración de sistemas de software libre 169

S i no observ amos nada extra o en la cuenta de un determinado usuario podemos
consultar el log / v ar/ log / s ecure en el cual se reg istran todos los ev entos de inicio
de sesión así como los posibles errores que han aparecido a la hora de hacer log in
con un determinado usuario.

S i el problema se está teniendo con la cuenta de root como por ejemplo que no
recordemos la contrase a de este, será necesario acceder al sistema en modo
monousuario o sing le user.

S i se trata de un problema de permisos deberemos comprobar que efectiv amente el

usuario necesita tener permisos en esa ruta y facilitárselos mediante los comandos
y a conocidos chm od, chow n….

P roblem as de red

E s posible que se nos presenten problemas de red como por ejemplo que no
podemos nav eg ar o ni siquiera podemos resolv er el nombre de un determinado
dominio.

C on el comando ifconfig podemos comprobar las interfaces de red que están

habilitadas en este momento y con ifconfig - a se nos mostrarán todas las interfaces
que tenemos disponibles aunque no estén lev antadas.

ifconfig - a

Además de v er si las interfaces están lev antadas o no, se nos muestra la

información de los parámetros de red asignados a cada interfaz por lo que es una
buena forma de comprobar que los v alores han sido asig nados correctamente.
T ambién se muestra el v alor de los paquetes transmitidos ( tx) y recibidos ( rx) lo
cual también nos puede ay udar a la hora de determinar si está fallando una
determinada interfaz.

Administración de sistemas de software libre 170

También podemos comprobar si se están env iando y recibiendo paquetes mediante
el comando nets ta t - i

Para localizar errores la herramienta que se suele usar en la may oría de los casos
es ping . Mediante ping mandamos paquetes de tipo IC MP esperando que el host al
que le mandamos esos paquetes nos responda aunque es importante tener en
cuenta que el no recibir respuesta de un host remoto a la hora de realizar un ping
no siempre sig nifica que teng amos un problema de conectiv idad y a que es posible
que el host remoto esté config urado para no dev olv er las solicitudes de ping o
incluso rechazarlas tal y como hemos v isto en el tema de iptables.

Podemos usar ping para descartar alg unos fallos. Por ejemplo si intentamos hacer
un ping a otro equipo de la red y este no nos responde es muy probable que el
problema esté en la config uración de red de nuestro equipo o en el equipo al que le
hemos hecho ping . Podemos probar a hacerle ping también a la puerta de enlace
para comprobar si existe alg ún problema.

S i probamos a hacerle ping a un dominio externo a nuestra red como por ejemplo
www.g oog le.es y se nos dice que no se encuentra el host es muy probable que el
problema se encuentre en nuestra config uración dns o en el serv idor dns que
tenemos config urado.

Otro comando muy interesante es traceroute. S i hacemos traceroute a un

determinado host, nos aparecerán los nodos o enlaces por los que pasamos hasta
lleg ar al destino. C uando aparece un "*" en alg uno de esos nodos sig nifica que no
se obtiene respuesta y por lo tanto existe un problema con ese nodo. Un ejemplo
de un traceroute a www.g oog le.es:

E l primero salto siempre debería ser la puerta de enlace.

Administración de sistemas de software libre 171

Otra herramienta que resulta muy útil a la hora de diag nosticar problemas de red
es telnet. Haciendo un telnet a un determinado equipo al puerto que le indiquemos
podemos av erig uar si ese puerto está abierto o no. T ambién podemos hacer telnet
a un puerto de nuestro propio equipo para comprobar si el mismo se encuentra
abierto o no.

También debemos comprobar si lo que está impidiendo que nav eg uemos es el

propio firewall que teng amos config urado en el sistema. Para descartar que sea del
firewall podemos deshabilitarlo temporalmente.

S i la config uración de red la obtenemos por dhcp deberemos aseg urarnos que se
nos han proporcionado los datos correctamente, por el contrario, si los datos de la
config uración de red los asig namos de manera estática deberemos aseg urarnos de
que el fichero de config uración de la interfaz de red sea correcto. E ste fichero
podemos encontrarlo en / etc/ s y s config / netw ork- s cripts / ifcfg - ethx en centos.

S i la asig nación de datos la hacemos de manera manual deberemos aseg urarnos

también de tener config urado alg ún serv idor dns en el fichero / etc/ res olv .conf o
de lo contrario cuando preg untemos por un nombre de dominio no se nos
proporcionará la ip asociada con dicho dominio.

P roblem as de arranque

Para poder solucionar los problemas de arranque es necesario recordar la secuencia

que se sig ue para iniciar el sistema:

1. Al pulsar el botón de encendido lo primero que ocurre es que se inicia la

BIOS . La BIOS hace un test al equipo y comprueba que todos los
componentes funcionen correctamente. Después, la BIOS accede a una
memoria no v olátil ( nv ram) que g uarda la información de qué dispositiv o se
v a a utilizar para el arranque del sistema ( normalmente suele ser un disco
duro) . Una v ez localizado el dispositiv o de arranque se acceder a el y se
lanza el carg ador de arranque o bootloader.
2. E l bootloader se encuentra en el primer sector del dispositiv o utilizado para
el arranque al cual se le conoce como MBR ( Master Boot R ecord) . E l MBR
tiene un espacio muy reducido ( 512 by tes) el cual contiene una peque a
parte del bootloader y la tabla de particiones. Al tener esta limitación de
espacio, se hace que el bootloader carg ue el resto de la información desde
otra partición más g rande. La función principal del bootloader es carg ar el
kernel y ejecutarlo.
3. C uando el k ernel se inicializa, inicia los dispositiv os con sus respectiv os
driv ers, monta el sistema de archiv os de root / en modo sólo lectura y ,
finalmente, inicia el proceso padre /sbin/init ( PID 1) al cual le pasa los
mismos parámetros que ha recibido el.
4. Una v ez iniciado el init, este lee la config uración del fichero /etc/inittab e
inicia los scripts contenidos en /etc/rc.d/ en el niv el de ejecución definido en
el /etc/inittab. Después inicia las consolas v irtuales y finalmente, inicia la
v entana X ( entorno g ráfico) si el sistema se ha iniciado en el niv el de
ejecución 5.

Administración de sistemas de software libre 172

Así pues, resumiendo los pasos serían los sig uientes:

1. S e inicializa la BIOS .
2. Bootloader.
3. S e inicializa el k ernel.
4. S e inicializa el init que lee el fichero /etc/inittab e inicializa los scripts
/ etc/ rc.d/ rcX .d siendo X el niv el de ejecución que le hay amos definidos en
el fichero /etc/inittab en el parámetro initdefault

S i está fallando el bootloader ( en nuestro caso g rub) es posible que hay a que
reinstalarlo de nuev o en el MBR .

Después del bootloader se inicia el k ernel el cual se encarg a de iniciar los div ersos
dispositiv os así como el proceso padre init. Podemos comprobar si ha habido alg ún
fallo a la hora de inicializar estos dispositiv os o a la hora de montar alg una de las
particiones examinando el fichero de log / v a r/ log / dm es g

Una v ez que se inicia el init, se lee el fichero / etc/ inittab cuy o formato es el
sig uiente:

( S alida suprimida parcialmente)

E n la primera línea se le especifica el niv el de ejecución con el que se iniciará el

sistema por defecto, en este caso niv el de ejecución 5 ( con entorno g ráfico) . E l
niv el de ejecución por defecto se le pasa a los comandos que aparecen abajo y en
este caso se ejecutaría la línea:

Administración de sistemas de software libre 173

Mediante el comando anterior se lanzarían los scripts que hay dentro de la carpeta
/etc/rc.d/rc5.d:

Los que tienen una K ( k ill) delante se detienen y los que tienen una S ( start)
delante se inician. C ada directorio /etc/rc.d/rcX .d tiene config urados estos scripts
de manera diferente por lo que podemos config urar qué serv icios se inician en cada
niv el de ejecución lo cual resulta muy útil.

Conociendo el proceso de arranque del sistema y a sabemos los ficheros que

podemos rev isar si hay alg o que no v a bien a la hora de iniciar el equipo.

P roblem as con los s erv icios

E s posible que un determinado serv icio no arranque lo cual puede ser producido por
div ersas causas.

E s posible que hay amos a adido alg ún parámetro de manera errónea al fichero de
config uración del serv icio en cuestión. De esta forma, cuando intentamos iniciarlo,
al no entender el parámetro que hemos asig nado, el serv icio no se lev antará.

Para ev itar este tipo de problemas, la may oría de los serv icios llev an una utilidad
asociada que permite comprobar la sintaxis de los ficheros de config uración
asociados a los mismos de tal forma que si al utilizar la herramienta, se encuentra
alg ún parámetro incorrecto o nos hemos dejado alg o por a adir, se reportará un
error y , en la may oría de los casos, se mostrará el número de línea que contiene el
error y alg unas v eces incluso se mostrará una posible solución al problema que se
presenta.

Por ejemplo, si hemos modificado la config uración del serv icio apache y queremos
comprobar que la sintaxis es correcta antes de arriesg arnos a reiniciar el serv icio y
que este no se lev ante podríamos comprobarlo mediante apache2 ctl config tes t o
en el caso de bind9 mediante un na m ed- checkconf

E n el caso de que todo este correcto no dev olv erán ning ún mensaje o nos
aparecerá un S y ntax OK

Hay serv icios que no incorporan estas herramientas y por lo tanto deberemos tener
mucho cuidado a la hora de realizar modificaciones en sus archiv os de
config uración. Normalmente cuando un serv icio no puede iniciarse por la razón que
sea se reg istra un ev ento en el log / v ar/ log / m es s a g es .

Administración de sistemas de software libre 174

T ambién es posible que un serv icio no pueda lev antarse debido a que el puerto que
utiliza dicho serv icio está siendo utilizado por otro serv icio o aplicación. Podemos
comprobar si el puerto está siendo utilizado por otro serv icio o aplicación mediante
el comando netstat.

Y cuand o todo fa lla

Lo expuesto anteriormente son sólo alg unas pautas utilizadas

normalmente a la hora de resolv er problemas. La experiencia
es el factor más determinante cuando uno se enfrenta a un
problema similar a los que aquí aparecen.

Debido a que Linux es un S .O de software libre, existen

muchos usuarios que trabajan con el y conocen su
estructura lo cual posibilita que exista una g ran
comunidad de personas que se prestan soporte los
unos a los otros.

C uando tenemos un problema que no conseg uimos

resolv er, muchas v eces la mejor solución consiste
en buscar en internet sobre ese problema debido a que es muy probable que
alg uien más se hay a topado con el mismo problema y hay a conseg uido resolv erlo.

Administración de sistemas de software libre 175