El ABC del administrador

de sistemas Linux.

Pablo Sanz Mercado

[usuario@portatil ~]$ hostname

[usuario@portatil ~]$
[usuario@portatil ~]$ date
[usuario@portatil ~]$
[usuario@portatil ~]$ ls /etc
[usuario@portatil ~]$
[usuario@portatil ~]$ ifconfig
[usuario@portatil ~]$
[usuario@portatil ~]$ traceroute www.google.com
[usuario@portatil ~]$
[usuario@portatil ~]$ iptables -L

[usuario@portatil ~]$ more /etc/passwd

[usuario@portatil ~]$
[usuario@portatil ~]$ ldconfig
[usuario@portatil ~]$
[usuario@portatil ~]$ lspci
[usuario@portatil ~]$
Indice general

1. Comparativas de CPUs. 3

2. Preparaci
on de discos duros. 7

3. Instalacion de Linux. 9
3.1. Eleccion de la distribucion. . . . . . . . . . . . . . . . . . . . . 9
3.2. Multiples instalaciones. . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Kickstart. . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Creacion de imagenes. . . . . . . . . . . . . . . . . . . 19
3.3. Instalacion de Linux y Windows. . . . . . . . . . . . . . . . . 23
3.4. Gestor de arranque. . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Particionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . 24

4. Reconocimiento de hardware. 25
4.1. Sistema proc. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2. partitions . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3. meminfo . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.4. cpuinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2. Comandos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1. iostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2. mpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3. vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4. top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.5. lspci . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.6. lsusb . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.7. fdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5. Directorios en Linux. 33
5.1. /etc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1. aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

i
ii INDICE GENERAL

5.1.2. at.deny y cron.deny . . . . . . . . . . . . . . . . . . . . 35

5.1.3. cron.hourly, cron.daily, cron.weekly y cron.monthly . . 35
5.1.4. csh.login y csh.cshrc . . . . . . . . . . . . . . . . . . . 36
5.1.5. exports . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.6. fstab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.7. group . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.8. gshadow . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.9. host.conf . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.10. hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.11. hosts.allow y hosts.deny . . . . . . . . . . . . . . . . . 39
5.1.12. inittab . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1.13. issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.14. issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.15. ld.so.conf . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.16. login.defs . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.17. logrotate.conf . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.18. modprobe.conf . . . . . . . . . . . . . . . . . . . . . . 43
5.1.19. motd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.20. mtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.21. passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.22. profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.23. rc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.24. rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d . . . . . . . 45
5.1.25. rc.local . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.26. rc.sysinit . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.27. resolv.conf . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.28. securetty . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.29. services . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.30. shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.31. shells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.32. sysconfig . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.33. sysctl.conf . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.34. timezone . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.35. xinetd.d . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6. Scripts de arranque. 51
6.1. Configuracion y comandos basicos. . . . . . . . . . . . . . . . 52
6.2. service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3. chkconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7. Creaci on de usuarios. 57
7.1. Entorno grafico. . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2. Lnea de comandos. . . . . . . . . . . . . . . . . . . . . . . . . 58
INDICE GENERAL iii

8. Tcpwrappers 61
8.1. Configuracion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.1. Palabras especiales. . . . . . . . . . . . . . . . . . . . . 65
8.1.2. Patrones. . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.1.3. Operadores. . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.4. Comandos de shell. . . . . . . . . . . . . . . . . . . . . 68

9. Cortafuegos 71
9.1. Estudio previo. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.1.1. Topologa de la red a proteger. . . . . . . . . . . . . . 73
9.1.2. Servicios mas accesibles. . . . . . . . . . . . . . . . . . 75
9.1.3. Equipos fundamentales en mi red. . . . . . . . . . . . . 75
9.1.4. Trafico generado. . . . . . . . . . . . . . . . . . . . . . 76
9.1.5. Presupuesto y personal disponible. . . . . . . . . . . . 76
9.2. iptables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.3. Poltica por defecto. . . . . . . . . . . . . . . . . . . . . . . . 78
9.4. Inicializacion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.5. Cadena INPUT. . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.5.1. Servidores de nombres. . . . . . . . . . . . . . . . . . . 82
9.5.2. Cadena OUTPUT. . . . . . . . . . . . . . . . . . . . . 82
9.5.3. IP spoofing. . . . . . . . . . . . . . . . . . . . . . . . . 83
9.5.4. Conexiones establecidas o relacionadas. . . . . . . . . . 84
9.5.5. Servidor FTP. . . . . . . . . . . . . . . . . . . . . . . . 85
9.6. Scripts de inicio. . . . . . . . . . . . . . . . . . . . . . . . . . 86
9.6.1. Ejemplo de script. . . . . . . . . . . . . . . . . . . . . 88

10.Accounting. 93

11.Prevision de ataques. 101

11.1. chkrootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
11.2. Rootkit Hunter. . . . . . . . . . . . . . . . . . . . . . . . . . . 103

12.Backup 105
12.1. Herramientas propias. . . . . . . . . . . . . . . . . . . . . . . 108
12.1.1. dump . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12.1.2. tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.1.3. cp/scp . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.1.4. rsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

13.Control de logs. 113

13.1. rsyslog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
13.2. Logwatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

14.Sistema de cuotas. 119

15.Wake On Lan. 125

iv INDICE GENERAL

16.Otras tareas administrativas. 127

16.1. strace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
16.2. Ejecucion en varias maquinas. . . . . . . . . . . . . . . . . . . 128
16.3. Integridad de las particiones. . . . . . . . . . . . . . . . . . . . 129
16.4. Desfragmentacion. . . . . . . . . . . . . . . . . . . . . . . . . 130

17.Actualizaciones. 131
17.1. yum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
17.2. apt-get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
17.3. yast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Captulo 1

Comparativas de CPUs.

3
4 CAPITULO 1. COMPARATIVAS DE CPUS.

Una de las decisiones mas importantes del responsable de compras de un

Centro de Calculo es la eleccion del tipo de procesadores a utilizar en las
maquinas que vaya a comprar.
Muchas veces este tipo de decisiones, muy erroneamente, se dejan al azar,
permitiendo que los comerciales de las diferentes empresas que nos muestran
presupuestos decidan por nosotros.
Un presupuesto mas economico no es sinonimo de buena compra, y en
estas adquisiciones jamas tendremos que mirar u nicamente el precio total de
la adquisicion, sino sentarnos tranquilamente y pensar durante el tiempo que
sea necesario cual de las ofertas obtenidas es la mas interesante para nuestras
necesidades.
Como veremos, hay muchos tipos de CPUs. Principalmente podemos pen-
sar en los dos principales generadores de procesadores, AMD e Intel, si -
bien hay otros productores que quizas deberamos comprobar antes de tomar
cualquier decision.
De ninguna manera podremos guiarnos sin mas por una decision de alg un
otro responsable que nos haya ofrecido su ayuda, pues lo principal es evaluar
las necesidades que nosotros concretamente tenemos. Es primordial tener los
procesadores mas rapidos? Utilizo programas que primordialmente trabajan
con enteros? Utilizo programas que primordialmente trabajan con reales?
Tengo alg un limitante en el n umero maximo de equipos que puedo instalar
en mis dependencias?
Estas y muchas otras preguntas nos las tendremos que hacer para fi-
nalmente obtener una respuesta que nos gue a una compra correcta para
nosotros.
Como un caso quizas extremo, podramos pensar en que disponemos de
una sala de maquinas muy espaciosa y que tanto el consumo electrico como la
disipacion de calor no son preocupaciones nuestras sino de otro departamento
que nos da va libre en la compra. Si esto es as, y nuestra necesidad es la
de realizar el maximo n umero de calculos simultaneos pero sin importarnos
la velocidad maxima de cada uno de ellos, es posible que nuestra decision
sea la compra de equipos convencionales. Por que no comprar equipos de
sobremesa? Son extremadamente baratos y con el mismo dinero con el que
compraramos servidores de u ltima generacion podremos alcanzar un n umero
muy considerable de cpus que finalmente calcularan mucho mas que los
servidores de ultima generacion.
Ahora bien, si lo que necesitamos es tener los resultados cuanto antes,
como nos vamos a decidir por las cpus integradas en equipos de consumo
pudiendo elegir cpus dise nadas para el calculo masivo?
Pero es mas, si nuestros programas basicamente utilizan calculos entre
enteros, por que comprar procesadores que se comportan considerablemente
bien con calculos con n umero de coma flotante? Por que no centrarnos en
procesadores que se comporten bien en calculos con n umero enteros?
Para llegar a una correcta solucion, lo que tendremos que hacer es con-
seguir una comparativa correcta de las cpus que entran dentro de nuestras
 5

necesidades. Un organismo ajeno a cualquier compa

na y que publica com-
parativas de cpus es

www.spec.org

Esta organizacion (Standard Performance Evaluation Corporation), pu-

blica diferentes comparativas de tal forma que podremos comparar facilmente
el comportamiento de dos cpus distintas, pues obtendremos n umeros perfec-
tamente comparable tras haber ejecutado un conjunto de pruebas.
Estas pruebas pueden ser con n umeros enteros o con numeros en coma
flotante, de tal forma que podremos comprobar que procesadores se compor-
tan mejor en cada tipo de calculos.
Si bien podramos pensar que esto ya es suficiente para nosotros, tenemos
que tener en cuenta que todava no sabemos cual es el dise no de los proce-
sadores. Para nosotros, para nuestros calculos concretamente, me podre fiar
de estas medidas?
Por supuesto que www.spec.org nos ofrece una informacion totalmente
fiable, pero si tuvieramos la posibilidad de probar dos equipos con el sistema
operativo que vamos a instalar, con los compiladores que vamos a utilizar y
con los programas que necesitaremos, entonces los graficos que generaramos
con las diferentes comparaciones s que nos podran dar una ayuda muy
importante y que nos conducira a una decision final.
No obstante nos queda el u ltimo punto, el procesador en s. Como fun-
ciona? Que diferencias hay entre uno y otro procesador? Hay alg un motivo
en este sentido que me gue a utilizar un procesador u otro?
En este u ltimo caso entonces tendremos que recurrir a la informacion
proporcionada por cada uno de los fabricantes, donde podremos ver la infor-
macion del numero de registros disponibles, de la cantidad de cache a la que
podremos optar, de la forma de gestionar la memoria, etc.
Si bien en muchas ocasiones esta informacion nos supera e incluso es
superflua para la decision de compra, es recomendable comprobar todos estos
numeros para no llevarnos sorpresas desafortunadas.
Captulo 2

Preparaci
on de discos duros.

7
8 CAPITULO 2. PREPARACION
DE DISCOS DUROS.

El primer paso que debemos dar cuando queremos instalar un sistema

operativo en nuestro ordenador, es el particionamiento de nuestro disco duro.
Este paso muchas veces se hace de forma rapida y sin un estudio previo de
las expectativas que tenemos sobre el sistema, y por tanto es mas que posible
que necesitemos redise nar las particiones a posteriori en muchas ocasiones.
Con el fin de redise
nar particiones, pero tambien por supuesto con el fin
de crearlas, existen diferentes herramientas disponibles, como por ejemplo
Partition Magic. El problema de muchas de estas herramientas es su coste,
y es que estas herramientas quizas no tengan un coste elevado, pero si em-
pezamos a sumar los precios de todas y cada una de las herramientas que
un administrador debera tener, probablemente la cantidad total supere el
presupuesto del que disponemos.
Una herramienta equivalente, pero gratis, es gparted

http://gparted.sourceforge.net

que podremos instalar en nuestro sistema, pero tambien podemos bajarnos

un live-cd de tal forma que simplemente tras meterlo en la lectura de cds y
arrancar el sistema, se nos abrira un entorno grafico con la aplicacion gparted.
Esta aplicacion es extremadamente sencilla de utilizar, de tal forma que
veremos en pantalla la representacion de nuestro disco duro de forma lineal,
con las diferentes particiones.
Podremos por tanto eliminar particiones existentes, crear particiones y
modificar (redimensionar por ejemplo) las particiones que tengamos.
Esta herramienta es por tanto fundamental para cualquier administrador,
con el fin de poder crear las particiones de forma previa a una instalacion,
por ejemplo, o bien para poder modificar las ya existentes en el caso de que
encuentre una mala prevision en el particionado existente.
Tambien debemos tener en mente que los sistemas operativos modernos
tienen herramientas propias para el redimiensionado de particiones. De esta
forma podremos por ejemplo, desde un sistema Windows 7, disminuir una
de sus particiones si es que lo necesitamos. Tambien, por ejemplo, podremos
realizar esta accion a la hora de instalar una distribucion de Linux, ya que en
su men u de particionamiento del disco aparecera una opcion que es el redi-
mensionado y que funciona de forma equivalente a lo que habamos indicado
para gparted.
Captulo 3

Instalaci
on de Linux.

3.1. Elecci
on de la distribuci
on.

9
10 CAPITULO 3. INSTALACION
DE LINUX.

Hoy en da tenemos multitud de distribuciones que podremos bajar a

nuestro equipo facilmente.
Originalmente fueron tres las distribuciones principales que existan, a
saber: Debian, Slackware y RedHat.
Estas distribuciones han dado lugar a centenares de distribuciones que
han ido naciendo, y muriendo, a lo largo de la historia de GNU/Linux.
Cual es la distribucion que debo elegir?
Realmente esta pregunta no tiene una respuesta concreta, sino que se
contesta indicando pros y contras que podremos tener a la hora de utilizar
una distribucion u otra.
Si lo que queremos es tener una distribucion GNU/Linux con la que po-
damos utilizar la lnea de comandos y practicamente nada mas, cualquiera
de las distribuciones que utilicemos sera valida. La lnea de comandos practi-
camente no tiene diferencia entre distribuciones, y si aprendemos a utilizar
los comandos en una distribucion, podremos trabajar con cualquier otra sin
el mas mnimo problema.
Donde s vamos a encontrar diferencias es en la instalacion del sistema
operativo, pues hay diferentes entornos de instalacion utilizados por difer-
entes distribuciones. Si nos gusta mas un programa de instalacion que otro,
esta puede ser una buena excusa para utilizar una distribucion u otra.
Si creemos que esta idea es muy basica, y que no debemos guiarnos por
la instalacion para centrarnos en la utilizacion de una u otra distribucion,
debemos tener presente que otra de las ideas que las diferencia es la forma
de actualizacion del sistema, as como de la instalacion de los programas.
Por ejemplo distribuciones basadas en Debian utilizan el entorno apt para
realizar estas tareas, mientras que las distribuciones basadas en RedHat uti-
lizan yum. Cual de las dos opciones es mejor? De nuevo necesitamos algo
de subjetividad para responder a esta pregunta, ya que en ambos entornos
conseguiremos la instalacion de programas o la actualizacion del sistema op-
erativo, y quizas sea la forma / estetica de hacerlo lo que nos haga preferir
una version respecto a otra.
Tambien podemos seguir con otras diferencias entre distribuciones, que
quizas nos permitan ser un tanto mas estrictos desde el punto de vista ob-
jetivo, con valores cuantificables. Siguiendo esta idea podemos elegir aquella
distribucion que tenga una buena poltica de actualizaciones, ya que este
punto es fundamental sobre todo si tenemos un entorno que queremos que
vaya evolucionando y sea atractivo al usuario final.
Algunas distribuciones nacen con mucha fuerza, con mucho animo por
parte de sus creadores, pero poco a poco desaparecen debido a la discon-
tinuidad de su producto. Su desaparicion es logica pues a nadie le gusta
tener una distribucion de GNU/Linux que no haya sido modificada en a nos.
El soporte es otra de estas ideas que podemos cuantificar facilmente.
Hay distribuciones que dan soporte directo, por el que cobran una cierta
cantidad de dinero, y que nos permite tener una cierta tranquilidad si tenemos
cualquier problema con el sistema operativo. Son estas distribuciones muy
 DE LA DISTRIBUCION.
3.1. ELECCION 11

utilizadas en entornos que requieren continuidad, que no pueden permitirse

ninguna parada, y que pueden permitirse el pago por el mantenimiento.
Una distribucion que cobra por soporte y que tiene mucho exito es Red-
Hat. Inicialmente era una distribucion de GNU/Linux ajena a la comercial-
izacion, pero en un momento determinado se dividio en dos ramas, Fedora
Core por una parte y Red Hat Enterprise por otra. La primera es una distribu-
cion de la comunidad, totalmente gratuita, y la segunda es una distribucion
gestionada por un equipo de personas que se mantiene gracias al cobro de
soporte.
Tras esta separacion hubo ciertos fabricantes de servidores, y desarrol-
ladores de software, que realizaron alianzas con RedHat para dar una cierta
calidad y continuidad a sus servicios con una distribucion de GNU/Linux
como RedHat. Esto hizo muy complicada la supervivencia de centros de
computacion con pocos recursos, en el sentido de que si no pagaban por el
mantenimiento de RedHat no podan tener acceso al soporte de las empresas
de hardware o de los desarrolladores de software cuando tenan problemas,
pues estos no soportaban otras distribuciones que no fueran RedHat.
CentOS, junto con otras, ha sido una distribucion que ha diezmado estos
problemas. CentOS (Community ENTerprise Operating System) se describe
como a free rebuild of source packages from the Red Hat Enterprise Linux, es
decir, utilizan el codigo fuente libre de Red Hat Enterprise Linux y lo recom-
pilan. El resultado por tanto es una distribucion totalmente equivalente que
podemos utilizar de forma similar a RedHat, y que nos permite interaccionar
con hardware y software como si estuvieramos trabajando con RedHat. La
diferencia, por supuesto, es que no tenemos soporte, pero el soporte de la
comunidad de usuarios de GNU/Linux es tan amplio que podremos tener
resuelto un problema en relativo poco tiempo en la mayora de las ocasiones.
En cuanto al soporte debemos tener muy presente que si pagamos por el
vamos a tener un contrato que nos garantizara una solucion en un determina-
do tiempo. Si no pagamos por el soporte la solucion al problema dependera de
lo rapido que seamos buscando en Internet por problemas equivalentes o de lo
rapido que sean otros compa neros de profesion a la hora de contestar nues-
tra pregunta. Dependiendo de las necesidades de continuidad de nuestros
servicios, tendremos que considerar una u otra opcion.
12 CAPITULO 3. INSTALACION
DE LINUX.

3.2. M
ultiples instalaciones.

3.2. MULTIPLES INSTALACIONES. 13

3.2.1. Kickstart.
Una forma de realizar m ultiples instalaciones equivalentes, es mediante
kickstart.
Esta forma de trabajo es muy utilizado en distribuciones de la rema de
Redhat, que permite crear un fichero llamado ks.cfg por defecto, que sera uti-
lizado por el entorno de instalacion para tomar de forma desatendida todas
las decisiones necesarias en una instalacion. De esta forma podremos instalar
un equipo o varios de la misma forma, con las mismas opciones, permitien-
do as poder realizar grandes instalaciones con m ultiples servidores de una
forma sencilla.
Otra ventaja de Kickstart es que haremos una instalacion desatendida,
pero en definitiva sera una instalacion. Para entender esto debemos pensar
en una instalacion desatendida proviniente de una imagen. Esta la haremos
instalando un servidor y luego clonandolo una y otra vez. El problema con
esta instalacion es que los ordenadores donde copiaremos el clon deben ser
equivalentes al original. Si no tenemos la misma capacidad de disco duro, por
ejemplo, podremos tener un problema. Con la instalacion mediante Kickstart
nos ahorramos este problema, ya que cada ordenador se instalara con las
pautas que le indiquemos en Kickstart. Siguiendo con el ejemplo del disco
duro podremos crear diferentes particiones y para crear la u ltima particion
podremos indicar que el sistema utilice lo que le quede de disco duro. Si el
servidor donde estamos instalando tiene u nicamente 1MB libre, utilizara esta
capacidad para la nueva particion, pero si tiene 10TB libres sera los que
utilice.
Un truco interesante para tener el perfil de instalcion de Kickstart, es
decir, el fichero ks.cfg, es instalar un equipo a mano, de forma interactiva, y
al final de la instalacion podremos comprobar que en el directorio /root nos
habra dejado un fichero llamado anaconda-ks.cfg si estamos utilizando una
distribucion que utilice Anaconda como gestor de instalacion.
Este fichero es un perfecto perfil de configuracion de Kickstart que po-
dremos utilizar para instalar otros equipos de forma equivalente al primero.
La forma de instalar un ordenador utilizando estos perfiles de instalacion
es sencilla, pues lo unico que tendremos que hacer es introducir el comando
ks en el indicador de comandos boot con la ruta en la que esta el fichero
ks.cfg, es decir, cuando arranca el instalador, en vez de pulsar ENTRAR sin
mas, teclearemos:

linux ks=floppy

si tenemos este fichero en un disquete, si bien podemos guardar este archivo

en otros medios:

ks=cdrom:/ks.cfg

para especificar que hemos guardado en el directorio principal del cdrom el

archivo ks.cfg.
14 CAPITULO 3. INSTALACION
DE LINUX.

ks=nfs:servidor:/camino

si hemos guardado el archivo en un directorio de un servidor nfs. En este

u
ltimo caso deberamos especificar el dispositivo que vamos a utilizar para
poder acceder al servidor nfs mediante la opcion ksdevice:

ksdevice=eth1

si queremos utilizar la tarjeta de red identificada como eth1.

Con este tipo de instalacion deberemos tener cuidado, como indicamos
tambien en el punto anterior, con la configuracion de red ya que sera exacta-
mente la misma que en el ordenador del cual obtuvimos el fichero anaconda-
ks.cfg o la que hayamos editado nosotros, por lo tanto deberemos cambiarla
antes de conectar el ordenador a la red si esta configuracion puede plantear
algun conflicto de IP.
Un ejemplo de fichero de configuracion puede ser:

install
cdrom
lang es_ES.UTF-8
langsupport --default es_ES.UTF-8 es_ES.UTF-8
keyboard es
network --device eth0 --bootproto static --ip 192.168.32.99
--netmask 255.255.255.0 --gateway 192.168.32.1
--nameserver 192.168.9.100,192.168.9.200,130.206.1.2
--hostname servidor.dominio
rootpw --iscrypted $1$o1DG1PR3$IofHRrWIgA5dL1MgoB6GN.
firewall --disabled
selinux --disabled
authconfig --enableshadow --enablemd5
timezone Europe/Madrid
bootloader --location=mbr --append rhgb rhgb quiet
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --all
#part / --fstype ext3 --size=6000 --ondisk=sda --asprimary
#part /home --fstype ext3 --size=2048 --ondisk=sda --asprimary
#part /scratch --fstype ext3 --size=500 --grow --ondisk=sda
--asprimary
#part swap --size=256 --ondisk=sda --asprimary

3.2. MULTIPLES INSTALACIONES. 15

%packages
@ kde-desktop
@ spanish-support
@ gnome-desktop
@ dialup
@ editors
@ xemacs
@ admin-tools
@ system-tools
@ base-x
@ printing
@ ruby
@ kernel-development
@ xemacs
@ development-tools
@ ruby
@ engineering-and-scientific
grub
kernel
e2fsprogs

%post

Iremos explicando lnea a lnea el significado de las mismas.

cdrom

Mediante esta lnea indicamos que la instalacion se va a realizar mediante

cdrom, es decir, todos los archivos necesarios para realizar la instalacion los
vamos a proporcionar mediante un juego de cdroms.

lang es_ES.UTF-8

La instalacion se realizara en castellano.

langsupport --default es_ES.UTF-8 es_ES.UTF-8

El sistema operativo se instalara utilizando el idioma castellano como

soporte de lenguaje por defecto.

keyboard es

El teclado que vamos a utilizar es un teclado espa

nol.
16 CAPITULO 3. INSTALACION
DE LINUX.

network --device eth0 --bootproto static --ip 192.168.32.99

--netmask 255.255.255.0 --gateway 192.168.32.1
--nameserver 192.168.9.100,192.168.9.200,130.206.1.2
--hostname servidor.dominio
Tambien tendremos que indicar la configuracion de red del equipo. Esta
configuracion es sencilla de seguir, pues podemos ver facilmente que la tar-
jeta de red eth0, la primera tarjeta de red de nuestro sistema, sera activada
por defecto al arrancar el ordenador y configurada con la ip 192.168.32.99,
mascara de red 255.255.255.0, puerta de enlace 192.168.32.1, servidores de
nombres 192.168.9.100, 192.168.9.200 y 130.206.1.2 y finalmente el nombre
del ordenador en este caso sera servidor.dominio. Estos datos tendremos que
cambiarlos para cada uno de los nodos, para no provocar conflictos IP al dar-
les a todos los nodos la misma configuracion de red. Podremos, por ejemplo,
crear varias copias del mismo fichero en las que cambie la configuracion de
red, iniciando la instalacion de cada uno de los nodos con el fichero corre-
spondiente y no teniendo por tanto ning un problema de instalacion.
rootpw --iscrypted $1$o1DG1PR3$IofHRrWIgA5dL1MgoB6GN.
Mediante esta lnea estableceremos la contrasena de root. Efectivamente
esta sera la misma para todos los nodos si utilizamos la misma lnea en cada
uno de los nodos. Sera poltica del administrador cambiarla en cada una de
las instalaciones o dejar la misma para todos ellos.
firewall --disabled
selinux disabled
Mediante estas lneas desactivaremos por defecto la seguridad que nos
proporciona la instalacion de un firewall en nuestro sistema y la capacidad
ofrecida por selinux. Esta en nuestra mano por tanto cambiar la opcion para
permitir la instalacion de estas dos funciones.
authconfig --enableshadow --enablemd5
La forma de autentificacion la estableceremos mediante esta lnea, donde
especificamos que en nuestro sistema utilizaremos contrasenas de tipo shad-
ow y md5, si bien es posible que queramos utilizar sha512 que nos propor-
cionara una mejora en la seguridad del equipo.
timezone Europe/Madrid
Muy importante es esta lnea sobre todo a la hora de actualizar sin ning
un
problema el reloj de nuestro ordenador, ya que al especificar que estamos en
Madrid-Europa, esto sera tenido en cuenta si realizamos una actualizacion de
hora gracias a NTP, ajustando el desfase horario sin problemas. Tambien es
importante en otras tareas del sistema como por ejemplo a la hora de mandar
mensajes de correo electronico, ya que normalmente cuando ordenamos por
fecha los mensajes obtenidos se suele tener en cuenta los desfases horarios
para que realmente tengamos un orden real.

3.2. MULTIPLES INSTALACIONES. 17

bootloader --location=mbr --append rhgb rhgb quiet

El cargador del sistema operativo lo instalamos mediante esta lnea, en

la que decimos que sera instalado en el Master Boot Record (mbr) y las
opciones que daremos al kernel seran rhgb rhgb quiet.

clearpart --all
part / --fstype ext3 --size=6000 --ondisk=sda --asprimary
part /home --fstype ext3 --size=2048 --ondisk=sda --asprimary
part /scratch --fstype ext3 --size=500 --grow --ondisk=sda
--asprimary
part swap --size=256 --ondisk=sda --asprimary

Estas lneas son las que nos permiten particionar el disco duro de nue-
stro ordenador. Tendremos que tener gran cuidado en las mismas para evitar
perdida de datos por una mala configuracion en un equipo con una insta-
lacion previa. En el ejemplo que tenemos eliminamos todas las particiones si
estas existieran (clearpart all) y a continuacion creamos cuatro particiones,
/, /home, /scratch y swap del tipo ext3 salvo la u ltima, que no tendra for-
mato ext3 al ser swap. Todas las particiones las creamos en el primer disco
duro de nuestro equipo, de ah que escribamos ondisk=sda y forzamos a que
sean particiones primarias mediante asprimary. El tama no de las mismas
lo fijamos, para finalizar, mediante la opcion size= donde estableceremos
el numero de megabytes que asignaremos a cada particion, diferenciando la
particion /scratch del resto en este caso ya que en la lnea correspondiente
hemos a nadido la opcion grow, que permitira asignar todo el espacio restante
del disco duro a esta particion, evitando por tanto tener que saber exacta-
mente el tama no del disco duro, y pudiendo utilizar esta configuracion en
ordenadores con discos duros de diferente capacidad ya que permitimos que
/scratch tenga una capacidad mayor que 500 Mb dandonos igual el tama no
final de la misma.

%packages
@ kde-desktop
@ spanish-support
@ gnome-desktop
@ dialup
@ editors
@ xemacs
@ admin-tools
@ system-tools
@ base-x
@ printing
@ ruby
@ kernel-development
@ xemacs
18 CAPITULO 3. INSTALACION
DE LINUX.

@ development-tools
@ ruby
@ engineering-and-scientific
grub
kernel
e2fsprogs

A continuacion de %packages escribimos las familias de paquetes que va-

mos a instalar en nuestro equipo si estas van precedidas mediante una arroba,
de tal forma que el instalador copiara en nuestro equipo todos los programas
que formen parte por defecto de cada una de estas familias. Adicionalmente
podremos escribir los paquetes adicionales que queremos instalar en nuestro
equipo y que no formen parte, por defecto, de ninguna de las familias que
hemos escrito. En este caso escribiremos el nombre de cada uno de los pa-
quetes adicionales pero sin ser precedidos por ning un caracter.

%post

Finalmente, y precedido por %post, escribiremos todos aquellos comandos

que queremos que se ejecuten a posteriori, es decir, una vez realizada la insta-
lacion, pudiendo por tanto crear diferentes usuarios en todas las maquinas sin
necesidad de teclear absolutamente nada despues de la instalacion, o modi-
ficar el fichero /etc/hosts de forma analoga en todos los nodos instalados o
cualquier cosa que se nos ocurra y que queramos realizar de forma automatica
mediante kickstart y sin interaccion por parte del administrador encargado
de instalar los equipos, simplificado por tanto enormemente las tareas que
siempre hay que realizar tras la instalacion de una maquina.

3.2. MULTIPLES INSTALACIONES. 19

3.2.2. Creaci
on de im
agenes.
Cuando hemos instalado un equipo, el tiempo que hemos invertido puede
ser realmente elevado, pues no solo esta el tiempo de instalacion del mismo,
sino ademas todo el tiempo de configuracion que supera en la mayora de las
ocasiones al primero.
Es muy posible que queramos guardar una copia exacta de esta instalacion
para evitar emplear otra vez tal cantidad de tiempo en el caso de necesitar
una reinstalacion de este equipo, o por ejemplo si necesitamos instalar varios
equipos de forma equivalente.
En este sentido no debemos preocuparnos pues disponemos de la her-
ramienta partimage, que nos permite realizar una copia exacta y ademas
siendo una herramienta gratuita.
Para poder utilizarla nos bajaremos un live cd de la pagina oficial:

http://www.partimage.org/Main_Page

ya que este cd nos permitira arrancar la maquina sin necesidad de hacer uso
del disco duro, de la informacion contenida en el, para este arranque.
Con este programa se pueden generar imagenes de cada una de las par-
ticiones existentes en el sistema, grabandolas sin comprimir o comprimidas
con gzip o bzip2. Ademas este programa lo podremos utilizar mediante un
entorno de men us o por lnea de comando, lo que le confiere la posibilidad
de poderlo utilizar sin apenas interaccion.
Tanto si utilizamos el entorno de men us, como la lnea de comandos,
lo primero que deberemos hacer es, una vez hayamos arrancado el equipo
utilizando el LiveCD, montar los dispositivos donde vayamos a grabar las
imagenes, por ejemplo un disco duro externo:

mkdir /mnt/usb
mount -t ext3 /dev/sdb1 /mnt/usb

en este sentido comentar que nunca deberemos montar un dispositivo en

/mnt, pues este directorio es utilizado por el live cd y podramos dejar inop-
erativo este sistema operativo, teniendo que reiniciar el equipo para volver a
una situacion estable.
Para obtener el men u de partimage, ejecutaremos este programa sin mas:

partimage

y obtendremos una pantalla en la que aparecen todas las particiones disponibles

en el ordenador. Seleccionaremos entonces una de ellas, y en la ventana donde
podemos leer Image file to create/use escribiremos el nombre que queremos
tenga el archivo imagen que se creara de esta particion.
La recomandacion en este punto es escribir el nombre con el path comple-
to, es decir, en nuestro caso podramos escribir /mnt/usb/imagen-sda1 por
ejemplo.
20 CAPITULO 3. INSTALACION
DE LINUX.

En este men u, en el apartado donde podemos leer Action to be done lo

dejaremos como Save partition into a new image file, que es la opcion que
viene por defecto, y pulsaremos F5 para continuar.
En la siguiente pantalla seleccionamos bzip2 como herramienta de com-
presion, pues aunque tardara mas la aplicacion en generarnos las imagenes,
estas ocuparan menos que las generadas con gzip y que por supuesto las no
comprimidas.
Pulsamos F5 para continuar y empezara a generar la imagen tras pedirnos
una descripcion de la imagen (un nombre cualquiera, por ejemplo el directorio
en el que la montamos, para luego, al escribirlas en disco, ser mas faciles de
indentificar).
Estas operaciones se hacen para cada una de las particiones que tengamos
en el equipo, de tal forma que al final tendremos al menos un archivo, en el
disco duro externo donde estamos grabando las imagenes, por cada una de
las particiones.
A continuacion lo que haremos es salvar el Master Boot Record, con el fin
de que si luego utilizamos estas imagenes en otro equipo, este pueda arrancar
sin mayor problema.
Para guardar el MBR utilizaremos el comando dd:

dd if=/dev/sda of=/mnt/usb/backup-del-mbr bs=1 count=512

y a continuacion guardaremos tambien la tabla de particiones con sfdisk:

sfdisk -d /dev/sda > /mnt/usb/backup-de-la-tabla-de-particiones

Si en algun momento lo que queremos hacer son los pasos inversos, es

decir, utilizar estas imagenes en otro equipo para crear un clon del original,
primero crearemos las particiones necesarias y escribiremos el MBR en el
disco destino:

sfdisk /dev/sda < /mnt/usb/backup-de-la-tabla-de-particiones

dd if=/mnt/usb/backup-del-mbr of=/dev/sda

Y a continuacion ejecutaremos el programa partimage, pero esta vez lo

que haremos es utilizar imagenes ya generadas que grabaremos en el disco
duro.
Para ello en el primer men u seleccionaremos la particion deseada y es-
cribiremos el nombre de la imagen a restaurar. Seleccionaremos entonces Re-
store partition from an image file y en el siguiente men u elegiremos Erase free
blocks with zero values para que deje el disco vaco y solo con los datos de las
imagenes originales. Pasaremos al siguiente men u pulsando F5 y empezara a
grabar la imagen en nuestro disco duro.
Una vez hecho esto para cada una de las particiones existentes, tendremos
un clon perfecto del ordenador original, pero con la ventaja de haber emplea-
do mucho menos tiempo en su consecucion.

3.2. MULTIPLES INSTALACIONES. 21

La ventaja de partimage es que puedo utilizar la lnea de comandos para

realizar todos y cada uno de los pasos descritos, y por lo tanto crear un
script que, tras ejecutarlo, me realice todos y cada uno de los pasos descritos
anteriormente sin interaccion.
Imaginemos que tenemos un ordenador ya instalado en tiene un disco duro
/dev/sda con varias particiones. Este disco duro es el unico en el sistema. A
parte de este instalaremos un disco duro usb para poder realizar el volcado
de las imagenes, y que montaremos en /mnt/usb.
El script que podramos crear podra ser:
#!/bin/bash
cat /proc/partitions|grep da|grep -v " 0 "|awk {print $4}
|while read particion
do
partimage -z2 -b -o -d save /dev/$particion
/mnt/usb/${particion}.bz2
done

disco=cat /proc/partitions|grep da|grep " 0 "

|awk {print $4}

dd if=/dev/$disco of=/mnt/usb/backup-mbr-$disco
count=1 bs=512
sfdisk -d /dev/$disco > /mnt/usb/backup-particionado-$disco
La primera lnea lo que hace es encontrar que particiones tenemos en el
disco duro. Como solo tenemos un disco duro interno, mediante grep da nos
quedaremos con la informacion del fichero /proc/partitions que responda a
este patron, que solo sera la del disco duro /dev/sda. El siguiente grep uti-
lizado lo que hara es quedarse solo con las particiones, pues en la informacion
obtenida en /proc/partitions tambien aparece el propio disco /dev/sda
El bucle que creamos en esta primera lnea sera entonces el principal
de todo el script, sera el que nos permita realizar todas y cada una de las
imagenes de las particiones existentes en el disco.
Nos fijamos entonces que para cada particion lo que hara es ejecutar el
comando partimage diciendole que creara (save) un imagen de la particion
/dev/$partition dandole como nombre /mnt/usb/$partition.bz2.000 (el 000
lo incluira partimage), sobreescribiendo si ya exista (-o), no pidiendo etiqueta
de la particion (-d) y ademas en batch mode (-b), es decir, no requerira in-
teraccion ninguna.
A continuacion cargamos el valor /dev/sda en la variable disco, y luego
utilizaremos esta variable para guardar tanto el MBR como la tabla de par-
ticiones.
La ejecucion de este script no necesita por tanto interaccion del admin-
istrador, pudiendolo ejecutar y volver al cabo de cierto tiempo, teniendo el
trabajo realizado.
22 CAPITULO 3. INSTALACION
DE LINUX.

En el caso de que quisieramos hacer el paso contrario, es decir, automa-

tizar la clonacion de un ordenador con estos ficheros que acabamos de crear,
lo que haremos es un script equivalente:

#!/bin/bash

disco=cat /proc/partitions |grep da |grep " 0 "

|awk {print $4}

dd if=backup-mbr-$disco of=/dev/$disco
sfdisk /dev/$disco < backup-particionado-$disco

ls *.000 |cut -d . -f 1|while read particion

do
partimage restore -b /dev/$particion ${particion}.bz2.000
done

y rapidamente tendremos el clon creado.

 DE LINUX Y WINDOWS.
3.3. INSTALACION 23

3.3. Instalaci
on de Linux y Windows.
24 CAPITULO 3. INSTALACION
DE LINUX.

3.4. Gestor de arranque.

La instalacion de los dos sistemas operativos se puede llevar a cabo sin
ningun problema. Para ello Linux dispone de GRUB, que es un gestor de
arranque que nos va a permitir, mediante un men u que nos aparecera en el
arranque del ordenador, elegir la carga de Windows o de Linux.
GRUB se cargara en el Master Boot Record (MBR) de nuestro disco duro,
que sera cargado en memoria por la BIOS en el arranque.
En este MBR habitualmente se encuentran los cargadores de los diferentes
sistemas operativos, que una vez cargados en memoria por la BIOS permiten
cargar, tambien en memoria, la parte del sistema operativo que se necesite.
En el MBR vamos a tener un cargador, por lo tanto es conveniente elegir
bien cual queremos para poder realizar la carga del sistema operativo o de
los sistemas operativos que queramos tener instalados en nuestro ordenador.
La idea, para tener los mnimos problemas, es instalar primero Windows
en nuestro ordenador y luego Linux. Por que? Bien, porque si instalamos
primero Linux, GRUB se cargara en el MBR y luego Windows se encargara de
borrarlo para grabar su propio cargador.
Si instalamos Windows primero, al instalar acto seguido Linux, en el MBR
se quedara el GRUB, que nos permitira elegir entre cargar Windows y Linux.
A la hora de instalar Windows, crearemos una particion con la capacidad
que creamos oportuna, y el resto del disco duro lo dejaremos sin utilizar. A
continuacion instalaremos Linux creando para ello las particiones que consid-
eremos oportunas, prestando atencion a la parte en la que se nos da la opcion
de instalar GRUB o no. Obviamente elegiremos que queremos instalarlo, y
lo configuraremos a nuestro gusto. Habitualmente lo que mas se suele modi-
ficar en este punto es el nombre que queremos que aparezca en el men u de
arranque para identificar la carga de cada uno de los operativos.
En este punto cabe destacar que sera interesante utilizar una contrasena
para GRUB, para evitar que facilmente se pueda modificar la carga de los
operativos y por lo tanto incluso poder entrar a ellos.

3.5. Particionamiento.
Cuando instalemos Linux, es un truco interesante no utilizar todo el disco
duro restante, sino dejar un espacio libre en disco para poder realizar una
particion nueva desde Windows (tambien la podramos crear desde Linux por
supuesto). El truco consiste en tener una particion en la que, escribamos lo
que escribamos, pueda ser leda y modificada por ambos sistemas operativos.
Actualmente Windows NO lee las particiones Linux, salvo que instale-
mos software adicional que s puede hacerlo, pero Linux es capaz de leer
particiones formateadas como vfat o como NTFS.
Captulo 4

Reconocimiento de hardware.

25
26 CAPITULO 4. RECONOCIMIENTO DE HARDWARE.

La informacion que tiene el sistema operativo acerca del hardware instala-

do en nuestro ordenador esta basicamente ubicada en el directorio /proc que
es un claro desconocido para la mayora de los administradores de sistemas.
El sistema proc presenta el estado actual del kernel, y es, podramos decir,
un sistema de archivos virtual, cambiante permanentemente no facilmente
modificable y cuya modificacion puede implicar un colapso inmediato del
sistema si se hace incorrectamente.
Cuando queramos obtener informacion del hardware de nuestro sistema,
basicamente lo que tendremos que hacer es consultar (mediante el comando
cat por ejemplo) los archivos contenidos en esta estructura, o bien utilizar
herramientas graficas o comandos que traten esta informacion y nos la pre-
senten en pantalla de forma clara.

4.1. Sistema proc.

Archivos interesantes que nos podemos encontrar en el directorio /proc
son:

4.1.1. vmstat
.
Que muestra estadsticas detalladas de la memoria virtual, como por
ejemplo:
El n
umero de paginas sucias, bajo reescritura o inestable:

nr_dirty 1550
nr_writeback 0
nr_unstable 0

Paginas libres:

pgfree 110549163

y as un largo etcetera que nos da informacion muy apreciada cuando nece-

sitemos saber si la memoria esta causando alg un tipo de inestabilidad que
suframos en nuestro equipo.

4.1.2. partitions
En este archivo encontraremos la informacion de las distintas particiones
existentes en nuestros discos duros. La informacion sera el nombre de la
particion, los bloques que ocupa y los major number y minor number de las
mismas:
4.1. SISTEMA PROC. 27

major minor #blocks name

8 0 58605120 sda
8 1 20523006 sda1
8 2 1 sda2
8 3 10265535 sda3
8 4 16434495 sda4
8 5 6144831 sda5
8 6 1004031 sda6
8 7 104391 sda7
8 8 4128673 sda8

4.1.3. meminfo
Si mostramos el contenido de este fichero, obtendremos informacion sobre
la memoria de nuestro equipo, como por ejemplo la memoria total del mismo

MemTotal: 481684 kB

Memoria libre:

MemFree: 52600 kB

Swap total:

SwapTotal: 1004020 kB

Swap disponible

SwapFree: 956228 kB

etc.

4.1.4. cpuinfo
En este fichero encontraremos la informacion de las cpus disponibles en
nuestro servidor. Dichas cpus (o nucleos), estaran numerados empezando con
el n
umero 0, pudiendo as identificar cada una de ellas.
Un ejemplo de las primeras lneas de este fichero bien podra ser:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.60GHz

de tal forma que accediendo al contenido de cpuinfo tendremos la informacion

exacta de las caractersticas de nuestras cpus.
28 CAPITULO 4. RECONOCIMIENTO DE HARDWARE.

4.2. Comandos.
Obviamente la informacion que podemos obtener por comandos, aunque
sea la misma que podramos obtener nosotros accediendo a los archivos pre-
viamente comentados, por regla general nos sera de mayor utilidad al estar
mejor estructurada y al tener ciertas herramientas que nos permiten gestionar
esta informacion de forma mas comoda.
Comandos hay muchos, as como herramientas graficas que basicamente
en u
ltima instancia ejecutan comandos presentando la informacion en un for-
mato altamente agradable. De todos los comandos existentes comentaremos
los mas utilizados a la hora de localizar problemas en nuestro equipo:

4.2.1. iostat
Este comando lo encontramos en el paquete sysstat, que muchos sistemas
no tienen instalado por defecto, pero que es conveniente instalar.
iostat nos muestra estadsticas de la cpu as como de entrada y salida
de dispositivos, particiones y sistemas de archivos de red, por lo tanto nos
podemos hacer una buena idea de la potencia de este comando.
Si ejecutamos sin mas el comando iostat, obtendremos una imagen del
estado actual del equipo:

avg-cpu: %user %nice %system %iowait %steal %idle

4,53 0,12 1,11 3,72 0,00 90,52

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

sda 8,25 243,63 83,71 3128500 1074870

no obstante siempre podremos incluir en la ejecucion del comando un inter-

valo, en segundos, de tal forma que nos mostrara esta informacion cada x
segundos que hayamos pedido, por ejemplo:

iostat 1

nos mostrara informacion de la cpu y de los dispositivos cada segundo.

4.2.2. mpstat
Al igual que iostat, este comando se encuentra dentro del u til paquete
sysstat muy utilizado desde el punto de vista de administracion de sistemas.
mpstat nos proporciona la actividad de cada una de las cpus que dispong-
amos, ofreciendonos algo mas de informacion que el comando iostat y pudi-
endo tambien elegir un intervalo de tiempo, de tal forma que a partir de ese
momento cada x segundos se mostrara en pantalla las estadsticas de las
cpus.
4.2. COMANDOS. 29

4.2.3. vmstat
Es un comando que nos muestra estadsticas de la memoria virtual. Po-
dramos decir que basicamente es una salida ordenada del contenido de
/proc/meminfo pudiendo ademas elegir un intervalo de tiempo

vmstat 1

para que cada segundo (siguiendo el ejemplo especificado), podamos obtener

informacion actualizada. Obviamente podremos elegir el intervalo de tiempo
que mas se ajuste a nuestras necesidades.

4.2.4. top
top es un comando ampliamente utilizado por los administradores de
sistemas y existente en practicamente todos los sistemas operativos Linux y
UNIX.
Este comando nos muestra en pantalla la situacion actual de los proce-
sos del sistema, pudiendo cambiar el intervalo de tiempo para que cada x
segundos nos muestre esta informacion actualizada.
Teniendo en cuenta que hoy por hoy la mayora de los ordenadores per-
sonales que se venden ya incluyen procesadores con varios n ucleos, una de
las opciones mas interesantes de este comando es 1
Si cuando hemos invocado top, pulsamos 1, encontraremos que la infor-
macion que encontrabamos en la zona superior que era un resumen de todas
las cpus existentes, se despliega para dar informacion pormenorizada de todas
y cada una de las cpus existentes

top - 17:27:51 up 153 days, 3:06, 4 users,

load average: 1.00, 1.00, 1.02
Tasks: 90 total, 2 running, 88 sleeping,
0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id,
0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id,
0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 100.0% us, 0.0% sy, 0.0% ni, 0.0% id,
0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id,
0.0% wa, 0.0% hi, 0.0% si
Mem: 2074672k total, 2019472k used,
55200k free, 75196k buffers
Swap: 4096564k total, 3360k used, 4093204k free,
1679804k cached
30 CAPITULO 4. RECONOCIMIENTO DE HARDWARE.

4.2.5. lspci
lspci es un comando no muy conocido por administradores noveles, y sin
embargo es un poderoso comando que nos muestra la informacion de los
dispositivos pci disponibles en nuestro equipo, con la consiguiente facilidad
para poder configurarlos gracias a esta informacion obtenida.
Al ejecutar el comando sin ninguna opcion, obtendremos un resumen de
los dispositivos encontrados, por ejemplo una de las entradas bien podra ser:

02:07.0 FireWire (IEEE 1394): Texas Instruments

TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)

las dos opciones mas utilizadas con este comando son -v y -x, que sirven
respectivamente para obtener informacion mas detallada y un volcado hex-
adecimal del espacio de configuracion.
Ademas podemos utilizar varias veces -v, concretamente podramos teclear:

lspci -v
lspci -vv
lspci -vvv

obteniendo en cada caso mayor informacion, por ejemplo la u ltima ejecu-

cion nos dara el siguiente resultado para el ejemplo que habamos utilizado
anteriormente:

02:07.0 FireWire (IEEE 1394): Texas Instruments

TSB43AB21 IEEE-1394a-2000 Controller
(PHY/Link) (prog-if 10 [OHCI])
Subsystem: Hewlett-Packard
Company Unknown device 3084
Control: I/O- Mem+ BusMaster+ SpecCycle-
MemWINV+ VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B-
ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 1000ns max),
Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e0205000 (32-bit,
non-prefetchable) [size=2K]
Region 1: Memory at e0200000 (32-bit,
non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+
AuxCurrent=0mA PME(D0+,D1+,D2+,
4.2. COMANDOS. 31

D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0
DScale=0 PME+

Con respecto a -x, podremos ejecutar:

lspci -x
lspci -xxx
lspci -xxxx

4.2.6. lsusb
Este comando lista los dispositivos USB que tenemos en nuestro sistema,
pudiendo utilizar la opcion -v para obtener mayor informacion.
La salida del comando bien podra ser:

Bus 004 Device 001: ID 0000:0000

Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

obteniendo una cuantiosa informacion al utilizar la opcion -v

4.2.7. fdisk
Si bien esta herramienta se suele utilizar la mayora de las veces solo
para realizar modificaciones de la tabla de particion, ejecutando sin mas el
comando y eligiendo diferentes opciones dentro del prompt que se nos ofrece,
puede ser utilizada para obtener informacion de los discos que disponemos
mediante la utilizacion de la opcion -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes

255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

/dev/sda1* 1 2555 20523006 7 HPFS/NTFS
/dev/sda2 2556 3972 11382052+ f W95 Extd (LBA)
/dev/sda3 3973 5250 10265535 c W95 FAT32 (LBA)
/dev/sda4 5251 7296 16434495 c W95 FAT32 (LBA)
/dev/sda5 2556 3320 6144831 83 Linux
/dev/sda6 3321 3445 1004031 82 Linux swap / Solaris
/dev/sda7* 3446 3458 104391 83 Linux
/dev/sda8 3459 3972 4128673+ 83 Linux
32 CAPITULO 4. RECONOCIMIENTO DE HARDWARE.

de tal forma que podemos obtener facilmente y sin posibilidad de da nar

nuestro disco informacion sobre el mismo.
Ejecutandolo sin especificar absolutamente nada (solo utilizando la opcion
-l), nos mostrara informacion de todos los discos duros de nuestro sistema.
Para obtener informacion de un disco en concreto, tendremos que especifi-
carlo:

fdisk -l /dev/hda
Captulo 5

Directorios en Linux.

33
34 CAPITULO 5. DIRECTORIOS EN LINUX.

Cuando utilizamos Linux, no tenemos una especial obligacion en la uti-

lizacion de un cierto directorio u otro para la ubicacion de nuestros trabajos.
En cualquier directorio, siempre que tengamos permisos para poder guardar
ficheros en el, podemos almacenar nuestra informacion.
Si bien es cierto esto que acabamos de comentar, tambien lo es que Linux
mantiene cierta jerarqua, cierta organizacion de los diferentes directorios.
Respetar esta organizacion muchas veces es obligatorio, pues por ejemplo
ciertos ficheros de configuracion el sistema los buscara en determinados di-
rectorios y en ning un otro sitio (salvo que realicemos un trabajo extra para
cambiar el Sistema Operativo), pero otras muchas veces simplemente se res-
peta esta distribucion por el mero hecho de la buena organizacion.
Si nosotros guardamos los ficheros de usuarios en subdirectorios de /home,
cualquier administrador que nos tenga que ayudar en un momento determina-
do no tendra mayor problema al buscar esta informacion. Si hubieramos deci-
dido utilizar /casa, probablemente la persona que nos ayude empleara tiempo
en darse cuenta de este cambio y por lo tanto perderemos efectividad.
De tal forma entonces comprenderemos que hay ciertos directorios en los
que encontraremos basicamente siempre cierta informacion, sobre todo cuan-
do nos referimos a ficheros de configuracion del Sistema, archivos importantes
del kernel y libreras.

5.1. /etc
En el directorio /etc nos encontramos los ficheros de configuracion del
sistema operativo Linux, de tal forma que cualquier cambio de configuracion
que queramos hacer, si no sabemos donde encontrar el fichero para guardar
este cambio, deberamos buscar primero en /etc antes que en ning un otro
sitio.
En este directorio nos podemos encontrar ficheros de configuracion de
libreras, de utilizacion de servicios de red, etc. Ademas podremos encontrar
subdirectorios que incluyen a su vez ficheros de configuracion.
Algunos de los ficheros de configuracion y directorios mas importantes
son:

5.1.1. aliases
Guarda una lista de los alias de correo electronico que tienen los diferentes
usuarios validos en el sistema, es decir, nos encontraremos ante un fichero
organizado en dos columnas, la primera haciendo referencia a un usuario en
concreto y la segunda a una direccion de correo electronico.
Cada vez que el usuario reciba correo electronico en la maquina, este se
redireccionara a la cuenta que tengamos asignada.
Un ejemplo podra ser:

root: administrador.ccc@uam.es
5.1. /ETC 35

Fijemonos que despues del login encontramos el caracter dos puntos, y a

continuacion una cuenta de correo electronico valida.
Decimos valida pues si no todo el correo electronico que se mande a este
usuario no se podra llevar a su destino.
Si en este fichero no esta definido un usuario, entonces todo el correo
electronico que le llegue sera guardado en su cuenta local en el sistema.
Debemos tener cuidado especial en no crear ning un bucle, es decir, una
configuracion:

pablo: root
root: pablo

es decir, el correo electronico del usuario pablo se enva al usuario root, y el

del usuario root se enva al usuario pablo.
Si bien podemos pensar que es imposible tener esta equivocacion, hay
que tener en cuenta que un fichero aliases puede llegar a contener muchas
entradas, de tal forma que podramos tener un descuido de este tipo.
Para que los cambios realizados a este fichero tomen efecto deberemos
teclear el comando newaliases

5.1.2. at.deny y cron.deny

Estos dos ficheros contendran una lista de usuarios (ordenados en filas),
a los que no permitiremos la utilizacion de at y cron respectivamente.
Los ficheros at.allow y cron.allow tienen el significado contrario, es decir,
contienen una lista de los usuarios a los que se les permite utilizar at y cron
respectivamente.
Una forma de configurar estos servicios mediante la utilizacion de estos
ficheros es escribir la lista de los usuarios a los que permitimos utilizar at y
cron, de tal forma que aunque no escribamos nada en at.deny y cron.deny,
solo los que esten en at.allow y cron.allow podran utilizar at y cron respec-
tivamente.
En este sentido por tanto nada mas instalar nuestro sistema tiene sentido
que a nadamos el login de root a at.allow y cron.allow, de tal forma que a
partir de ese momento solo root podra utilizar estas utilidades del sistema,
y conforme otros usuarios tengan que utilizarlas se les ira a nadiendo.

5.1.3. cron.hourly, cron.daily, cron.weekly y cron.monthly

Estos directorios contienen una serie de ejecutables, de tal forma que estos
se ejecutaran cada hora, cada da, cada semana o cada mes respectivamente.
Los ejecutables que contengan estos directorios bien pueden ser shell
scripts (la mayora), pero tambien pueden ser binarios, y por supuesto po-
dremos localizar enlaces simbolicos que apunten a ejecutables situados en
otra zona del arbol de directorios del sistema.
36 CAPITULO 5. DIRECTORIOS EN LINUX.

La forma de mantener tareas programadas en este sentido tiene sus de-

tractores y tambien sus amantes. En contra podramos decir que a priori
(aunque lo podemos descubrir en los ficheros de configuracion correspondi-
ente), no sabemos exactamente en que minuto de cada hora se ejecutaran los
ejecutables contenidos en cron.hourly, a que hora los contenidos en cron.daily,
etc. En este sentido la programacion mediante cron directamente es mucho
mas directa. Ademas tenemos muy restringida la programacion, es decir, si
queremos afinar un poco la programacion (por ejemplo que se ejecute todos
los domingos a las doce y un minuto de la noche), nos sera imposible utilizar
esta forma de programar tareas.
A favor tenemos la sencillez, pues simplemente realizando un enlace simboli-
co al ejecutable que acabamos de instalar en nuestro sistema y que queremos
que se ejecute un numero determinado de veces (pero nos da un poco igual
en que momento en concreto) tendremos solucionado nuestro requerimiento.
Por ejemplo con esta forma de programar tareas podremos ejecutar tareas
de busqueda de troyanos o de control de logs, que se deben hacer todos los das
pero que no es muchas veces imprescindible que sea a una hora en concreto.

5.1.4. csh.login y csh.cshrc

Son dos ficheros que leera la shell csh cuando sea llamada, de tal forma
que ejecutara lo que se le especifique en estos ficheros, cargando por ejemplo
valores en diferentes variables.
El fin de estos ficheros por tanto es que los usuarios tengan un entorno
homogeneo y es labor del administrador modificarlos consecuentemente con el
fin de que los usuarios tengan las mnimas preocupaciones a la hora de crearse
un perfil correcto de ejecucion que funcione perfectamente en la maquina
deseada.
Los administradores por tanto tendran que cargar las variables correspon-
dientes que vayan a ser necesarias. Por ejemplo tras la instalacion de un pro-
grama de calculo, es posible que para que funcione correctamente los usuarios
tengan que cargar alguna variable de alguna forma en concreto. Cargando
estos valores en este archivo, ningun usuario tendra que hacer absolutamente
nada en su cuenta.

5.1.5. exports
Es el fichero donde tendremos que escribir los recursos que queremos
exportar va NFS, as como las propiedades de exportacion.
Este fichero permanecera vaco siempre y cuando no habilitemos un servi-
dor NFS en nuestra maquina, y deberemos tener extremo cuidado en su con-
figuracion si habilitamos el servidor.
Un ejemplo bien podra ser:

/home maquina.dominio.es(rw)
5.1. /ETC 37

fijandonos especialmente en los espacios que inclumos. Entre el nombre del

recurso a exportar, y el nombre de la maquina (o conjunto de maquinas), que
podran acceder al recurso, debe haber un espacio, no as entre el nombre de
las maquinas y las propiedades de exportacion (includas entre parentesis).

5.1.6. fstab
En este fichero incluiremos los sistemas de archivos que vamos a montar
en nuestro equipo.
Estos no tienen que ser montados automaticamente en el arranque ni
mucho menos, sino que podemos tener sus lneas correspondientes para hacer
mas sencillo su montaje cuando sea necesario.
Este fichero se compone de diferentes lneas (una para cada sistema de
archivos que queramos montar), y cada una de ellas esta organizada en seis
columnas.
En la primera columna escribiremos el dispositivo objetivo del montaje,
como por ejemplo /dev/sda1 si queremos especificar el montaje de la primera
particion del primer disco del sistema.
La segunda columna hace referencia al directorio donde se montara esta
particion, por ejemplo /home si queremos que la informacion del dispositivo
sea accesible desde este directorio.
En la siguiente columna especificaremos el sistema de archivos que vamos
a utilizar. Que podamos montar un sistema de archivos o no depende de si
esta habilitado en el kernel, es decir, si este sabe trabajar con este sistema
de archivos. Los mas habituales son ext4 y iso9660 (sistemas de archivos de
linux y de los CDs/DVDs respecivamente), si bien podramos especificar vfat
o ntfs para particiones Windows, etc.
En la cuarta columna indicaremos las opciones que se incluiran a la hora
de montar este dispositivo. Muchas veces nos encontraremos defaults, ya que
as se utilizaran unas opciones que existen por defecto sin necesidad de es-
cribirlas todas, pero podremos especificar todas las opciones que queramos,
por ejemplo rw si queremos que sea un sistema de lectura y escritura, user
si queremos que cualquier usuario lo pueda montar, noauto si no queremos
que se monte automaticamente (con la opcion -a de mount), etc.
La pen ultima columna hace referencia a la utilizacion del comando dump.
Este comando sirve para realizar copias de seguridad y puede ser utilizado
de forma general para realizar un backup global del sistema. Si en la quinta
columna de un sistema de archivos determinado aparece el n umero 1, dump
podra realizar el backup global tambien sobre este sistema de archivos, pero
si aparece un 0 no podra hacerse el backup de esta manera.
La sexta y u ltima columna es utilizada por el comando fsck para realizar
un chequeo de este sistema de archivos siempre que no hayamos escrito el
numero 0. En los casos en los que hayamos escrito el n umero 1 (siempre en
el sistema de archivos / ) o 2 (en cualquier otro sistema de archivos), se
comprobara mediante fsck cuando sea montado.
38 CAPITULO 5. DIRECTORIOS EN LINUX.

5.1.7. group
En este fichero tendremos una lista con todos los grupos creados en nuesto
sistema.
Se compone de una lnea por cada grupo, en cada una de ellas podremos
encontrar el nombre del grupo, la contase na del mismo, el numero identifi-
cador del grupo (gid) y la lista de los usuarios que pertenecen a este grupo.
Todos estos campos se separan con el caracter dos puntos.
Es poco habitual que un grupo tenga contrase na, si bien podemos definirla
sin mayor problema.
Este fichero debe tener permisos de lectura para todos los usuarios del
sistema, ya que si un usuario al hacer login en el sistema, no puede acceder
a esta informacion, no podra acceder al sistema.

5.1.8. gshadow
Es el equivalente al fichero shadow pero para los grupos, disponible en
sistemas donde tengamos habilitadas las contrase nas shadow. Este sistema
aumenta la seguridad del operativo, ya que las contrase nas se separan de los
ficheros que tienen que ser accesibles a todos los usuarios del sistema y se
alojan en ficheros accesibles solo a root.
Es posible realizar esta separacion ya que el proceso de autentificacion
lo lleva a cabo el superusuario, por lo tanto solo este usuario necesita tener
acceso al fichero, mientras que el resto de los usuarios simplemente necesita
saber la informacion de su login, informacion que encontraran sin mayor
problema en los ficheros correspondientes y con permisos para que se pueda
llevar a cabo esta lectura.
Hasta la aparicion de shadow, en la mayora de los sistemas encontrabamos
las contrasenas, cifradas, en ficheros accesibles, de tal forma que cualquier
usuario poda hacerse con estos ficheros e intentar por tanto el crackeo de las
mismas.

5.1.9. host.conf
En este fichero estableceremos el orden en el que se consultara la resolu-
cion de nombres.
Cuando intentamos realizar una conexion a un equipo, necesitamos saber
su IP. Si lo que tenemos es su nombre, debe ser resuelto. Este proceso se
puede hacer mediante ficheros de configuracion en el propio sistema mediante
la consulta en un servidor DNS u otras opciones menos utilizadas.
En este fichero estableceremos por tanto el orden en que realizaremos es-
ta consulta, siendo normalmente la primera opcion la consulta local en los
ficheros del sistema habilitados, y como segunda opcion la consulta en servi-
dores de nombres, si bien puede ser cambiado este orden o incluso modificado
para incluir otras opciones (por ejemplo utilizando servicio NIS).
Un ejemplo tpico de este fichero es:
5.1. /ETC 39

order hosts,bind

donde hosts indica ficheros locales y bind consulta a un servidor de nombres.

5.1.10. hosts
Fichero que contiene relaciones IP/nombre para que el sistema operativo
pueda resolver direcciones sin necesidad de hacer consultas a los servidores
de nombre.
Este fichero esta estructurado por lneas, de tal forma que en cada una de
ellas nos encontraremos una direccion IP, seguida de su nombre correspon-
diente y a continuacion uno o varios alias para esta direccion IP. De esta
forma podremos realizar una conexion a una IP en concreto utilizando su
nombre equivalente o cualquier alias que hayamos elegido, siempre y cuando
este fichero se consulte en primera instancia (ver fichero host.conf).
Si tenemos un error en la configuracion de este fichero tenemos que tener
en cuenta que las conexiones que realicemos pueden no llevarse a cabo o
realizarse de forma erronea.
Un ejemplo podra ser:

64.233.183.99 www.google.com buscador

de tal forma que podremos acceder a la pagina web de Google escribiendo en

nuestro navegador cualquiera de estas tres opciones:

http://64.233.183.99
http://www.google.com
http://buscador

5.1.11. hosts.allow y hosts.deny

Son los ficheros de configuracion de la herramienta tcpwrapper.
Esta herramienta nos permite realizar un control de acceso a los servi-
cios de nuestra maquina que ofrezcamos mediante el protocolo tcp y esten
habilitados. tcpwrapper comprobara la IP del equipo que intenta realizar
la conexion y, atendiendo a la configuracion de estos ficheros, permitira el
acceso o no.
Una configuracion por defecto muy utilizada es escribir en el fichero
hosts.deny:

ALL:ALL

que impedira cualquier conexion, configurando entonces el fichero hosts.allow

servicio:IP

para permitir que el ordenador con ip IP acceda al servicio servicio.

40 CAPITULO 5. DIRECTORIOS EN LINUX.

5.1.12. inittab
En este fichero se indican que procesos son ejecutados en el arranque
as como durante la operacion normal del sistema operativo.
Si bien mucha de la informacion contenida en este fichero permanece
invariable desde la instalacion del sistema operativo, muchas veces los ad-
ministradores modifican la lnea donde se indica que nivel de ejecucion se al-
canzara tras arrancar la maquina, es decir, que nivel de ejecucion tendremos
por defecto

id:5:initdefault:

en este ejemplo tendremos que el nivel de ejecucion por defecto es el cinco, si

bien podramos cambiarlo a 3 en una maquina de calculo, para evitar que se
arranque el entorno grafico con el consiguiente consumo de cpu y memoria
RAM que conlleva.
La sintaxis de las lneas includas en este fichero consiste en cuatro campos
separados por el caracter dos puntos. El primer campo es un identificador
(de cuatro caracteres maximos, o dos para versiones de sysvinit compiladas
con libc5 < 5.2.18). Este identificador tiene que ser u nico en todo el archivo.
El segundo campo identifica el nivel de ejecucion donde se aplicara esta
lnea. En este campo podremos tener un solo nivel de ejecucion, varios o
ninguno: en el caso de que queramos ejecutar algo solo al alcanzar un nivel
de ejecucion, cuando alcancemos varios o cuando arranquemos la maquina
respectivamente.
El cuarto campo indica el proceso, el comando que se ejecutara.
Finalmente el tercer campo indica la accion de lo que queremos realizar.
El n umero de acciones es finito, siendo su significado:
respawn. El proceso se rearrancara tan pronto se termine.
wait. El proceso se ejecutara cuando se acceda al nivel de ejecucion ini-
dicado e init esperara a su ejecucion.
once. El proceso se ejecutara una vez cuando se alcance el nivel de ejecu-
cion indicado.
boot. El proceso se ejecutara en el arranque. El campo de los niveles de
ejecucion sera ignorado por tanto.
bootwait. El proceso se ejecutara en el arranque, pero en esta ocasion
init esperara hasta que se lleve a cabo. El campo de los niveles de ejecucion
tambien sera ignorado en este caso.
off. No tiene efecto.
ondemand. Se ejecutara el proceso cuando se llame al nivel de ejecucion
ondemand. Estos niveles son el a, b y c, y cuando se llaman no conllevan un
cambio en el nivel de ejecucion.
initdefault. Indica el nivel de ejecucion al que se accedera cuando la
maquina arranque. Si no hay indicacion al respecto, el sistema lo pregun-
tara interactivamente en consola.
5.1. /ETC 41

sysinit. El proceso se ejecutara en el arranque antes de cualquier proceso

con accion boot o bootwait. El campo de los niveles de ejecucion es ignorado
por tanto.
powerwait. El proceso se ejecutara cuando init recibe una se nal de falta de
corriente electrica (mandada por un sistema de alimentacion ininterrumpida
por ejemplo). init esperara hasta que se ejecute el proceso indicado.
powerfail. Se ejecuta el proceso igual que con powerwait, pero en este caso
init no esperara a su final.
powerokwait. Se ejecutara el proceso cuando init reciba una se nal que
indique que se ha restablecido el proceso de alimentacion electrica. init es-
perara a su ejecucion.
powerfailnow. Si el sistema de alimentacion ininterrumpida conectado al
sistema es capaz de informar a init que su autonoma esta a punto de termi-
nar, se ejecutara el proceso que se indique con esta accion.
ctrlaltdel. Se ejecutara el proceso cuando se reciba la secuencia Ctrl+Alt+Spr.
kbrequest. Si hemos asignado una combinacion de letras a la accion Key-
boardSignal, cuando se utilice esta combinacion se detectara y se ejecutara el
proceso asignado a esta accion.

5.1.13. issue
Es un fichero de texto que se mostrara en pantalla antes del indicador
de entrada en el sistema. Podremos modificar su contenido para mostrar
mensajes institucionales o con informacion al usuario.

5.1.14. issue.net
Es equivalente a issue, pero su contenido se mostrara en las conexiones
telnet que se hagan contra nuestra maquina.
Es conveniente sobre todo en este caso no mostrar informacion sensible
de nuestra maquina en este fichero. Hay que tener en cuenta que su contenido
se mostrara antes de que se realice un login correcto en nuestro sistema, de
tal forma que si dejamos el contenido por defecto (habitualmente la version
de sistema operativo que se esta ejecutando), estamos dando una valiosa
informacion a un hacker que quiera acceder a nuestro equipo, pues a partir de
ese momento se centrara en las vulnerabilidades que pueda haber en nuestra
version de operativo en vez de intentar cualquier vulnerabilidad conocida.

5.1.15. ld.so.conf
En es fichero encontraremos la configuracion utilizada por el cargador /
enlazador ld.so (o ld-linux.so*), que buscan y cargan las libreras compartidas
que necesita un programa que se necesite ejecutar.
En este fichero por tanto escribiremos la ubicacion (directorio), donde se
encuentran las libreras compartidas que tengamos en nuestro sistema.
42 CAPITULO 5. DIRECTORIOS EN LINUX.

Cada vez por tanto que instalemos libreras compartidas en nuestro sis-
tema, que entendamos que necesiten ser cargadas en alg un momento, es-
cribiremos su directorio en este archivo y ejecutaremos el comando ldconfig
para que el cambio tenga efecto.
Actualmente se utiliza una sintaxis un tanto distinta, pero totalmente
equivalente, para tener mayor orden en este sentido. En el fichero ld.so.conf
lo que se hace es incluir la lnea:

include ld.so.conf.d/*.conf

de tal forma que al ejecutar ldconfig, al leer este fichero obligaremos a que se
lea cualquier fichero, con extension .conf, existente en el directorio
/etc/ld.so.conf.d
Por lo tanto cada vez que instalemos una librera compartida en nue-
stro sistema, crearemos un fichero .conf en el directorio /etc/ld.so.conf.d que
contenga el directorio donde se encuentra la (o las) librera compartida.
En este sentido la configuracion es mucho mas sencilla, pues en vez de
tener un archivo u nico con muchas entradas (muchas veces desordenadas
y complicadas de comprobar), tendremos varios archivos con nombres car-
actersticos (deben acabar .conf), que cumpliran la misma funcion cara al
sistema pero que seran mucho mas faciles de ordenar para el administrador.

5.1.16. login.defs
Define la configuracion que utilizara shadow en la creacion de logins.
En este fichero indicaremos las caractersticas comunes que tendran las
cuentas que creemos en nuestro sistema, como puede ser la mascara por
defecto, la caducidad del login, la creacion o no del directorio home, etc.

5.1.17. logrotate.conf
Configura la accion de logrotate. Este comando puede rotar los logs del
sistema, comprimirlos e inclusos mandarlos por correo electronico, seg un lo
configuremos en su fichero de configuracion.
Hay que tener en cuenta que si no realizamos ninguna modificacion de
los ficheros de log, estos al cabo del tiempo se volveran inmanejables debido
a su gran tama no.
En el fichero logrotate.conf configuraremos por tanto si estos ficheros
tienen que ser rotados, si tienen que ser comprimidos, etc.
Cuando decimos rotar, lo que queremos indicar es que el fichero de log
cambiara de nombre, por ejemplo se llamara log.1, el fichero que se llama-
ra log.1 se llamara log.2 y as consecutivamente. El fichero mas antiguo se
eliminara (por ejemplo), y as tendremos un sistema en el que el fichero de
log correspondiente no alcanza un tama no que le haga inmanejable y donde
tendremos un n umero finito de archivos de log historicos.
Una configuracion habitual de este fichero de configuracion puede ser:
5.1. /ETC 43

weekly
rotate 4
create
compress

donde de forma semanal (weekly) se rotaran los logs, guardando cuatro se-
manas de antig uedad (rotate 4 ). Como cambiamos de nombre los ficheros de
log al rotarlos (les a
nadiremos la extension .1, .2, etc), se creara un nuevo
fichero de log sin esta extension para guardar los logs actuales (create), y se
comprimiran los ficheros de logs (compress).

5.1.18. modprobe.conf
Este fichero indica la configuracion necesaria para la herramienta mod-
probe. Este comando carga en memoria modulos del kernel, pero incluyendo
las dependencias si es que las tiene, a diferencia del comando insmod.
Estas dependencias son incluidas en este fichero de configuracion, as como
en ficheros que podremos incluir en el directorio
/etc/modprobe.d
Ademas de dependencias, en este fichero podremos incluir alias, es decir,
nombres distintos para los modulos que deseemos, as como caractersticas
extraordinarias para la carga de modulos.
Esta ultima utilidad, la de incluir caractersticas extra de carga de modu-
los en memoria, tenemos que configurarlas con mucho cuidado, pues una
carga de un modulo de forma incorrecta puede producir errores en el fun-
cionamiento del equipo. Habitualmente es el fabricante del dispositivo al
que hace referencia el modulo, o el desarrollador del modulo quien indica
que variables se pueden utilizar en la carga del modulo para modificar su
funcionamiento. El realizar nosotros cualquier cambio sin estar seguros de su
finalidad ultima puede acarrear, como hemos indicado, una inestabilidad de
la utilidad a la que haga referencia el modulo as como del sistema.

5.1.19. motd
motd es el acronimo de Message Of The Day, es decir, en este fichero
podremos escribir la informacion que nuestros usuarios lean cuando hagan
login, y por lo tanto es una buena manera de mantener informados a los
usuarios de las noticias que creamos interesantes para ellos.

5.1.20. mtab
Es un fichero donde esta includa la informacion de los dispositivos mon-
tados en nuestro sistema.
Es un fichero que en un principio un administrador no debe modificar en
ning
un momento, pues es el sistema el que lo modifica cada vez que se monte
44 CAPITULO 5. DIRECTORIOS EN LINUX.

o desmonte un dispositivo, y cualquier modificacion puede llevar consigo un

mal funcionamiento del sistema por incongruencia entre lo que se ha montado
y lo que el sistema cree que tiene montado (el contenido de este fichero).
Algunas veces es necesario modificar el fichero, y normalmente es cuan-
do hay algun problema grave con alguno de los dispositivos montados. Por
ejemplo si accedemos a un dispositivo mediante NFS, y en un momento dado
perdemos la conexion (perdida de conectividad por ejemplo), es posible que
ciertas caractersticas de nuestro sistema no funcionen correctamente (por
ejemplo el comando df podra colgar una terminal al ser ejecutado, pues no
podra acceder a la informacion del recurso importado). Un metodo (quizas
agresivo), que nos puede permitir recuperar cierto control en el sistema (pero
que tambien puede hacerle inestable), es eliminar la lnea de este fichero que
este provocando la inestabilidad. En este momento el sistema creera que no
tiene montado este dispositivo y por tanto los errores que estuvieramos te-
niendo dejaran de manifestarse.

5.1.21. passwd
Es el fichero donde se encuentra las caractersticas de los login validos
en nuestro sistema. Este fichero esta organizado por filas, cada una de ellas
conteniendo la informacion de un login en concreto.
La organizacion de las filas viene indicada por campos separados por el
caracter dos puntos. El numero de campos es siempre siete.
El primer campo siempre es el login del usuario. A continuacion ten-
dremos la contrase na encriptada (tendremos el caracter x en el caso de que
las contrasenas encriptadas no esten en este fichero sino en el fichero shadow).
El tercer campo indica el n umero identificador del usuario (uid). Seguida-
mente el cuarto campo indica el n umero identificador del grupo principal del
usuario. A continuacion, en el quinto campo, obtendremos una descripcion
del login (que podremos dejar en blanco si as lo deseamos). El sexto campo
es el directorio home del usuario. El septimo y u ltimo campo indica la shell
por defecto del usuario.
Este fichero es imprescindible en el sistema. Cualquier error en el mis-
mo provocara la imposibilidad de login del usuario afectado, y por lo tanto
su ausencia provocara la imposibilidad de ning un usuario pueda acceder al
sistema (incluido el superusuario).
Como contiene informacion vital para los usuarios, estos deben tener per-
miso de lectura sobre el mismo.

5.1.22. profile
Su cometido es el al del fichero csh.login, pero para los usuarios de shell
bash.
5.1. /ETC 45

5.1.23. rc
Es un script responsable de arrancar/parar servicios cuando un nivel de
ejecucion cambia.
Este script no debe ser modificado salvo que sepamos exactamente lo
que estamos haciendo, pues un mal funcionamiento del mismo hara que los
cambios de nivel de ejecucion se realizaran erroneamente.

5.1.24. rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d

Cada uno de los directorios que consultara el script rc cuando cambiemos
al nivel de ejecucion al que haga referencia su n umero.
Es decir, si cambiamos al nivel de ejecucion 2, el script rc consultara el
directorio rc2.d y ejecutara (por orden alfabetico), todos los scripts que haya
en este directorio (habitualmente enlaces simbolicos que apuntan a scripts
ubicados en /etc/init.d o en cualquier otra parte accesible del sistema). Esta
ejecucion sera acompa nada con el argumento start si el nombre del fichero
empieza por S, o con stop si empieza por K.
Como hemos dicho que la ejecucion sera en orden alfabetico, primero
se ejecutaran todos los ficheros que empiecen con K, seguidos de los que
empiecen por S.

5.1.25. rc.local
Es un script que se ejecutara tras el resto de los scripts init, de arranque
del sistema, de tal forma que podremos escribir en el ejecutables (o scripts)
que queramos se ejecuten, independientemente del nivel de ejecucion alcan-
zado.

5.1.26. rc.sysinit
Este script se ejecutara en el arranque, y permite por ejemplo cargar las
especificaciones de la red, de usb, etc.
Cuando arrancamos el ordenador, el n ucleo ejecuta init. Este comando
buscara el fichero rc.sysinit y ejecutara su contenido. A continuacion se eje-
cutara, si existe, el fichero rc.serial. Acto seguido se ejecutara los guiones
del nivel de ejecucion por defecto (establecido en inittab) y finalmente se
ejecutara rc.local

5.1.27. resolv.conf
Fundamentalmente este fichero contiene la lista de servidores de nom-
bre que consultara el sistema cuando tenga que realizar una resolucion de
nombres gracias a un servidor externo.
La sintaxis es:
46 CAPITULO 5. DIRECTORIOS EN LINUX.

nameserver IP
donde IP es el n umero ip del servidor de nombre.
Podremos escribir tantas lneas como queramos, y el orden de consulta
sera el orden de las lneas, es decir, primero se realizara la consulta al servidor
de nombres que aparezca en la primera lnea, en el caso de que no se produzca
correctamente la consulta se utilizara el siguiente, etc.
Ademas de especificar la lista de servidores de nombres que consultara el
sistema, tambien podremos especificar nuestro dominio
domain universidad.es
el orden de b
usqueda
search uam.es
y podremos especificar tambien opciones de b usqueda.
En cuanto al orden de busqueda indicar que se utilizara cuanto intentemos
una conexion utilizando un nombre de equipo incompleto. Por ejemplo si
queremos conectarnos al equipo www.uam.es, si escribimos u nicamente www
el ordenador se dara cuenta de que no hay ning un equipo valido con ese
nombre y entonces intentara buscar el equipo www.uam.es (seg un hemos
indicado con search uam.es). Si encuentra entonces un equipo valido entonces
realizara la conexion. Podremos escribir tantas lneas search como nos sea
necesario, utilizandose por el sistema en orden.
Por supuesto si nuestro equipo, antes de realizar una consulta al servidor
de nombres, busca la resolucion en ficheros locales, si en estos existe un alias
que coincida con el nombre corto que hemos utilizado, se utilizara este y no
el que se obtenga al usar search.

5.1.28. securetty
Es el fichero donde incluiremos las ttys donde root puede hacer login, para
evitar que por ejemplo root pueda realizar una conexion mediante telnet o
en ciertas consolas.

5.1.29. services
Este fichero incluye una lista de los servicios de red de Internet, es decir, en
el tendremos una lista del nombre del servicio, el puerto y protocolo utilizado
y en algunas ocasiones un alias:
http 80/tcp www www-http
http 80/udp www www-http
Todo programa que necesite realizar una conexion podra leer este fichero
para conocer el puerto que debe utilizar. Cualquier error por tanto en la
configuracion del mismo acarreara un error en la conexion. Si intentamos
realizar una conexion y no existe la lnea correspondiente, es posible que esta
no pueda llevarse a cabo.
5.1. /ETC 47

5.1.30. shadow
Es el fichero que contiene las contrase
nas cifradas cuando utilizamos shad-
ow.
En este sentido aumentamos la seguridad del sistema, pues ning un usuario
(salvo root por supuesto), podra leer este fichero (si los permisos del mismo
son correctos), y por tanto no se podra realizar un crackeo de contrase nas,
que s se puede llevar a cabo por un usuario no privilegiado del sistema si
las contrase
nas cifradas se encuentran en el fichero passwd, ya que este debe
tener permisos de lectura para los usuarios (aun no siendo privilegiados).
El que sea posible que el fichero shadow no tenga permisos de lectura
para los usuarios, solo para root, es debido a que el usuario encargado de la
autentificacion en el sistema es root, y por lo tanto ningun usuario necesita
acceder a esta informacion.

5.1.31. shells
Cualquier shell que quiera ser utilizada en el sistema debe estar contenida
en este fichero, organizado en lneas.
Si realizamos la instalacion de una nueva shell en nuestro equipo, esta no
funcionara hasta que la incluyamos en este fichero, modificable solo por root.
As solo podran ser utilizadas, en un principio, las shells autorizadas por
el superusuario, evitando cualquier tipo de acceso anormal en el sistema.

5.1.32. sysconfig
El directorio sysconfig alberga una gran cantidad de ficheros de configu-
racion, donde podremos encontar por ejemplo la configuracion de la red.

5.1.33. sysctl.conf
Este fichero de configuracion, desgraciadamente, es un gran desconocido
entre los administradores de sistema.
La configuracion de este fichero es utilizada por el comando sysctl para
configuraciones opciones del kernel existentes en el directorio /proc/sys
Lo que podemos modificar en este directorio /proc/sys lo podemos saber
ejecutando el comando

sysctl -a

cuya ejecucion nos dara una larga lista de opciones. Modificar cualquiera de
estas opciones cambiara ciertos comportamientos que tiene el kernel, cara al
sistema de archivos, red, etc. de tal forma que hay que tener cierto cuidado en
realizar cambios solo y exclusivamente cuando estemos seguros de no causar
ningun error en el sistema.
48 CAPITULO 5. DIRECTORIOS EN LINUX.

La forma de cambiar estas caractersticas es modificando los archivos

existentes en /proc/sys, que tienen los valores que hemos obtenidos tras la
ejecucion de sysctl -a Esta modificacion la podemos realizar mediante el
comando sysctl:

sysctl -w a.configurar="valor"

o tambien modificando el fichero correspondiente mediante el comando echo

echo "valor" > archivo.a.configurar

Al ser /proc un sistema virtual, cualquier modificacion se perdera en el

siguiente reinicio, por lo tanto si queremos que todas estas modificaciones
se realicen siempre que arranque el sistema operativo, las escribiremos en el
archivo sysctl.conf y por tanto seran modificadas sin nuestra interaccion.
Un ejemplo que podramos poner es desactivar la respuesta al ping, es
decir, que nuestra maquina no respondiera al ping de otra maquina remota.
Esto lo podemos hacer ejecutando:

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

o con el correpondiente comando sysctl.

Para evitar tener que teclear esto cada vez que arranquemos el sistema,
lo que haremos entonces es incluir en el fichero sysctl.conf la siguiente lnea:

net/ipv4/icmp_echo_ignore_all=1

donde podemos observar que la sintaxis cambia un poco: Evitamos la in-

clusion de /proc/sys/ en la ruta del archivo a modificar, y lo que hacemos es
a
nadir el signo igual seguido del valor que queremos incluir en este fichero.

5.1.34. timezone
En este fichero tendremos definida la zona horaria donde nos encontramos.
Habitualmente no se suele modificar este archivo, pues no es habitual
cambiar un ordenador de localizacion geografica, y su configuracion viene
predefinida por la eleccion que hayamos hecho a la hora de instalar el sistema
operativo. No obstante, si lo necesitamos, siempre podremos modificar su
contenido para cambiar nuestra zona horaria.
Una eleccion incorrecta de la zona horaria de nuestro sistema no solo
nos dara problemas por ejemplo en la recepcion/envo de mensajes de correo
electronico (desfasados sus marcas de tiempo debido a esta configuracion),
sino que afectaran al buen funcionamiento del sistema de colas, por ejemplo,
donde integremos el equipo ya que tendra un desfase horario con respecto
al resto de los equipos. Tambien por supuesto podremos tener problemas
al utilizar NFS y NIS, y en general con cualquier servicio que necesite una
correcta sincronizacion horaria.
5.1. /ETC 49

5.1.35. xinetd.d
El directorio xinetd.d contiene una serie de archivos que contienen la
configuracion de diferentes servicios que ofrece el super demonio xinetd
Cada uno de los archivos contenidos en este directorio mantiene la con-
figuracion de un servicio instalado en nuestro equipo, con el que por ejemplo
se podra permitir o evitar la ejecucion de este servicio, controlar el binario
que se debe ejecutar, el tipo de seguridad empleado, etc.
Captulo 6

Scripts de arranque.

51
52 CAPITULO 6. SCRIPTS DE ARRANQUE.

6.1. Configuraci
on y comandos b
asicos.
Los niveles de ejecucion en Linux son los diferentes estados en los que
podemos encontrar un sistema operativo Linux.
Cuando arrancamos un sistema Linux,tenemos la posibilidad de que el
sistema operativo se comporte por ejemplo de forma monousuario, es decir,
que no tengamos que introducir ni siquiera la contrase na del super usuario
ya que arranca directamente en esta cuenta, como pasaba con los sistemas
operativos DOS o Windows95/98/me. Otra forma que podemos tener de
arrancar Linux es que permita que m ultiples usuarios puedan conectarse a
nuestra maquina, y que arranque un entorno grafico en el cual pueda trabajar
de forma muy agradable la persona que se siente delante de este equipo.
Niveles de ejecucion tenemos varios, es mas, podremos incluso crear nues-
tro propio nivel de ejecucion, totalmente personalizado. Por tanto esta forma
de trabajar aumenta la versatilidad que tiene el sistema operativo Linux.
Al ser los niveles de ejecucion totalmente configurables, es posible que al
trabajar en diferentes versiones de Linux veamos diferencias significativas.
En la mayora de las distribuciones de Linux vamos a tener que el nivel
de ejecucion 0 es el de apagado, es decir, si vemos que nuestro equipo esta en
este nivel de ejecucion, inmediatamente tendremos que darnos cuenta de que
esta produciendose el apagado del mismo. Otro nivel de ejecucion que suele
ser el mismo en todas las distribuciones es el n umero 6, que es el nivel de
ejecucion de reinicio, es decir, cuando nuestra maquina pasa a estado de
ejecucion 6 realmente esta reiniciandose.
Llegados a este punto nos damos perfecta cuenta de que un nivel de
ejecucion no es una forma de arrancar el sistema operativo, sino un estado
del mismo. En muchas distribuciones el nivel de ejecucion n umero 5 es el
nivel de ejecucion multiusuario con entorno grafico y es el que se ejecuta por
defecto cuando arranca el equipo. No tenemos que querdarnos entonces en
que el nivel de ejecucion de nuestro equipo es el n umero 5, sino que en ese
justo momento esta en el nivel de ejecucion 5 y podremos cambiar a otro
nivel en el momento que deseemos.
Tambien es habitual que en las diferentes distribuciones Linux el nivel
de ejecucion n umero 3 sea el de multiusuario sin entorno grafico. Si bien es
posible que en alg un sistema Linux este nivel de ejecucion no sea el numero
3, normalmente nos encontraremos este nivel de ejecucion ya que es muy
habitual que las maquinas permanezcan la mayora del tiempo en el. Esto
suele ocurrir en maquinas destinadas al calculo, donde es superfluo un entorno
grafico ya que suelen ser administradas en remoto y el tener este entorno
aumenta la necesidad en disco pero sobre todo la cantidad de memoria RAM
necesaria para las operaciones habituales.
Ya que habamos hablado del nivel de ejecucion monousuario, comentar
que en la mayora de las distribuciones suele ser el n umero 1, es decir, estar
en nivel de ejecucion n umero 1 implica necesariamente la imposibilidad de
poder conectarnos a esta maquina con mas de un usuario, y ademas este
 Y COMANDOS BASICOS.
6.1. CONFIGURACION 53

(root) debe conectarse directamente en consola.

El nivel de ejecucion n umero 2 es multiusuario sin entorno grafico y sin
NFS en muchas distribuciones de Linux, es decir, es como el nivel de ejecucion
numero 3 pero sin la posibilidad de importar/exportar recursos de disco a
traves de la red. Este nivel de ejecucion se suele utilizar si tenemos alg un
problema con la red, si bien queremos mantener la caracterstica de entorno
multiusuario en nuestro equipo.
Finalmente comentar que el nivel de de ejecucion n umero 4 suele estar
reservado para que el administrador del equipo lo adapte a sus propias necesi-
dades, siendo por tanto este nivel de ejecucion el personal del administrador,
teniendo las caractersticas que este haya querido introducir.
Cuando hablamos de nivel de ejecucion es posible que lo veamos como
un ente extra no y totalmente lejano a nuestras necesidades y posibilidades.
Nada mas lejano de la realidad.
Cuando accedemos a un nivel de ejecucion, realmente lo que ocurre es
que se ejecutan los scripts contenidos en el directorio rcX.d, donde X es
un n umero que indica el nivel de ejecucion al que nos referimos (rc5.d por
ejemplo a multiusuario con entorno grafico).
Los directorios rcX.d habitualmente los encontramos directamente en
el directorio /etc, si bien en ciertas distribuciones los encontraremos en
/etc/init.d, y si comprobamos su contenido nos daremos cuenta de que con-
tienen varios (en muchas ocasiones una gran cantidad) enlaces simbolicos con
nombres que siguen una estructura muy caracterstica:
El primer caracter que nos encontramos es o una K o una S. A conti-
nuacion tenemos dos caracteres que son n umeros y finalmente tenemos un
nombre sin ninguna regla preestablecida, pero que suele ser exactamente igual
al nombre del fichero que apunta el enlace simbolico, por ejemplo:
K05network
Los ficheros a los que apuntan, los scripts a los que apuntan, habitual-
mente los encontraremos en el directorio /etc/init.d (si bien no es obligatoria
esta ubicacion), y normalmente responden estos scripts a una estructura tipo
case.
Cuando pasamos a un nivel de ejecucion dado, digamos el n umero 5, lo que
ocurre es que se ejecutan en orden estricto todos y cada uno de los scripts
a los que hacen referencia los enlaces simbolicos. Estos scripts se ejecutan
con un unico argumento, que sera start o stop dependiendo de si los enlaces
simbolicos empiezan por S o K respectivamente.
Es decir, si en el directorio rc5.d tenemos los siguientes enlaces simbolicos:
S01network --> /etc/init.d/network
S05nfs --> /etc/init.d/nfs
K01ypbind --> /etc/init.d/ypbind
el orden estricto implica por tanto que el primer script en ejecutarse sera /etc/init.d/ypbind
(K es anterior a S), seguido de /etc/init.d/network (S01 es anterior a S05) y
finalmente /etc/init.d/nfs
54 CAPITULO 6. SCRIPTS DE ARRANQUE.

La forma de ejecutar estos scripts sera por tanto:

/etc/init.d/ypbind stop
/etc/init.d/network start
/etc/init.d/nfs start

Lo cual nos da una idea de la sencillez a la hora de incluir scripts per-

sonales para que se ejecuten de una determinada manera a la hora de pasar
a un nivel de ejecucion concreto, pues lo que tendremos que hacer es ubicar
nuestro script en el directorio /etc/init.d y realizar un enlace simbolico en
el directorio rcX.d que consideremos oportuno, llamando a este script con la
sintaxis correcta.
Hay que tener en cuenta que al ejecutarse en orden estricto, es conveniente
tener en cuenta que scripts se ejecutan antes y despues del que estamos
modificando. Por ejemplo deberamos tener en cuenta que si nuestro script
ejecutara alguna herramienta que necesite de la red para funcionar, debera
ejecutarse (si este es el caso), con posterioridad al script que arranca la red,
por lo tanto si este u ltimo esta enlazado como S08network, nuestro script
podra ser S09script para que se ejecute con posterioridad al arranque de la
red.
Muchas veces equivocamos el sentido del fichero /etc/inittab al rela-
cionarlo con los niveles de ejecucion. Este fichero indica que procesos tienen
que ejecutarse en el arranque as como en la operacion habitual, y una de
sus lneas indica que nivel de ejecucion se utilizara, por defecto, al arrancar
la maquina.
La lnea a la que hacemos referencia bien podra ser:

id:3:initdefault:

en la que se indica que el nivel de ejecucion por defecto, el que se ejecutara al

arrancar la maquina, sera el nivel n
umero 3.
No obstante nosotros podremos cambiar de nivel de ejecucion facilmente
utilizando el comando telinit,

telinit 2

hara que nuestra maquina pasara al nivel de ejecucion numero 2, de tal

forma que podemos utilizar los comandos halt (o shutdown -h now ) y reboot
(o shutdown -r now para apagar la maquina o reiniciarla respectivamente, o
bien sus analogos telinit 0 y telinit 6 respectivamente.
En cualquier momento, podremos saber en que nivel de ejecucion estamos
sin mas que teclear,

runlevel

ademas nos mostrara el nivel de ejecucion previo en el que estuvimos antes.

6.2. SERVICE 55

6.2. service
Estos scripts que tenemos en nuestro sistema pueden ejecutarse con la
opcion stop o start cuando se cambia de nivel de ejecucion, pero tambien los
podremos ejecutar mediante el comando service
service httpd start
por ejemplo arrancara el servidor web en nuestro ordenador, es decir, bus-
cara el script httpd en el directorio /etc/init.d y lo ejecutara con la opcion
start, sin tener que escribir nosotros toda la ruta completa.
Ademas de poder darle la opcion start, podemos optar por proporcionarle
la opcion stop o cualquier otra (status por ejemplo), que tuviera configurada
el script.

6.3. chkconfig
Finalmente, si queremos configurar los distintos scripts que queremos que
paren o arranque al pasar a uno u otro nivel de ejecucion, pero no nos atrae
la idea de estar borrando, modificando o creando enlaces simbolicos en los
directorios correspondientes, siempre podremos hacer uso del comando chk-
config
La ejecucion de este comando con la opcion list
chkconfig --list
nos mostrara en pantalla una lista con todos y cada uno de los scripts que
pueden arrancarse o pararse al cambiar de nivel de ejecucion, describiendo
su estado para cada nivel de ejecucion, es decir, nos indicaran si en el nivel
5, por ejemplo, se arrancan o se paran, etc.
Un ejemplo de ejecucion podra ser:
xfs 0:desactivado 1:desactivado 2:activo
3:activo 4:activo 5:activo 6:desactivado
ypbind 0:desactivado 1:desactivado 2:desactivado
3:desactivado 4:desactivado 5:desactivado 6:desactivado
Con esta herramienta no solo podremos listar el estado, sino que tambien
podremos configurar un determinado script para que se le enve una se nal
stop a la hora de pasar a un nivel de ejecucion determinado:
chkconfig --level 35 sendmail off
que configurara los directorios rc3.d y rc5.d de tal forma que se mandara
una senal stop al script sendmail al pasar a cualquiera de estos dos niveles
de ejecucion.
Igual que hemos utilizado este comando para parar servicios, lo podramos
haber hecho de forma equivalente para que arrancaran servicios cuando pasaramos
a estos niveles de ejecucion, pues lo u
nico que habra cambiado es off por
on.
Captulo 7

Creaci
on de usuarios.

57
58 CAPITULO 7. CREACION
DE USUARIOS.

7.1. Entorno gr
afico.
A la hora de crear usuarios, las diferentes distribuciones de Linux nos
suministran herramientas sencillas con entorno grafico, como por ejemplo
system-config-users, que nos permiten realizar estas tareas administrativas
sin mayor complicacion.

Figura 7.1: Aspecto de la herramienta system-config-users, para la creacion

de usuarios.

Estas herramientas ademas aunan tanto la creacion de grupos, como la

creacion de usuarios y la asignacion de contrase
nas, de tal forma que son
ampliamente utilizadas por los administradores.

7.2. Lnea de comandos.

El uso de este tipo de herramientas graficas no debe dejar de lado la
necesidad que tiene un administrador de utilizar sus equivalentes no graficos
(comandos), ya que muchas veces los administradores no disponen de termi-
nales graficos para poder realizar sus tareas, o bien no se dispone del tiempo
suficiente para utilizarlas a golpe de raton, y se necesita realizar alg
un script
para la automatizacion de las mismas (por ejemplo si habitualmente tenemos
que crear varias decenas de cuentas para usuario).
Los tres comandos utilizados entonces en este sentido son

useradd
groupadd
passwd
7.2. LINEA DE COMANDOS. 59

que nos permiten crear usuarios, grupos y establecer contrasenas respectiva-

mente.
Lo primero que tendremos que hacer por tanto es crear un grupo, si es
que no lo tenemos ya creado, en el que incluiremos al usuario.
El comando groupadd lo invocaremos con la opcion -g con el fin de asignar
un numero identificador al grupo que creemos. Este numero debe ser u nico,
es decir, no debe existir ning
un grupo que tenga asignado este n umero.

groupadd -g 510 nombregrupo

Una vez hayamos creado el grupo correspondiente (que nos servira para
aunar a los usuarios que tengan un perfil equivalente), podremos crear el
usuario mediante el comando useradd.
Este comando tiene mas opciones que groupadd, algunas de las mas im-
portantes son:

-c A~
nade una descripci
on a la cuenta creada.
-d Especifica el directorio HOME del usuario.
-g Indica el grupo principal en el que se
incluir
a el usuario.
-G Indica, separados por comas, los grupos
secundarios del usuario.
-s Especifica la shell por defecto que tendra
el usuario.
-u Asigna el valor num
erico del usuario.

Por lo tanto una tpica ejecucion de este comando sera:

useradd -c "Usuario de calculo" -d /home/usuario -g 510

-G 501,502 -s /bin/bash -u 561 usuario

Finalmente especificar que el comando passwd lo utilizaremos para es-

pecificar la contrase
na de un usuario.
El usuario root puede cambiar la contrase na de cualquier usuario, pero
un usuario no root solo podra cambiar la suya propia. Ademas, cuando root
ejecuta el comando, el sistema no le pedira la contrasena previa de la cuenta
en la que quiere cambiar esta. Sin embargo la ejecucion de este comando por
otro usuario necesitara, para su correcta ejecucion, que le introduzcamos la
contrasena previamente.
Una de las opciones mas desconocidas de este comando es stdin, que
permite que la contrase na sea introducido mediante la entrada estandar sin
la necesidad de que esta sea el teclado.
Esta utilidad es muy utilizada en la creacion de scripts que automatizan
la creacion de cientos de usuarios por ejemplo. El introducir en estos casos
la contrasena mediante el teclado hara impracticable el script, ya que se
demorara de forma alarmante la ejecucion del mismo. Si las contrase nas las
60 CAPITULO 7. CREACION
DE USUARIOS.

tenemos escritas en alg un fichero (o base de datos por ejemplo), siempre

las podremos pasar al comando passwd mediante la entrada estandar sin
necesidad por tanto de escribirlas.
No obstante comentar que tambien podramos realizar una automati-
zacion de este tipo sin la utilizacion del comando passwd, pues el propio
comando useradd incluye una opcion (-p), que permite indicar la contrase na
que tendra este usuario. Esta contrase na tendra que estar previamente en-
criptada mediante crypt, por lo tanto muchas veces es mas complicado im-
plementar un script mediante la llamada a crypt que utilizando el comando
passwd con la opcion stdin.
Captulo 8

Tcpwrappers

61
62 CAPITULO 8. TCPWRAPPERS

Bajo el nombre de tcpwrappers se comprende un sistema de control de

accesos para ordenadores, es decir, la forma de poder seleccionar conexiones
desde ciertos ordenadores.
Normalmente a la hora de levantar un nuevo servicio en nuestro orde-
nador nos solemos interesar sobremanera en los beneficios que puede reportar
este servicio, olvidandonos frecuentemente de las repercusiones negativas, en
cuanto a seguridad, que pueden tener. Esta forma de trabajar suele derivar
en una ausencia de control en cuanto a que ordenadores pueden acceder a los
servicios que estamos ofreciendo, de tal forma que facilitamos enormemente
el trabajo de los hackers, que tienen en los servicios disponibles en nuestro
ordenador la forma de acceder fraudulentamente al mismo.
Herramientas para mejorar la seguridad de los servicios ofrecidos hay
muchas. Una de las mas efectivas, siempre que arranquemos un nuevo servicio
en nuestro ordenador, es leer detenidamente el manual, haciendo especial
hincapie en la lectura de la seguridad del mismo, configurandolo por tanto
de forma efectiva con el fin de evitar accesos no deseados.
Ademas de las propias herramientas que nos puedan ofrecer los propios
programas, existe la utilizacion de los tcpwrappers siempre y cuando los
programas esten desarrollados con compatibilidad con tcpwrapper. Esta her-
ramienta provoca un filtro entre la peticion exterior y el servicio ofrecido por
el ordenador servidor (bajo tcp), de tal forma que acepta la peticion siempre y
cuando se cumplan unas ciertas caractersticas que definiremos en los ficheros
de configuracion correspondiente. A este respecto hay que tener en cuenta
que es una herramienta de seguridad que recarga el sistema, ya que por cada
conexion se provocara un fork que hara uso de las capacidades del sistema,
de tal forma que un excesivo n umero de clientes exigira una maquina con su-
ficiente capacidad para poder asegurar la creacion de los sucesivos procesos
hijos que se iran creando a instancias de tcpwrapper.
Los ficheros de configuracion necesarios para la autorizacion o denegacion
de la peticion son hosts.allow y hosts.deny que se suelen encontrar en el
directorio /etc. Cada fichero de acceso consiste en diferentes lneas de texto
en las que se especifica, en un principio, los ordenadores que pueden o no
acceder a nuestros servicios.
La forma de atender a estas especificaciones es:

* Se procesa el fichero hosts.allow, y a continuacion el fichero

hosts.deny

* Cada una de las lneas de estos ficheros se procesa en orden de aparicion.

* En cuanto se realiza una comparacion acertada, se para con la compro-

bacion.

es decir, si un ordenador intenta acceder a nuestro servidor web, que esta ase-
gurado mediante tcpwrapper, primero se buscara en el fichero hosts.allow si
el ordenador que nos pide la conexion esta permitido o no, buscando alguna

8.1. CONFIGURACION. 63

lnea en la que se autorice esta peticion, si no se encuentra ninguna regla que

afecte esta conexion, se pasara a la evaluacion del fichero hosts.deny. Si no
se encuentra ninguna regla que afecte a esta conexion, se permitira que se
realice.
Con respecto a lo comentado, cabe destacar que es muy importante poner
absoluto cuidado a la hora de crear ambos ficheros. Una forma de trabajar
muy utilizada es la de denegacion por defecto, en la cual lo que haramos es
editar el fichero hosts.deny negando la entrada a cualquier ordenador para
cualquier servicio, editando el fichero hosts.allow con las reglas oportunas que
permitan el acceso a nuestro servidor a los ordenadores que creamos opor-
tunos. Esto nos asegura que en caso de que no hayamos permitido explcita-
mente el acceso a un ordenador, su acceso no sera permitido, y por lo tanto
evitara que por cualquier error a la hora de crear estos ficheros permitamos
la entrada a ordenadores no deseados. En el caso de que nos equivoquemos y
no facilitemos el acceso a alg un ordenador en concreto, tendremos la seguri-
dad de que recibiremos la queja oportuna del usuario que no puede obtener
el servicio ofertado, subsanando el error por tanto. Si optaramos por el caso
contrario, podremos estar seguros de que no recibiremos nunca la queja de
un hacker que haya podido acceder a nuestro ordenador por una sintaxis
erronea.
Con la configuracion de estos ficheros podremos permitir o no diferentes
conexiones, y ademas nos permitira tomar determinadas acciones ante deter-
minadas peticiones.

8.1. Configuraci
on.
A la hora de editar los ficheros de configuracion tenemos que tener en
cuenta las siguientes indicaciones, como hemos adelantado anteriormente:

* Cada fichero de acceso (hosts.allow o hosts.deny), consiste en ninguna

o varias lneas de texto.

* Las lneas son procesadas en orden, terminando la comprobacion en

cuanto se encuentra una concordancia, queden las lneas que queden
por procesar.

* Para permitir una edicion mas confortable, se permite la entrada de

retornos de lnea siempre y cuando, si los queremos evaluar en la misma
lnea, vayan finalizados por \\.

* Las lneas en blanco o las precedidas por # no seran consideradas, per-

mitiendonos por tanto la creacion de ficheros de acceso con comentarios
(lneas precedidas por #) o con mayor facilidad de lectura (insertando
lneas en blanco).

Todas las lneas deben tener la siguiente sintaxis:

64 CAPITULO 8. TCPWRAPPERS

lista_de_demonios:lista_de_clientes[:comando_de_shell]

ltimo (los comandos de shell) optativos y donde con lista de demonios

siendo esto u
nos referimos a una lista con el nombre de uno o varios demonios o palabras
clave y con lista de clientes nos referimos a una lista con uno o varios nom-
bres de ordenadores, direcciones de ordenadores, patrones o palabras clave
que permitan identificar al ordenador cliente, estos u ltimos separados por
comas o por espacios en blanco.
Pasemos entonces a los primeros ejemplos que podemos utilizar en nues-
tros ficheros de configuracion. Recordemos que, a la izquierda de los dos
puntos, debemos poner los demonios a los que hacemos referencia, por lo
tanto en el fichero hosts.allow, si queremos permitir que el ordenador de ip
192.168.0.101 acceda a nuestro ordenador mediante telnet, lo que escribire-
mos sera:

in.telnetd:192.168.0.101

recordemos que podemos escribir mas de un cliente al que se le permite

acceder a nuestro servicio, por lo tanto, si queremos escribir mas de un cliente,
facilmente modificaremos esta lnea para obtener:

in.telnetd:192.168.0.101,192.168.0.102,192.168.0.103

en la que indicamos que permitimos el acceso a nuestro ordenador mediante

telnet, a los ordenadores con ips 192.168.0.101,192.168.0.102 y 192.168.0.103.
Si queremos tambien permitir la entrada a estos ordenadores al servicio ssh,
escribiremos:

sshd,in.telnetd:192.168.0.101,192.168.0.102,192.168.0.103

y podremos escribir tantas lneas sean necesarias con el fin de obtener una
configuracion acorde a nuestras necesidades, recordando a su vez que pode-
mos partir una lnea, para resultar mas comodo a la hora de leer, mediante
el uso de \:

sshd,in.telnetd:192.168.0.101,192.168.0.102,192.168.0.103,\
192.168.0.10,192.188.0.102,192.168.0.233,\
192.168.0.11,192.198.0.102,192.168.0.153,\
192.168.0.12,192.178.0.102,192.168.0.143
ftpd: 192.168.0.1,192.168.0.2,192.168.0.3

8.1. CONFIGURACION. 65

8.1.1. Palabras especiales.

Nos podramos preguntar como podramos permitir el acceso a todos los
servicios que ofrecemos desde uno o varios ordenadores, sin tener que describir
cada uno de los servicios explcitamente, ya que esta formula es sumamente
tediosa.
La forma de especificar todos, es mediante el uso de la palabra especial
ALL, de tal forma que si queremos que el ordenador con ip 192.168.0.10 pueda
acceder a cualquier servicio disponible en nuestro ordenador, escribiremos en
el fichero hosts.allow:

ALL:192.168.0.10

ahora bien, esta palabra especial tambien se puede utilizar a la derecha del
caracter dos puntos, es decir, haciendo referencia a los clientes que pueden
acceder a este servicio. Si tenemos por ejemplo un servidor ftp que ofrece do-
cumentos y/o programas que queremos que pueda obtener cualquier cliente,
lo que podremos escribir en el fichero hosts.allow es:

ftpd:ALL

escribiendo en lneas consecutivas el resto de restricciones que consideremos

oportunas.
Con respecto a esta u ltima idea, comentar que se utiliza mucho a la hora
de crear el fichero hosts.deny, ya que, como digimos anteriormente, una forma
muy extendida de configurar estos ficheros es la de denegacion por defecto y
luego ir permitiendo poco a poco cada uno de los servicios a los clientes que
consideremos oportunos. La denegacion por defecto la podemos conseguir
mediante la configuracion del fichero hosts.deny de la siguiente manera:

ALL:ALL

ya que negara (recordemos que es el fichero hosts.deny) la entrada a cualquier

servicio (ALL a la izquierda de los dos puntos), desde cualquier equipo (ALL
a la derecha de los dos puntos).

Otras palabras especiales son:

LOCAL. Que resulta en una comparacion positiva si el nombre del cliente
no contiene un punto, es decir, es un ordenador local, de nuestra subred.
UNKNOWN. La comparacion resulta positiva en este caso cuando el
cliente que quiere realizar la conexion resulta desconocido, como por ejemplo
cuando no esta registrado, un ordenador, en un servidor de nombres. En este
sentido hay que destacar que resultara UNKNOWN cualquier ordenador
cuyo servidor de nombres este cado, es decir, que no nos permita, temporal o
permanente, realizar una consulta y por lo tanto garantizar su inclusion en el
servidor de nombres. Podramos utilizar esta palabra especial si quisieramos
66 CAPITULO 8. TCPWRAPPERS

evitar todos aquellos accesos de ordenadores no registrados a servidores de

nombre, casos relacionados normalmente con ordenadores de hackers que
intentan provocar malentendidos en cuanto a su identidad real. Debemos
tener presente que podemos encontrar estos ejemplos en algunas compa nas
que ofrecen servicios de conectividad a la Internet que no relacionan sus ips
con nombres. Ademas se nos puede plantear el caso de otras compa nas que
descuidan sus servidores de nombres, permaneciendo estos no operativos con
cierta frecuencia.
KNOWN. Es el caso contrario al ejemplo anterior, de tal forma que se
realizara una comparacion positiva si se puede realizar una consulta correcta
al servidor de nombres en el caso de que intentemos validar un ordenador.
Tambien hay que se nalar en este caso, como en el anterior, que una cada,
temporal o permanente, de su servidor de nombres provocara una compara-
cion erronea.
PARANOID. En este caso se dara una comparacion positiva cuando el
cliente se presenta con una ip que no corresponde a su nombre, casos que se
pueden producir por una incorrecta insercion en el servidor de nombres o,
en la mayora de los casos, por una manipulacion de hackers para intentar
provocar errores en las interpretaciones de los ordenadores atacados.

8.1.2. Patrones.
A la hora de configurar los ficheros hosts.allow y hosts.deny podemos uti-
lizar distintos patrones que nos permiten simplificar la sintaxis de los mismos,
pasemos a enumerarlos:

* Si una cadena empieza por un punto, se considera que el cliente dara una
comparacion positiva si los u
ltimos componentes de su nombre coinci-
den con esta cadena. Por ejemplo si escribimos en el fichero hosts.allow:

ALL:.uni.via.edu

se permitira el acceso a todos los servicios del ordenador a los clientes

cuyo nombre finalice en .uni.via.edu, como por ejemplo lab1.uni.via.edu

* Si una cadena acaba en punto, tenemos un patron equivalente al anteri-

or pero referido a la ip de los ordenadores clientes, es decir, se dara una
comparacion positiva si los primeros campos coinciden con esta cadena.
En el siguiente ejemplo, encontrado en el fichero hosts.allow:

ALL:192.168.10.

se permite el acceso a todos los servicios del ordenador a los clientes

de la subred 192.168.10.0, es decir, a todos los ordenadores cuyos tres
primeros campos en su ip sean 192.168.10 sea cual sea su cuarto campo.

8.1. CONFIGURACION. 67

* Una cadena que comienza con el caracter @ sera tratada como un

nombre de dominio NIS, de tal forma que se dara una comparacion
positiva si el cliente pertenece a este dominio NIS.

* Una cadena de la forma a.b.c.d/m.n.o.p es interpretada como una pare-

ja ip / mascara de red, de tal forma que una direccion IPv4 de un or-
denador dara una comparacion positiva si esta comprendida dentro de
la operacion AND entre la pareja ip / mascara, es decir, si por ejemplo
tenemos:

192.168.17.0/255.255.255.0

todos los ordenadores de la subred 192.168.17.0, es decir, todos los or-

denadores cuyos tres primeros campos de la ip sean 192.168.17 daran
una comparacion positiva. Este mismo ejemplo se puede extender para
el caso de una direccion IPv6, utilizando en este caso la expresion cor-
respondiente para IPv6, n:n:n:n:n:n:n:n/m

* Si la cadena comienza con el caracter / , se entendera que a contin-

uacion se especifica un fichero en el que estaran contenidos los nom-
bres o ips que tengan que compararse con los nombres o ips de los
ordenadores que quieran utilizar los servicios del ordenador. El fichero
puede contener todas las lneas que se necesiten (pudiendo estar vaco
tambien), y los nombres de ordenadores o direcciones comprendidas en
este fichero estaran separadas por caracteres blanco o por comas.

* Se podran utilizar los caracteres * o ? para la comparacion de nombres

o direcciones ip, pero no podran ser utilizados junto con definiciones
del tipo ip/mascara, o cadenas que empiecen o terminen con el caracter
.

8.1.3. Operadores.
Podremos utilizar el operador EXCEPT para especificar una excepcion
tanto en el campo de la lista de los demonios (izquierda del signo dos puntos),
como en el campo de la lista de ordenadores (derecha del signo dos puntos),
de tal forma que podremos tener ejemplos como:

ALL EXCEPT in.telnetd : 192.168.10.

en el fichero hosts.allow, de tal forma que todos los ordenadores de la subred

192.168.10.0 tendran acceso a todos los servicios excepto el telnet, o:

ALL: 192.168.10. EXCEPT 192.168.10.1

donde se permite el acceso a todos los servicios del ordenador en cuestion a

los clientes de la subred 192.168.10.0 salvo al ordenador de ip 192.168.10.1
68 CAPITULO 8. TCPWRAPPERS

8.1.4. Comandos de shell.

Otra posibilidad interesante que ofrecen los tcpwrappers es la ejecucion
de comandos de shell, para ello tendremos que especificarlo en la primera
regla de control de acceso. La ejecucion de los comandos de shell podra ser
ayudada por expansiones que nos permitiran agregar a estos comandos el
nombre del cliente, el nombre del servidor, etc, de tal forma que tengamos
una mayor comodidad a la hora de especificar los comandos. Las expansiones
que podremos realizar son:
* %a La direccion del ordenador cliente.
* %A La direccion del ordenador servidor.
* %c Informacion del cliente. Dependiendo de que informacion este disponible,
esta podra ser usuario@ordenador, usuario@direccion, un nombre de
ordenador o simplemente una direccion.
* %d El nombre del demonio que rige el proceso.
* %h El nombre del ordenador cliente o su direccion si este no esta disponible.
* %H El nombre del ordenador servidor o su direccion si este no esta disponible.
* %n El nombre del ordenador cliente o unknown o paranoid, dependi-
endo del caso, en el caso de que no este disponible el nombre.
* %N El nombre del ordenador servidor o unknown o paranoid, depen-
diendo del caso, en el caso de que no este disponible el nombre.
* %s Informacion del servidor. Dependiendo de que informacion este disponible,
esta podra ser demonio@ordenador,
demonio@direccion o el nombre del demonio.
* %u El nombe del usuario cliente, o unknown en el caso de que no se
conozca.
* % % Se expande como un simple % por si se quiere utilizar este caracter
como tal.

Un ejemplo que podramos tener en este caso es, en el caso del fichero
hosts.allow:

ftpd : 192.168.10.

que permitira acceder al servicio ftp de nuestro ordenador servidor de los

ordenadores de la red 192.168.10.0, y en el fichero hosts.deny:

ftpd:ALL:spawn(/directorio_correspondiente/safe_finger -l
@%h | /directorio_correspondiente/mail -s %d-%h root) &

8.1. CONFIGURACION. 69

en el que ejecutaramos el comando safe finger, que es un comando que se

facilita con tcpwrappers, y que es practicamente equivalente al comando fin-
ger habitual, pero un tanto mas seguro en el sentido que es menos probable
bloquear su ejecucion, con las opciones explicadas con anterioridad.
Si nos fijamos, primero se comprobara la regla del fichero hosts.allow, y
si comprobamos que el ordenador cliente no pertenece a ninguna de las re-
glas contenidas en este fichero, pasaremos a comprobar las reglas del fichero
hosts.deny, donde se especifica que para cualquier ordenador se ejecutara el
comando safe finger y nos podemos fijar que hemos utilizado un par de las ex-
pansiones explicadas anteriormente, para facilitar los argumentos necesarios
al comando safe finger y al comando mail.
A este respecto cabe comentar varias cosas:

* La ejecucion del comando se ejecutara bajo shell /bin/sh

* No se utilizara el PATH definido, sino que habra que definirlo explcita-

mente en la lnea o bien utilizar paths absolutos para los comandos
utilizados.

* Podremos permitir que se sigan comparando reglas si utilizamos al

final de la lnea el caracter &, al igual que ocurre en las ejecuciones
habituales.

* La entrada por defecto as como la salida por defecto y la salida de

error se redirigen a /dev/null por defecto.

Un caso practico que tambien podemos implementar para obtener un log

con los intentos de entrada en el sistema puede ser:

ALL:150.244.120.:spawn(echo Soy %H intentando entrar

en %d desde %h >> /tmp/entradas)&

que generara una lnea por cada intento de entrada en el fichero

/tmp/entradas. En estas lneas recogeramos el nombre del ordenador servi-
dor, el demonio al que intenta acceder y el nombre del ordenador al que
intenta acceder, practico por ejemplo si tenemos un u
nico fichero de log para
todas nuestras maquinas.
Captulo 9

Cortafuegos

71
72 CAPITULO 9. CORTAFUEGOS

El firewall, o cortafuegos en castellano, es un elemento, una herramienta,

que se ha ido introduciendo cada vez con mayor fuerza en el vocabulario
habitual de los usuarios de ordenadores, si bien este concepto existe desde
hace mucho tiempo, y es ampliamente utilizado en redes en las que preocupe
la seguridad.
Hoy en da practicamente en la totalidad de los ordenadores personales
incorporan cortafuegos personales, que son programas que filtran las cone-
xiones entrantes (y salientes) a nuestro ordenador, intentando que nuestro
ordenador no se vea afectado por ning un ataque externo. Ciertamente este
tipo de herramientas han mejorado la calidad de vida de los usuarios de estos
ordenadores personales, disminuyendo considerablemente el n umero de en-
tradas no deseadas en este tipo de sistemas. Esto es debido a la proliferacion
de ataques masivos y automaticos, en los que el hacker programa un ataque y
espera a que cada maquina infectada intente infectar al resto, estando mien-
tras tanto cruzado de brazos a la espera de la cosecha, debida probablemente
a algun fallo de seguridad en los equipos atacados.
De todas formas cuando hablamos de cortafuegos solemos tener en mente
algo distinto a los programas para equipos personales, y mas bien solemos
pensar en una maquina que se encarga de filtrar toda la informacion de una
determinada red. Cortafuegos en este sentido hay muchos, y por ejemplo
nos podemos encontrar con las tpicas soluciones caras y triviales de uti-
lizar que nos ofrecen compa nas dedicadas a la construccion de las mismas;
pero tambien podemos encontrarnos con cortafuegos que mas bien parecen
ordenadores personales.

9.1. Estudio previo.

Antes de aventurarnos en la adquisicion o montaje del cortafuegos, de-
beramos dedicarle algo de nuestro tiempo a la realizacion de un estudio
previo de varios puntos importantes:

* Topologa de la red a proteger.

* Servicios mas susceptibles de ser atacados.

* Equipos fundamentales en mi red.

* Trafico generado.

* Presupuesto disponible.

* Personal disponible.
9.1. ESTUDIO PREVIO. 73

9.1.1. Topologa de la red a proteger.

Un punto extraordinariamente importante a la hora de realizar el estudio
previo es la topologa de la red, es decir, como estan unidos los ordenadores
entre s (desde el punto de vista de intercambio de datos).
Hoy en da es habitual que los ordenadores tanto de una peque na empresa
como de una gran institucion, esten unidos unos con otros gracias a switches.
Esta configuracion, ademas de ser muy sencilla de instalar y mantener, es
relativamente barata, por lo tanto es la que nos vamos a encontrar en la
mayora de los casos, si bien hay que tener en cuenta otro tipo de conexiones,
como USB, firewire, modem, etc.
Obviamente dependiendo de como esten conectados nuestros ordenadores
entre s, y tambien, como tenemos configurada la union de nuestra red a la
Internet, tendremos que configuar nuestro cortafuegos de manera que sea lo
mas optimo posible.
Cuando el tipo de conexion es homogenea, la configuracion del cortafuegos
se hace mucho mas sencilla, independientemente de que sea mas barata o mas
cara. Queremos decir con esto que si todos los ordenadores utilizan tarjetas
fast ethernet (10/100 MBs), en nuestro cortafuegos tendremos que emplear
tarjetas fast ethernet unicamente. De igual forma si todos nuestros equipos se
conectan mediante firewire, tendremos que utilizar conectores firewire en nue-
stro cortafuegos, independientemente de que esta solucion sea mas o menos
barata que la anterior. Sin embargo, si cada equipo de nuestra red tiene
un tipo distinto de conexion, en el cortafuegos tendremos que integrar todas,
con el fin de asegurarnos un correcto funcionamiento del filtrado de paquetes,
haciendo mucho mas complicada la configuracion del cortafuegos, y proba-
blemente mas costosa.

Tipo - Velocidad.
Centremonos por ejemplo en tarjetas de red u nicamente, tendremos que
tener en cuenta algo mas?: Tienen todos los equipos el mismo tipo de tarjeta
de red? Tenemos que tener en cuenta que no es lo mismo estar pensando
en equipos de una oficina, que suelen estar configurados con tarjetas fast
ethernet, gracias a las cuales pueden intercambiar datos entre ellos, que estar
pensando en un centro de computacion en el que sus equipos estan trabajando
gracias a tarjetas Gigabit Ethernet, Infiniband, etc., que les permiten poder
ejecutar calculos paralelizados.
En este sentido tenemos que tener en cuenta que nuestro equipo cortafue-
gos tendra un interfaz de red que tendra que conectarse, de alguna forma, a
estos equipos. Este interface tendra que ser adquirido de forma que se integre
perfectamente en esta topologa que tenemos, pero tambien tendremos que
tener en cuenta la velocidad del mismo.
Si estamos hablando de una oficina en la que todos los equipos poseen
tarjetas fast ethernet, es mas que probable que el interface de red que conecte
nuestro cortafuegos a estos equipos sea una tarjeta de red fast ethernet, ya
74 CAPITULO 9. CORTAFUEGOS

que no provocaremos ning un cuello de botella con su utilizacion, y es una

solucion mucho mas barata que una tarjeta gigabit de la que no vamos a
sacar mayor rendimiento que de esta otra. Si por otro lado estamos en el
ejemplo del centro de computacion, tendremos que tener en cuenta que tipo
de comunicacion van a tener los ordenadores del centro con otros equipos
externos, que estan al otro lado del cortafuegos. Si se van a intercambiar
enormes cantidades de datos entre equipos internos y externos, obviamente el
interface de red que debe disponer el cortafuegos no puede ser una tarjeta fast
ethernet, ya que provocara un embudo que impedira el perfecto desarrollo
de la actividad del centro, sino que habra que adquirir al menos una tarjeta
gigabit (si no mas), que permitan la conexion entre los ordenadores internos
y los externos a traves del cortafuegos.

IPs p
ublicas - IPs privadas.
Quizas estamos muy acostumbrados a la terminologa IP p ublica - IP
privada. Hoy por hoy la mayora de las nuevas configuraciones se realizan
mediante la utilizacion de IPs privadas, reservandose el uso de una (quizas
mas) IP p ublica en el equipo que nos comunica con la Internet, suprimiendo
por tanto el gasto que supondra la utilizacion de una IP p ublica en cada
ordenador.
A la hora de instaurar un cortafuegos, tenemos que tener en cuenta que
no todos los ordenadores tienen que ser protegidos de la misma manera, unos
seran mas crticos que otros, unos tendran mas restricciones de acceso que
otros. Normalmente lo que se suele hacer es repartir las IPs conforme a la
utilidad de los equipos, de tal forma que nos permita este reparto hacer una
clasificacion oportuna conforme a los riesgos potenciales de cada grupo.
Si utilizamos IPs privadas esta clasificacion la podemos hacer facilmente.
Si utilizamos por ejemplo la red 192.168.0.0/16, podremos implementar en
nuestra organizacion 254 apartados de 254 ordenadores cada uno, de tal
forma que podremos separar facilmente los ordenadores por riesgos, incluso
por departamentos si nos interesa, siendo esta clasificacion a priori muy u til
en la configuracion del cortafuegos.
En el caso de IPs p ublicas probablemente no tengamos tan facil esta
clasificacion, ya que no es habitual adquirir muchas IPs mas de las necesarias
a priori, de tal forma que muchas veces disponemos de diferentes partidas de
IPs p ublicas que iremos adquiriendo bajo demanda y que nos haran mas
difcil la clasificacion de los equipos mediante familias de IPs. A favor de la
utilizacion de IPs p ublicas tenemos que en este caso no tendremos que realizar
NAT (traduccion de direcciones de red), que habitualmente se realiza en el
propio cortafuegos, ya que los equipos con IPs p ublicas pueden comunicarse
directamente en la Internet, mientras que en el caso de la utilizacion de
IPs privadas, tendremos que tenerlo en cuenta porque muy probablemente
tengamos que configurar en el cortafuegos NAT para que los equipos puedan
tener acceso a la Internet.
9.1. ESTUDIO PREVIO. 75

9.1.2. Servicios m
as accesibles.
Algo a estudiar de forma previa a la adquisicion del cortafuegos, es
que servicios estamos ofreciendo (y si hay alguno que queremos ofrecer en un
futuro cercano), y que p ublico tienen estos. Si nosotros estamos ofreciendo
informacion a traves de un servidor web a cualquier equipo de la Internet
tenemos que darnos cuenta de que tendremos que tratar de forma diferente
a este servidor que a un ordenador que esta sirviendo directorios a clientes
internos.
Obviamente en el primer caso tendremos que permitir el acceso a traves
de nuestro cortafuegos a cualquier IP, mientras que en el segundo caso solo
deberamos permitir el acceso al servidor a los ordenadores clientes de nuestra
institucion.
Es por tanto fundamental la enumeracion de todos los servicios que esta-
mos ofreciendo, catalogandolos seg un los equipos que pueden acceder a ellos,
tanto equipos internos como externos, para as configurar el cortafuegos con
las reglas correspondientes.
Habitualmente, siempre que sea posible, los equipos que ofrecen servicios
a peticiones externas, suelen ubicarse en una subred distinta del resto de los
equipos, ya que esto permite su aislamiento desde el cortafuegos con mayor
facilidad, no obstante, esten en una subred o no, el cortafuegos debera estar
fsicamente entre estos equipos y el resto de los ordenadores de mi institucion,
es decir, si siguieramos el cable que une a un equipo con servicios que se ofre-
cen externamente, antes de llegar a cualquier equipo interno debera toparme
con el cortafuegos, ya que as, esten en subredes diferentes o no, siempre po-
dre establecer una regla sencilla que impida a ordenadores externos pasar al
interface del cortafuegos donde he conectado los equipos internos.
Cuando separamos los ordenadores que ofrecen servicios externos, deci-
mos que hemos creado una zona desmilitarizada (ampliamente conocido como
DMZ, con sus siglas en ingles), es decir, una zona donde la seguridad no es
tan severa como en el resto de las zonas, y siempre conectaremos esta zona
a un interface de red en el cortafuegos, diferente del resto de zonas.

9.1.3. Equipos fundamentales en mi red.

Aunque repitamos en cierta medida lo expuesto anteriormente, debemos
tener en cuenta tambien que equipos son fundamentales en nuestra red. Si so-
mos practicos, aunque un ataque debe evitarse por todos los medios posibles
sea el ordenador que sea el objetivo, los ordenadores que contienen informa-
cion vital para la empresa tienen que ser, necesariamente, mas mimados.
Este tipo de ordenadores tambien suelen establecerse, si es posible, en
subredes ajenas al resto de los equipos, y siempre conectados al cortafue-
gos a traves de un interface de red distinto al resto de los equipos, ya que
as podremos controlar mucho mejor las conexiones que se haran con estos
equipos.
76 CAPITULO 9. CORTAFUEGOS

Si en el caso de la zona desmilitarizada tenemos el maximo numero de

conexiones permitidas, en esta zona tendremos el mnimo numero de conex-
iones permitidas. Seguramente, salvo que sea imperativo lo contrario, no
permitiremos el acceso de ning
un ordenador externo a esta zona, y probable-
mente de los ordenadores internos no todos podran acceder a cualquiera de
estos ordenadores fundamentales.

9.1.4. Tr
afico generado.
Hemos introducido ya varias veces la necesidad de instalar diferentes inter-
faces para las diferentes zonas de nuestra institucion. Estos interfaces pueden
ser fsicos o no, dependiendo de las necesidades, pero algo que tendremos que
tener en cuenta, y que nos obligara a utilizar o no diferentes interfaces fsicos
es el trafico generado.
En condiciones normales, el trafico generado por los equipos de una insti-
tucion media pueden ser gestionados sin ning un problema con un interface
fsico en el cortafuegos, pudiendose hacer cargo de todas las transacciones
que se mantienen. No obstante el trafico generado tiene que ser estudiado
ya que es posible que no podamos gestionar absolutamente todo debido a
limitaciones con nuestro interface. En estas ocasiones lo que debemos hacer
es instalar mas interfaces que permitan aumentar las posibilidades de nuestro
cortafuegos. Con los equipos actuales (switches) esta operacion es sencilla y
podremos tener un equipo cortafuegos con diferentes tarjetas funcionando de
forma agregada, pudiendo soportar mas trafico del que soportara con una
u
nica tarjeta.
En este sentido tambien tenemos que indicar que las caractersticas del
equipo son importantes para llevar a cabo una buena gestion, ya que no
es lo mismo utilizar un equipo antiguo como cortafuegos, que un equipo
con las u ltimas prestaciones. En este sentido los grandes protagonistas son
el procesador elegido y la memoria RAM. Se suele decir que el procesador
en un cortafuegos no es primordial. Es algo que, con ciertas herramientas
de creacion de cortafuegos, puede ser secundario, pero recordemos que todo
el trafico que atraviesa los interfaces de red del cortafuegos tiene que ser
analizado para comprobar si permitimos o no su entrada, salida o reenvo,
y si tenemos un equipo obsoleto en una institucion con un elevado trafico,
podremos tener problemas de accesos no permitidos por desbordamiento del
cortafuegos.

9.1.5. Presupuesto y personal disponible.

Finalmente entramos en uno de los puntos mas delicados a la hora de
poner en marcha un cortafuegos, y es el presupuesto del que disponemos y
del n umero de horas que se puede dedicar al cortafuegos. En este sentido cabe
decir que existen soluciones finales en el mercado que permiten gestionar el
trafico de cualquier institucion mediante unas reglas que se definen facilmente
9.2. IPTABLES. 77

a traves de un entorno grafico sencillo, parcheandose automaticamente siem-

pre que se descubre alguna vulnerabilidad en el equipo y hayamos pagado
la debida cuota de mantenimiento. Este tipo de soluciones son las ideales
cuando se dispone de un presupuesto importante pero no de personal, ya
que la interaccion que se necesita es mnima, ya que viene preconfigurada de
fabrica. El problema en este sentido es la dificultad de cambio, es decir, si
queremos cambiar algo en nuestra red, la adaptacion del cortafuegos no va a
ser tan inmediata como desearamos y vamos a tener que volver a desembolsar
dinero para que la empresa suministradora lo adapte a nuestras necesidades.
Sin embargo, existen soluciones muy baratas (ordenador personal con
diferentes tarjetas de red), en las que se pueden implementar soluciones gra-
tuitas (iptables de linux), pero que nos van a requerir un cierto tiempo de
configuracion, es decir, ya no vamos a tener a nadie que nos lo configure
sino que vamos a tener que trabajar nosotros en ello, teniendo a una persona
dedicada en parte al cortafuegos para que tenga suficiente pericia para poder
realizar cualquier tipo de cambio en nuestra red en tiempo mnimo.
Esto no quiere decir, ni mucho menos, que una u otra sean las mejores
soluciones, cada una tiene sus pros y sus contras que deben ser estudiados en
cada caso particular. Al igual que en otros campos de la informatica, en este
punto, dejando aparte el tema economico y de personal, hay detractores de
una u otra solucion, alentando la utilizacion de soluciones cerradas debido a
la dedicacion exclusiva de personal de la empresa suministradora a la mejora
del producto o a la utilizacion de soluciones de codigo abierto debido a las
ventajas de este.

9.2. iptables.
La herramienta por excelencia en codigo abierto cuando hablamos de
cortafuegos es iptables, sucesor directo de ipchains, que a su vez proceda
de ipfwadm. Realmente no podemos hablar de un programa, iptables no es
un programa, sino que podramos decir que es un sistema de seleccion de
paquetes que hace uso de netfilter y con el que se pueden definir unas reglas
que se almacenan en memoria, contra las que se comparan los paquetes que
pasan por nuestro ordenador, pudiendo desechar los paquetes que no cumplan
estas reglas, aceptarlos o pasarlos a un determinado interfaz.
iptables lo podemos configurar en nuestro ordenador personal, al igual
que las m ultiples soluciones aparecidas ultimamente para plataformas de
Microsoft, aumentando considerablemente la seguridad de nuestro equipo,
si bien la idea de iptables es mas ambiciosa al poder utilizarse en un or-
denador puente en nuestra red, de tal forma que filtre no solo los paquetes
particulares de un ordenador, sino todos los paquetes de una red, bien sea
una red peque na en una casa, bien una red de una empresa o bien la red de
una universidad. Lo bueno de iptables es que la generacion de las reglas que
nos permitiran controlar los paquetes de esta red, tiene la misma complejidad
78 CAPITULO 9. CORTAFUEGOS

que si la generaramos para nuestro equipo personal, es decir, si sabemos fil-

trar los paquetes que llegan a nuestro ordenador mediante iptables, sabemos
filtrar los paquetes que llegan a una institucion compleja.

9.3. Poltica por defecto.

Lo primero que debemos considerar, ya no al configurar un cortafuegos
con iptables, sino en cualquier caso, es que tipo de poltica vamos a seguir,
si la de aceptacion por defecto o la de denegacion por defecto.
En el primer caso lo que haremos es aceptar todas las conexiones que
lleguen a nuestra cortafuegos, e iremos cerrando las conexiones que consi-
deremos. Este tipo de idea conlleva conocer perfectamente nuestro equipo o
nuestra red, dependiendo de si tenemos un cortafuegos personal o institu-
cional, asegurando aquellos puertos existentes en nuestra red, y no haciendo
absolutamente nada en el resto ya que no existen servicios basados en ellos.
En el segundo caso denegaremos absolutamente todo lo que llegue al
cortafuegos como poltica por defecto, e iremos abriendo los diferentes puer-
tos que nos vayan haciendo falta. Esta segunda forma de trabajar esta am-
pliamente extendida, sobre todo en cortafuegos no personales, casos en los
que es muy complicado conocer perfectamente todos los puertos que tienen
abiertas las maquinas que protege el equipo cortafuegos. En este caso ten-
dremos la seguridad, salvo mala configuracion o gestion, de que no tendremos
ning un ataque a puertos de los que desconozcamos su existencia. Sin embar-
go tendremos que tener muy en cuenta que hasta que tengamos el corta-
fuegos totalmente operativo, recibiremos un n umero considerable de quejas
de usuarios que no pueden acceder a ciertos servicios o contenidos de otras
maquinas al no estar reflejadas todas las posibilidades en el cortafuegos. En
cierto sentido esto ultimo puede considerarse, dandole la vuelta a su signifi-
cado, como un pretexto para no utilizar la aceptacion por defecto, ya que
ante cualquier instalacion nueva de un servicio en cualquiera de los orde-
nadores bajo nuestro cortafuegos, puede pasar desapercibida en la poltica
de aceptacion por defecto por la habitual falta de comunicacion de este tipo
de actividades por parte de los usuarios. En una denegacion por defecto, sin
embargo, estaremos seguros de la comunicacion de este tipo de instalaciones
ya que el propio usuario (enfadado o no) nos avisara de la imposibilidad de
ejecutar correctamente el nuevo software instalado.
A la hora de trabajar con iptables, tendremos que comentar primeramente
que podremos configurar nuestro cortafuegos con la ejecucion de ordenes que
iran aplicando las distintas reglas de cortafuegos. Estas ordenes mayoritaria-
mente las daremos mediante el comando iptables, que iremos alimentando
con diferentes argumentos que iran permitiendo o negando entradas.
A la hora de imponer en nuestro equipo una poltica, utilizaremos el argu-
mento -P, a continuacion describiremos si la poltica afecta a la entrada (IN-
PUT) de paquetes, a la salida (OUTPUT) o a la redireccion (FORWARD),

9.4. INICIALIZACION. 79

y finalmente elegiremos que hacer por defecto con estos paquetes, aceptarlos
(ACCEPT), rechazarlos (REJECT) o eliminarlos (DROP).
En una poltica de aceptacion por defecto escribiremos por tanto:

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD ACCEPT

mientras que en una poltica de denegacion por defecto, escribiremos:

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

Con respecto a las diferencias entre REJECT y DROP: Cuando un pa-

quete no es aceptado mediante REJECT, la maquina origen de este paquete
obtendra la informacion de que el paquete ha sido rechazado, mientras que
si utilizamos la opcion DROP nunca sabra que ha ocurrido con el paquete,
pues sera como si el paquete se hubiera perdido en la transmision. En cuanto
a utilizar una u otra posibilidad, depende del administrador.
Mediante el uso de REJECT estaremos muy probablemente indicando al
usuario de la maquina origen que hay un cortafuegos en nuestra institucion,
que es el causante de que la comunicacion no se lleve a cabo, mientras que
en el segundo caso, mediante la utilizacion de DROP, sera mas complicado
saber si ha sido eliminado el paquete, y su respuesta, por un cortafuegos o
por un fallo en la red. Depende por tanto de las caractersticas de la insti-
tucion, de la red y del administrador del cortafuegos, pues hay veces que se
prefiere realizar un REJECT para hacer ver que existe un firewall, bien para
disuadir a los atacantes, bien para que el usuario de la maquina origen conoz-
ca el caso y pida una apertura del puerto correspondiente al administrador
del cortafuegos. En el caso de DROP, ampliamente utilizado en la configu-
racion de sistemas cortafuegos, quizas estemos aumentando la seguridad por
ocultacion, si bien hay muchas crticas en cuanto a la bondad de la seguridad
por ocultacion.

9.4. Inicializaci
on.
Si analizamos convenientemente lo dicho hasta el momento respecto a
iptables, podremos darnos cuenta de que estas tres polticas por defecto in-
sertaran tres reglas en memoria para el tratamiento de los paquetes pero,
son estas tres reglas nuevas? Hemos tenido otras reglas anteriormente? Es
80 CAPITULO 9. CORTAFUEGOS

decir, no es posible que hayamos ejecutado el comando iptables, con las op-
ciones que sea, anteriormente? En ese caso, que estara pasando realmente
en el cortafuegos?
Pues bien, si previamente hemos ejecutado el comando iptables, es posible
que aunque creamos que ning un paquete por defecto se va a aceptar, una
regla previa tecleada, como prueba, acepte ciertos paquetes, para lo cual o
bien antes de teclear nada nos aseguramos de que reglas tenemos cargadas en
memoria, o bien eliminamos cualquier regla aceptada con el uso de iptables,
asegurandonos por tanto comenzar en un escenario totalmente limpio.
En el primer caso, para conocer las reglas existentes en nuestro sistema,
podremos teclear:

iptables -L

y si queremos en cualquier momento eliminar cualquier regla establecida con

anterioridad, teclearemos:

iptables -F

iptables -Z

Donde la opcion -F elimina la regla que a continuacion escribamos, elim-

inando la totalidad de reglas establecidas si no escribimos nada mas; y la
opcion -Z pone a cero los contadores de bytes y de paquetes, es decir, em-
pezamos a contabilizar a partir de ese momento.

9.5. Cadena INPUT.

A partir de este momento tendremos que ir permitiendo las diferentes
conexiones que nos interesen, para ello tendremos que definir ciertos argu-
mentos de iptables:

* -s Es la fuente del paquete. Habitualmente ponemos la IP desde la que

se origina el paquete, pudiendo poner una mascara que nos interese
mediante el uso del caracter / seguido de la mascara. Como ejemplo:

192.168.5.1/32

que especifica exclusivamente el ordenador con IP 192.168.5.1

192.168.5.1/16

que especifica todos los ordenadores de la subred 192.168.5.0

9.5. CADENA INPUT. 81

* -d Es el destino del paquete, estableciendose este con las mismas reglas

establecidas en el punto anterior.

* sport Es el puerto de origen.

* dport Es el puerto de destino.

* -i Es el dispositivo de entrada del paquete.

* -o Es el dispositivo de salida del paquete.

* -p Protocolo del paquete en cuestion.

* -A Cadena sobre la que se establece la regla, pudiendo ser INPUT,

OUTPUT o FORWARD.

* -j Que es lo que se hara con este paquete, como puede ser ACCEPT,
DROP, REJECT.

Por tanto estableceremos diferentes posibilidades:

Si queremos que todas las conexiones entrantes originadas en el dispositivo
lo (loopback), se acepten, lo que tendremos que escribir es:

iptables -A INPUT -i lo -j ACCEPT

Fijemonos que hemos dicho cualquier tipo de conexion, por lo tanto en

este caso no acotaremos que tipo de protocolo (-p), puerto de origen (sport),
puerto de destino (dport), etc. vamos a autorizar, sino que cualquier cosa
que cumpla que sea originada en el dispositivo lo y sea de entrada al sistema
sera aceptada.
Si tenemos un servidor web configurado, tendremos que permitir todas las
conexiones que se hagan a el, concretamente al puerto 80, para ello tendremos
que teclear:

iptables -A INPUT -p tcp -dport 80 -j ACCEPT

En este caso cualquier tipo de conexion tcp dirigida al puerto 80 sera acep-
tada por parte del cortafuegos pero, y si queremos que nuestro servidor solo
sea visto por los ordenadores de nuestra subred (192.168.6.0)? Teclearemos
entonces:

iptables -A INPUT -p tcp -s 192.168.6.0/24 -dport 80

-j ACCEPT
82 CAPITULO 9. CORTAFUEGOS

9.5.1. Servidores de nombres.

Habitualmente no se nos olvida que nuestro ordenador tiene un servidor
web arrancado, y por lo tanto deberamos permitir la entrada a este puerto,
pero hay ciertas conexiones que no las tenemos tan frescas, que ni siquiera
tenemos en cuenta, pero que aun as deberamos autorizar. Es el caso por
ejemplo de las consultas al servidor de nombres, y es que no se nos debe
olvidar que cada vez que intentamos hacer una conexion a una maquina
mediante su nombre, y no su ip, o cuando alguna comunicacion se presenta a
nuestro ordenador con el nombre, nuestro ordenador tiene que consultar con
el servidor de nombre para poder llevar a cabo la resolucion.
Para permitir este tipo de conexiones, tendremos que insertar en memoria
las siguientes reglas:

iptables -A INPUT -s IP_del_DNS -p udp -m udp --sport 53

-j ACCEPT

iptables -A OUTPUT -d IP_DEL_DNS -p udp -m udp --dport 53

-j ACCEPT

es decir, por una parte permitimos las conexiones entrantes del servidor DNS,
y tambien permitimos las peticiones que hacemos al servidor.

9.5.2. Cadena OUTPUT.

En ciertas redes algo que se permite es la salida de cualquier maquina
al exterior, es decir, se entiende que no hay ning un problema en que las
maquinas internas puedan acceder a cualquier contenido en la Internet. Este
tipo de polticas, si bien estan muy extendidas, hay que pensarlas a fondo por
si son o no convenientes. Normalmente los administradores de los cortafuegos
suelen optar por permitir cualquier conexion de salida porque si no sufren
un gran n umero de crticas internas sobre la configuracion del cortafuegos,
ya que el personal de la empresa o de la institucion no puede acceder a
ciertos contenidos en la Internet que le son necesarios. La solucion quizas no
es permitir cualquier salida, ya que hay muchos troyanos en la Internet que
una vez que infectan la maquina, en vez de esperar una conexion exterior
para permitir la entrada o comenzar una accion determinada, provocan ellos
la comunicacion, ya que en la mayora de las ocasiones las entradas a la zona
interna esta prohibida, pero no as la salida.
Por esta razon es conveniente hacer un analisis, al igual que cuando
hablamos de permitir conexiones entrantes a nuestra red, y ver que tipo
de conexiones salientes deberamos permitir y dejar accesible solamente es-
tas salidas y no otras. No obstante no es que esta solucion sea la clave para
evitar accesos gracias a troyanos, pues muy probablemente tengamos que
permitir la salida a puertos 80 (servidores web), y los troyanos pueden uti-
lizar este puerto como destino, por lo tanto ademas de este tipo de solucion,
9.5. CADENA INPUT. 83

deberamos incorporar otros localizadores de troyanos para evitar intrusiones

aun teniendo cortafuegos.
Si hemos optado por permitir cualquier salida al exterior, la poltica que
escribamos en un principio debera cambiar para ser:

iptables -P OUTPUT -j ACCEPT

dejando las otras dos polticas como habamos indicado.

En el caso de que prohibieramos por defecto las salidas, tendramos que
ir aceptando cada una de las conexiones que nos interesaran, siguiendo los
ejemplos que hemos introducido anteriormente para conexiones entrantes, por
ejemplo, si queremos que cualquier ordenador de nuestra red pueda acceder
a servidores web, teclearamos:

iptables -A OUTPUT -s NUESTRA_SUBRED -dport 80 -j ACCEPT

Si queremos que se pueda acceder al servidor ssh del ordenador cuya IP

es 192.168.9.6, teclearamos:

iptables -A OUTPUT -s IP_ORIGEN -d 192.168.9.6 -dport 22

-j ACCEPT

9.5.3. IP spoofing.
Algo por lo que hemos pasado muy rapidamente, es el uso de -i y -o. Ha-
bitualmente se suelen utilizar bastante para poder hacer uso de la topologa
empleada, ya que cada subred, tanto externa, como DMZ, como subredes
internas, puede estar conectada a un interfaz de red distinto, y por lo tan-
to podremos discriminar las entradas o salidas ya no solo por IP origen y
destino, sino por interfaz origen y destino.
Si queremos, por ejemplo, que cualquier conexion que proceda del interfaz
de red eth0 pueda salir, lo que tendramos que teclear es:

iptables -A OUTPUT -i eth0 -j ACCEPT

mientras que si no queremos que la red conectada a la tarjeta eth1 tenga

conexion hacia el exterior, tendremos que teclear:

iptables -A OUTPUT -i eth1 -j DROP

este tipo de ejecuciones las podemos llevar a cabo por ejemplo, cuando confi-
amos de los ordenadores conectados a la tarjeta eth0 pero no a los que estan
conectados a la eth1.
Tambien se suelen utilizar estas opciones para asegurarnos de que no
estamos siendo atacados mediante IP spoofing. Esta tecnica se basa en en-
ga
nar al receptor haciendole creer que la IP de procedencia es otra de la que
realmente debera tener.
84 CAPITULO 9. CORTAFUEGOS

Supongamos por ejemplo que tenemos dos subredes en nuestra institucion,

una que consideraremos no fiable y otra fiable (aulas de informatica y servicio
de nominas por ejemplo). En este caso, si no hacemos ning un tipo de filtrado,
nada impedira que un usuario de un ordenador en un aula de informatica
configurase el ordenador con una IP del servicio de nominas (de un ordenador
apagado por ejemplo, para no provocar alarmas). Habiendo hecho esto, y si
el cortafuegos estuviera configurado para permitir la salida a la Internet a
todos los ordenadores con IP del servicio de nominas y a los de aulas de
informatica solamente para visitas de paginas web, el mal usuario tendria
acceso como si su maquina fuera del servicio de nominas.
Para evitar estas situaciones lo que podemos hacer es rechazar todas las
conexiones que clamen proceder de donde no deben. Por ejemplo, si a nuestro
interfaz de red eth1 estan conectados solamente los ordenadores de la subred
192.168.101.0 (aulas de informatica) podramos ejecutar:

iptables -A OUTPUT -i eth1 -s 192.168.101.0/24 -dport 80

-j ACCEPT

iptables -A OUTPUT -i eth1 -j DROP

en este orden, pues la primera regla permitira la salida por la tarjeta eth1 de
las conexiones procedentes de los ordenadores con IPs correctas (de la subred
dedicada a aulas de informatica), mientras que el resto negara la salida al
resto de conexiones (a todas la que no cumplieran el primer requisito). Por
ejemplo tener una IP del servicio de nominas e intentar acceder a algo distinto
al puerto 80.

9.5.4. Conexiones establecidas o relacionadas.

Una vez que ya hemos aceptado todas las conexiones entrantes y salientes
que consideremos oportunas, podramos tener el ordenador protegido y oper-
ativo? Probablemente la primera pregunta sera afirmativa, siempre y cuando
nos hubieramos tomado nuestro tiempo para asegurarnos de todas las reglas
escritas, pero en cuanto a la segunda, hemos de decir que todava tendramos
un problema.
Imaginemos que queremos visitar una pagina web. Para ello nuestro orde-
nador tiene permitida la salida al exterior sin mayor problema, pero, que pasara con
los datos que nos devuelve el servidor web? Estos datos, como podemos au-
torizarlos para poder ver el resultado de nuestra consulta?
Este tipo de conexiones no se establecen a puertos determinados, es decir,
cuando hacemos una consulta web, los datos que nos devuelve el servidor web
no van a un puerto en concreto, sino que vamos recibiendolos en puertos no
privilegiados (mayores de 1024) que no dependen del tipo de conexion, sino
que para cada conexion a un servidor web seran distintos. Es claro que de
9.5. CADENA INPUT. 85

esta manera no podemos abrir un puerto para permitir estas conexiones en-
trantes, es mas, si lo pudieramos abrir, lo tendramos que abrir para cualquier
ordenador, algo que no sera del todo practico.
Lo que podemos hacer entonces es autorizar todas las conexiones en-
trantes que tengan que ver con conexiones autorizadas previas que hayamos
tenido. Es decir, una conexion exterior-interior que responda a una previa
interior-exterior permitida, sera autorizada, permitiendo entonces acceder a
los datos que nos presenta el servidor web al que le hemos hecho la peticion.
La regla que deberamos escribir para autorizar este tipo de actuacion sera:

iptables -A INPUT -m state --state ESTABLISHED,RELATED

-j ACCEPT

donde nos encontramos con la opcion -m que nos permite comprobar un

estado para los paquetes que acceden a nuestra maquina, que en este caso
alimentamos despues de state con las palabras clave ESTABLISHED y RE-
LATED, es decir, se permiten (-j ACCEPT) las conexiones que se consideren
establecidas o que se consideren relacionadas con otras previas.

9.5.5. Servidor FTP.

Hay dos formas de realizar una conexion a un servidor FTP, una es la
forma pasiva, y otras es la forma activa. Mediante una conexion activa, un
cliente se conecta a un servidor FTP mediante el puerto 21 para hacer trans-
ferencia de ordenes, y al puerto 20 para hacer transferencia de datos, es decir,
se establecen dos puertos por los que fluye informacion que deberamos au-
torizar mediante el uso de las reglas oportunas:

iptables -A INPUT -p tcp --dport 21 -m state --state NEW

-j ACCEPT

iptables -A INPUT -p tcp --dport 20 -m state --state NEW

-j ACCEPT

donde hemos permitido conexiones a los puertos destino 21 y 20 respectiva-

mente, conexiones del tipo tcp y cuyo estado sea nuevo.
En este tipo de conexiones no deberamos tener problema, ahora bien,
cuando pasamos a tener conexiones pasivas (muy habituales), el puerto de
datos no es el 20, sino que puede ser cualquier puerto, ayudando por tanto
este tipo de conexion a la bajada de archivos. El problema esta aqu en saber
que puerto autorizamos, ya que nunca vamos a saber a priori cual se va a
utilizar. Para solventar este problema no deberemos hacer uso de ninguna
regla de iptables, sino que deberemos cargar en memoria un modulo, en
concreto el modulo ip conntrack ftp mediante la ejecucion:

modprobe ip_conntrack_ftp
86 CAPITULO 9. CORTAFUEGOS

que permitira al cortafuegos seguir las conexiones ftp de datos y pasarlas por
la segunda regla que hemos escrito anteriormente, autorizando entonces o no
la conexion con arreglo a la misma.
Es la primera vez que hemos hecho uso de algo ajeno a iptables, algo que
no tenga que ver con iptables, si bien en ciertas ocasiones lo tendremos que
hacer. Un ejemplo en este sentido lo tenemos en servidores NFS. Cuando es-
tamos realizando conexiones de tipo NFS, los puertos implicados son los del
portmaper (111), nfs (2049) y al menos el de mountd. El puerto asociado a
mountd (y a otros demonios asociados a nfs) es aleatorio, es decir, cuando ar-
rancamos el servidor nfs, este elige un puerto desde el que escuchara mountd,
y por lo tanto no podemos configurar de esta manera el cortafuegos a priori.
Algo que podramos hacer es habilitar en el script de arranque del servi-
dor nfs una lnea que comprobara el puerto con el que arranca mountd, y
as ejecutar iptables permitiendole. No obstante en este caso, y en la may-
ora de los casos de asignacion aleatoria de puertos, se puede resolver a nivel
de configuracion del propio servicio, pudiendo configurar a mano el puerto
con el que queremos que arranque el servicio en concreto, y por tanto poder
as establecer las reglas correspondientes de la misma forma que el resto.

9.6. Scripts de inicio.

Cuando hablamos del arranque de linux, uno de los puntos en los que
inmediatamente pensamos es en la ejecucion de los diferentes scripts del di-
rectorio correspondiente al nivel de ejecucion en el que estamos arrancando
la maquina. Si por ejemplo la maquina arranca en nivel de ejecucion cinco,
sabemos que parara todos los servicios que as lo indiquen los archivos ubi-
cados en el directorio /etc/rc5.d que comiencen con el caracter K, mientras
que arrancara todos aquellos que comiencen con el caracter S.
Este forma de arranque nos permite habilitar cuantas secuencias necesite-
mos ejecutar en el arranque o cambio de nivel de ejecucion de la maquina,
ya que podemos escribirlas en un script y que este se ejecute de forma au-
tomatica, ahorrandonos tener que teclearlo nosotros.
En el caso del cortafuegos esta utilidad no puede pasar desapercibida. El
cortafuegos obviamente se puede arrancar a mano, tecleando una por una
cada una de las reglas del mismo, si bien podramos recoger todas ellas en un
script, llamado por ejemplo cortafuegos y ubicarlo en el directorio /etc/init.d
Una vez hayamos dado permisos de ejecucion a este archivo, podemos crear
un enlace simbolico en el directorio que corresponda al nivel de ejecucion por
defecto, si es el cinco podramos teclear:

ln -s /etc/init.d/cortafuegos /etc/rc5.d/S10cortafuegos

La estructura que debemos dar a este archivo es la de case, o al menos es

la mas afortunada para estos casos, y consiste en:
9.6. SCRIPTS DE INICIO. 87

case "$1" in

start)
# Secuencias para arrancar el cortafuegos.
;;

stop)
# Secuencias para parar el cortafuegos.
;;

restart)
$0 stop
$0 start
;;

*)
# Secuencias que se ejecutar\{a}n si no ejecutamos
# el script con el argumento start o stop o restart.
;;

esac

exit 0

Esta sintaxis significa que dependiendo de lo que se escriba como primer

argumento en la ejecucion del script, se ira al apartado correspondiente y se
ejecutara lo que en el este escrito hasta que termine. Cada uno de los aparta-
dos comienzan con los caracteres que coinciden con este primer argumento
seguidos del smbolo ) y acaban con los dos punto y coma, pudiendo escribir
cuantas instrucciones queramos entre medias, de tal forma que se ejecutaran
cuando sea llamado el script con este argumento.
Estos scripts ubicados en /etc/init.d suelen tener cuatro casos: start, stop,
restart y *. En el caso start se suele poner aquellos comandos necesarios
para arrancar el servicio oportuno, el caso stop los comandos necesarios para
pararlos y luego en el caso restart pondremos normalmente las lneas:

$0 stop

$0 start

que nos permitiran llamar al script ($0) para ejecutar los comandos del caso
stop y luego los del caso start, con el fin de rearrancar los servicios corre-
spondientes. Normalmente se suele poner el caso * con el que nos aseguremos
que se ejecute las secuencias correspondientes hasta los dos puntos y coma
siempre y cuando el primer argumento que demos al script no coincida con
ninguno de los casos, como por ejemplo cuando intentamos arrancar el script
88 CAPITULO 9. CORTAFUEGOS

y nos confundimos, tecleando por ejemplo skart en vez de start. En este caso
se suele poner una sentencia echo que nos invite a volver a teclear de nuevo
el argumento, indicandonos que nos hemos equivocado previamente.
En el caso de los cortafuegos creados con iptables ademas se suele poner
otro caso mas que es el paranoico, en el que configuramos las reglas mas
restrictivas posibles, de tal forma que si entendemos que podemos estar ante
un caso de ataque, podamos invocar el script de esta forma y as impedir
cualquier conexion.
Para finalizar la descripcion del script, decir que antes de comenzar la
sentencia case, podemos poner las definiciones iniciales que consideremos
oportunas. En este sentido podemos definir los comandos a utilizar mediante
variables cortas y significativas, as como definir tambien mediante el uso
de variables las ips y los interfaces, truco este que nos servira ademas para
evitar equivocaciones, pues no es lo mismo escribir intranet, que por ejemplo
192.168.10.0/24

9.6.1. Ejemplo de script.

#!/bin/bash

#--------------------
# Rutas de programas.
#--------------------

iptables=/sbin/iptables
modprobe=/sbin/modprobe

#----------------------------
# Especificaciones iniciales.
#----------------------------

# Ips.
privilegiadas="192.168.32.204 192.168.34.78 192.168.78.98"

case "$1" in
start)

#----------------------------------------
#Finalmente nos ponemos con el firewall.
#----------------------------------------

# Cargamos el modulo que nos permite hacer FTP pasivo.

9.6. SCRIPTS DE INICIO. 89

$modprobe ip_conntrack_ftp

# Nos quitamos todo lo que hubiera.

$iptables -F
$iptables -Z

# Reglas por defecto para el firewall

$iptables -P INPUT DROP

$iptables -P OUTPUT DROP
$iptables -P FORWARD DROP

# Configuracion del dispositivo loopback

$iptables -A INPUT -i lo -j ACCEPT

$iptables -A OUTPUT -o lo -j ACCEPT

# Permitimos nuestra salida asi como las entradas

#relacionadas y establecidas.

$iptables -A OUTPUT -o eth0 -j ACCEPT

$iptables -A INPUT -i eth0 -m state --state
ESTABLISHED,RELATED -j ACCEPT

# Permitimos el acceso por ssh a unas poquitas maquinas.

for maquina in $privilegiadas

do
$iptables -A INPUT -p tcp -i eth0 --dport 22
-m state --state NEW -s $maquina -j ACCEPT
done

# Permitimos el acceso por ftp a la red 192.168.0.0/16

$iptables -A INPUT -p tcp -i eth0 --dport 21

-s 192.168.0.0/16 -j ACCEPT
$iptables -A INPUT -p tcp -i eth0 --dport 20
-s 192.168.0.0/16 -j ACCEPT

;;

stop)
90 CAPITULO 9. CORTAFUEGOS

# Nos quitamos todo lo que hubiera.

$iptables -F
$iptables -Z

# Reglas por defecto para el firewall

$iptables -P INPUT ACCEPT

$iptables -P OUTPUT ACCEPT
$iptables -P FORWARD ACCEPT

;;

paranoico)

# Nos quitamos todo lo que hubiera.

$iptables -F
$iptables -Z

# Reglas por defecto para el firewall

$iptables -P INPUT DROP

$iptables -P OUTPUT DROP
$iptables -P FORWARD DROP

;;

restart)

$0 stop
$0 start

;;

*)

echo "Invoque este script con las opciones

{start, stop, restart o paranoico}"

exit 1

;;

esac
9.6. SCRIPTS DE INICIO. 91

exit 0

Este script es eso, un script, por lo tanto cualquier a nadido que queramos
incluir, que este permitido por la shell correspondiente, podra insertarse sin
mayor problema, como por ejemplo el bucle del ejemplo, en el que permiti-
mos el acceso a nuestro cortafuegos a traves de ssh a varias maquinas, que
previamente hemos cargado, sus IPs, en una variable.
Captulo 10

Accounting.

93
94 CAPITULO 10. ACCOUNTING.

Cuando en un equipo hay mas de un usuario, y sobre todo cuando hay

usuarios que no son administradores, es conveniente saber que comandos se
han ejecutado en el sistema para tener un poco de control sobre el mismo,
saber si los usuarios utilizan comandos no permitidos o incluso estan inten-
tando acceder al sistema de forma no permitida compilando y/o utilizando
cracks que permitan la escalada de privilegios en el sistema.-
La forma de controlar este tipo de a ctividades es mediante el accounting,
llevado a cabo mediante acct, que lo podemos obtener de:

http://ftp.gnu.org/gnu/acct/

Para poderlo instalar en nuestro sistema, nos bajamos de este URL la

u
ltima version disponible de acct y la descomprimimos en un directorio tem-
poral. El archivo resultante lo desempaquetamos mediante tar, y accedemos
al directorio creado.
Ejecutamos entonces:

./configure --prefix=/usr/local/seguridad/accounting/
make
make check
make install

siendo root para ejecutar esta u

ltima orden.
Esto nos generara una estructura de directorios y archivos a partir del
directorio que hemos indicado al script configure.
Ademas de esta estructura, crearemos varios directorios:

mkdir /usr/local/seguridad/accounting/logs
mkdir /var/account/
mkdir /usr/local/seguridad/accounting/scripts

En el primero permaneceran los logs que se vayan generando da a da, en el

segundo directorio sera el sistema el que vaya guardando la informacion de
accounting que se vaya generando en cada momento y finalmente, en el tercer
directorio, guardaremos los scripts que vamos a utilizar para el formateo y
tratamiento que hagamos de la informacion de accounting.
Antes de poner todo en funcionamiento, tambien deberamos crear el
grupo adm, pues es el que utiliza acct para generar los datos. Este grupo lo
crearemos con el comando groupadd
Para arrancar y parar el servicio de accounting, utilizaremos el script acct
generado inicialmente por Ian Murdock (utilizaremos la version modificada
de Dirk Eddelbuettel) que es distribuido con estas herramientas.
El script de arranque de acct es:

#! /bin/sh
#
 95

# Start or stop process accounting

#
# Initial version written by Ian Murdock
# <imurdock@debian.org>
# This version written by Dirk Eddelbuettel <edd@debian.org>

set -e

directorio=/usr/local/seguridad/accounting/sbin/

compare_kernel_version_and_exit_if_needed() {

# thanks to Joey Hess for this shell script snippet

# -- easier than my previous perl code
cmp_major=2
cmp_minor=2

# thanks for Ralf Hildebrandt

# <ralf.hildebrandt@charite.de>
# for a simpler uname -r solution which also works for
# hppa
#kernel_major=uname -a | cut -d -f 3 | cut -d. -f 1
#kernel_minor=uname -a | cut -d -f 3 | cut -d. -f 2
kernel_major=uname -r | cut -d. -f 1
kernel_minor=uname -r | cut -d. -f 2
if [ $kernel_major -gt $cmp_major ]
then
valid=true
elif [ $kernel_major -eq $cmp_major ] && [ $kernel_minor
-ge $cmp_minor ]
then
valid=true
else
valid=false
fi

if [ "$valid" = "false" ]; then

echo "Skipping process accounting: Package requires
kernel 2.2.*."
exit 0
fi
}

test -x $directorio/accton || exit 0

96 CAPITULO 10. ACCOUNTING.

# If you want to keep acct installed, but not started

# automatically, set this variable to 0. Because
# /etc/cron.daily/acct calls this file daily, it is
# not sufficient to stop acct once after booting if
# your machine remains up.
START_ACCT=1

if [ $START_ACCT -eq 1 ]
then
compare_kernel_version_and_exit_if_needed
fi

case "$1" in
start)
# We start acct only if the switch variable tells us to
if [ $START_ACCT -eq 1 ]
then
# Have to turn this on to be able to test the return
code
set +e
echo -n "Starting process accounting: "
mv /var/account/pacct /var/account/pacct-
date +%d-%m-%Y-%s
touch /var/account/pacct
chown root:adm /var/account/pacct
chmod 640 /var/account/pacct
$directorio/accton /var/account/pacct 2>/dev/null
rv=$?
if [ $rv -eq 0 ]
then
echo "done."
elif [ $rv -eq 38 ]
then
echo "failed"
echo "Process accounting not available on this
system."
elif [ $rv -eq 16 ]
then
echo "failed"
echo "Process accounting already running on this
system."
else
logger -f /var/log/daemon.log \
"Unexpected error code $rv received in
/etc/init.d/acct"
 97

fi
set -e
fi
;;
stop)
echo -n "Stopping process accounting: "
# Have to turn this on to be able to test the return code
set +e
$directorio/accton 2>/dev/null
if [ $? -eq 0 ]
then
echo "done."
else
echo "failed."
echo "Process accounting not available on this system."
fi
set -e
;;
restart|force-reload)
echo -n "Restaring process accounting: "
# Have to turn this on to be able to test the return code
set +e
$directorio/accton 2>/dev/null
if [ $? -eq 0 ]
then
echo "done."
else
echo "failed."
echo "Process accounting not available on this
system."
fi
set -e
# We start acct only if the switch variable tells us to
if [ $START_ACCT -eq 1 ]
then
# Have to turn this on to be able to test the
return code
set +e
echo -n "Starting process accounting: "
$directorio/accton /var/account/pacct 2>/dev/null
rv=$?
if [ $rv -eq 0 ]
then
echo "done."
elif [ $rv -eq 38 ]
98 CAPITULO 10. ACCOUNTING.

then
echo "failed"
echo "Process accounting not available on this
system."
elif [ $rv -eq 16 ]
then
echo " failed"
echo "Process accounting already running on this
system."
else
logger -f /var/log/daemon.log \
"Unexpected error code $rv received in
/etc/init.d/acct"
fi
set -e
fi
;;
*)
echo "Usage: /etc/init.d/acct {start|stop|restart
|force-reload}"
exit 1
esac

exit 0

Este script lo copiaremos en /etc/init.d y lo llamaremos acct, dandole por

supuesto permisos de ejecucion. Requiere atencion la variable directorio, que
debera ser cargada con el valor correspondiente a lo que hemos indicado en
prefix a la hora de ejecutar el script configure en la instalacion de acct.
Este script lo que hara es empezar a guardar en /var/account los datos
relativos al accounting, datos que podremos luego procesar para estar infor-
mados de los comandos que han utilizado los usuarios del sistema.
Para obtener un listado con los comandos ejecutados por los usuarios,
programaremos en el cron la siguiente tarea:

0 0 * * * /usr/local/seguridad/accounting/scripts/control >
/dev/null 2>&1

siendo el script control al que hace referencia:

#!/bin/bash

directorio=/usr/local/seguridad/accounting/logs/
log=date +%d-%m-%Y-%s
maquina=hostname
direccion=root
 99

filtrado=""

/etc/init.d/acct stop
/etc/init.d/acct start
ultimo=ls -ltrsia /var/account/pacct-* |awk {print $11}
|tail -1

echo > ${directorio}/${log}

echo "Control de procesos ejecutados en $maquina." >>
${directorio}/${log}
echo >> ${directorio}/${log}
echo "El fichero de accounting utilizado es:" >>
${directorio}/${log}
echo $ultimo >> ${directorio}/${log}
echo >> ${directorio}/${log}
echo >> ${directorio}/${log}

/usr/local/seguridad/accounting/sbin/sa -a -u -f $ultimo >

${directorio}/${log}.sa 2>&1
cp -f ${directorio}/${log}.sa ${directorio}/tempoa

for comando in $filtrado

do

grep -v " $comando " ${directorio}/tempoa > ${directorio}/

tempob
cp -f ${directorio}/tempob ${directorio}/tempoa

done

cp -f ${directorio}/tempoa ${directorio}/${log}.sa-limpio

echo "La salida filtrada es:" >> ${directorio}/${log}

echo >> ${directorio}/${log}
cat ${directorio}/${log}.sa-limpio |awk {print $1,$7,$8}
|sort -u >> ${directorio}/${log}
echo >> ${directorio}/${log}

/bin/mail -s "Control de procesos de $maquina" $direccion

< ${directorio}/${log}

rm -f ${directorio}/tempob ${directorio}/tempoa

/usr/bin/bzip2 ${directorio}/${log}*
100 CAPITULO 10. ACCOUNTING.

que lo que hara es, una vez al da (segun hayamos programado en el cron),
enviarnos un mensaje de correo electronico con la informacion de los procesos
ejecutados por los distintos usuarios del sistema, convenientemente formatea-
da e incluso filtrada ya que no mostrara aquellos comandos existentes en la
variable filtrado.
El filtrar comandos es debido a que muchas veces la lista de los comandos
ejecutados en el sistema es tan grande que supera el tiempo que disponemos
para leer el mensaje (acordemonos que este script se ejecutara una vez al
da en cada una de las maquinas que administremos). Si localizamos los
comandos fiables, es decir, carentes de peligro potencial, podemos incluirlos
en esta variable y por lo tanto no ser procesados a la hora de enviarnos el
mensaje de correo electronico.
Por supuesto el script aqu utilizado puede cambiarse con el fin de obtener
un mejor resultado cara a la administracion, si bien es un buen comienzo para
tener el sistema de accounting funcionando desde el primer momento.
Para que acct empiece a funcionar deberamos teclear:

/etc/init.d/acct start

o esperar a la ejecucion del script control, que en su ejecucion para y arranca

este script. En nuestra mano queda ademas realizar un enlace simbolico para
que arranque de forma conveniente al pasar al nivel de ejecucion por defecto
(o utilizar la herramienta chkconfig).
Captulo 11

Previsi
on de ataques.

101
102 CAPITULO 11. PREVISION
DE ATAQUES.

Uno de los problemas de seguridad mas graves con los que nos vamos a
enfrentar en un sistema operativo linux son los troyanos.
Los troyanos son instalados en nuestro ordenador por fallos de seguri-
dad, bien por bugs de programacion o bien por una configuracion erronea en
nuestro sistema.
No tener actualizado el sistema operativo o no tener bien acotado el acce-
so que tienen nuestros usuarios (fsico o remoto) al equipo puede ocasionar la
instalacion de un conjunto de herramientas que permitan la utilizacion indis-
criminada de nuestra maquina sin nuestro consentimiento ni conocimiento.
El control exquisito de las actualizaciones del sistema, y el acceso a nuestro
ordenador por parte de los usuarios debe ser una de nuestras prioridades
mas importantes. En el segundo punto, no solo tendremos que especificar
correctamente los permisos en los ficheros susceptibles de autorizar a usuarios
hacerse con el control del sistema, sino tambien impedir el acceso fsico al
equipo, ya que en el momento que alguien tenga delante nuestro equipo
sera solo cuestion de tiempo que se haga con su control.
Afortunadamente en el mundo Linux apenas tenemos la amenaza de los
virus. Sobre todo esto es debido a la idea que subyace en el funcionamiento
de Linux, y es que casi nunca utilizamos la cuenta de root para realizar
operaciones cotidianas como la lectura de nuestro correo electronico personal.
Estas tareas llevan consigo la posibilidad de la instalacion de software no
seguro (virus), que pueden comprometer el equipo al ser instalados con altos
privilegios.
En otros sistemas operativos, donde la mayora de los usuarios cuentan
con cuentas mas privilegiadas de lo que deberan ser, la instalacion de virus
en este sentido es un hecho. En el caso de Linux ya no es tan habitual pues
deberamos ejecutar estos programas desde la cuenta del superusuario, y
habitualmente los administradores no suelen caer en este error.
De todas formas algo muy habitual en los administradores es instalar soft-
ware de fuentes no fiables. Es decir, a la hora de buscar software que deseamos
instalar en nuestro ordenador una simple b usqueda en www.google.com es ad-
mitida por la mayora de los administradores. Las direcciones que nos muestra
Google, son las correctas? Pertenecen realmente a los desarrolladores del
software?
Hay que tener en cuenta que muchas veces no es as, y junto con el software
que queremos instalar en nuestro equipo nos bajamos software no deseado
con comportamiento de virus o troyano.
Una forma de controlar si tenemos alg un troyano en nuestro equipo es
instalar un anti troyanos. Suele haber en la red diferentes posibilidades de
anti troyanos, si bien dos de las mas utilizadas son chkrootkit y rkhunter.
La idea de ambas utilidades, de ambas aplicaciones es comparar los archivos
que habitualmente sufren cambios tras la instalacion de un troyano, con bases
de datos. Si se comprueba que uno de estos archivos contiene informacion ha-
bitual en un troyano, entonces el programa nos avisara y en ese momento
deberemos proceder a la limpieza del equipo.
11.1. CHKROOTKIT 103

11.1. chkrootkit
Para bajarnos el codigo fuente de esta herramienta nos conectaremos a:

http://www.chkrootkit.org/download/

Descomprimiendo y desempaquetando el fichero bajado con gunzip y tar.

gunzip chkrootkit.tar.gz
tar -xvf chkrootkit.tar

y compilamos, tecleando directamente:

make sense

una vez que ha compilado sin problemas, podremos ejecutarlo sin mas me-
diante el comando chkrootkit que se habra generado en el directorio donde
hemos compilado.
La ejecucion de este comando la deberamos programar de tal forma
que cada da chequeara nuestro sistema en busca de troyanos, tomando por
supuesto las medidas oportunas en el caso de obtener alg
un positivo.

11.2. Rootkit Hunter.

Rootkit Hunter es una herramienta que analiza el sistema en busca de
rootkits, puertas traseras y exploits locales ejecutando diferentes pruebas, a
saber:

* Comparacion de marcas MD5.

* Comprobacion de ficheros caractersticos de rootkits.

* Comprobacion de permisos erroneos de ciertos binarios.

* Comprobacion de cadenas sospechosas en modulos LKM y KLD.

* B
usqueda de ficheros ocultos.

* Comprobacion, opcional, de ficheros de texto y binarios.

Para instalarlo en nuestro sistema, nos bajaremos una copia del codigo
fuente, en un directorio temporal y la descomprimiremos:

gunzip rkhunter.tar.gz

a continuacio la desempaquetaremos:

tar -xvf rkhunter.tar.gz

104 CAPITULO 11. PREVISION
DE ATAQUES.

Finalmente accederemos al directorio creado y ejecutaremos el shell script

installer.sh que nos instalara ciertos ficheros en el directorio /usr/local/rkhunter
A continuacion pasaremos a ejecutar rkhunter, para ello teclearemos:

/usr/local/bin/rkhunter --versioncheck

que comprobara si la version de nuestro sistema es la ultima disponible,

debiendo actualizarla si no es as.
A continuacion actualizaremos la base de datos, para ello ejecutaremos:

/usr/local/bin/rkhunter --update

y finalmente ejecutaremos rkhunter en busca de rootkits, puertas traseras y

exploits locales en nuestro sistema ejecutando:

/usr/local/bin/rkhunter --checkall

Este programa tambien deberamos ejecutarlo regularmente, para ello po-

dramos realizar un shell script que fuera ejecutado diariamente, por ejemplo,
y mandara al administrador del equipo la informacion de su ejecucion. En
este sentido en el script creado a tal efecto deberamos reunir las dos primeras
lneas, y en vez de la ejecucion con la opcion - -checkall de la tercera lnea,
podramos utilizar:

/usr/local/bin/rkhunter --cronjob --report-warnings-only

que son las opciones creadas para la ejecucion correcta mediante scripts, de
tal forma que nos informe de los positivos en un formato que se pueda mandar
facilmente por correo electronico o guardar en un log, y no en formato de
color, y con excesiva informacion, como se obtiene la salida de su ejecucion
con la opcion - -checkall
Captulo 12

Backup

105
106 CAPITULO 12. BACKUP

Ya es no solo conocido, sino totalmente aceptado, la necesidad de realizar

backups periodicos de nuestro sistema.
Back-up significa respaldar, es decir, tener una copia de lo que considere-
mos importante.
Esta idea la entendemos perfectamente, pero muchas veces no la llevamos
a todo su significado. El tener una copia de respaldo es vital, eso lo sabemos,
pero de que hacemos backup? Como hacemos el backup? Cuando hacemos
el backup? Como guardamos el backup?
Todas estas preguntas muchas veces se quedan sin una buena contestacion
debido a que nada mas ponernos a trabajar en este punto intentamos poner
en marcha una solucion de backup sin mas, sin parar a pensar absolutamente
nada mas.
El backup no debemos hacerlo de todo el sistema en la mayora de las
ocasiones. Realmente queremos un backup de los archivos temporales de
nuestros sistemas? Nuestros usuarios nos van a pedir archivos intermedios
de calculos que hayan realizado? Sin embargo es fundamental realizar una
copia (o varias) de respaldo de los ficheros de los usuarios, pero tambien de
los ficheros de configuracion de nuestro sistema con el fin de ahorrar mucho
trabajo si nuestra maquina colapsa.
Algo importante a tener en cuenta es la frecuencia, cada cuanto hacemos
backup? Los datos de los usuarios deberan tener un respaldo al menos una
vez a la semana. Hay que tener en cuenta que estos datos cambian cons-
tantemente, por lo tanto cuando mas alejemos las copias de seguridad, mas
posibilidades tendremos de que se pierdan ficheros importantes.
Sin embargo los programas que tenemos instalados en nuestro equipo,
realmente necesitan ser respaldados semanalmente? En este sentido es posi-
ble que solo sea necesario realizar una copia de seguridad cuando se haga
alguna modificacion sobre los mismos, que puede ser a diario o bien puede
ser cada varias semanas. Es decir, justo en el momento de realizar una modifi-
cacion (una instalacion de un nuevo programa en nuestro sistema), realizare-
mos la copia de seguridad, y el resto del tiempo no sera necesario.
Como hacemos el backup? Aqu realmente nos referimos a dos cuestiones.
En que soporte? Con que software?
Soportes hay muchos en el mercado, desde los disquetes (claramente en
desuso hoy en da), hasta las famosas cintas pasando por los discos duros.
Por supuesto las cintas de backup son muy utilizadas en este sentido, y no
es raro encontrar un CPD en el que haya un robot de backup consistente en
un brazo robotizado que se encarga de ir cambiando cintas de backup de una
unidad de cinta que esta constantemente haciendo backup del sistema.
Las cintas tienen la ventaja de poder alojar gran cantidad de informacion
en un espacio realmente reducido, pero tienen la gran desventaja del acceso
lineal, que las hace terriblemente lentas a la hora de recuperar datos (si bien
hoy en da la velocidad de acceso ha aumentado considerablemente).
Un soporte muy utilizado es el DVD, pues debemos tener en cuenta que
pueden alcanzar hasta 9GB aproximadamente y son relativamente baratos
 107

y con poco volumen. El problema en este sentido es que deberamos irnos

a utilizar DVDs regrabables pues si no estaramos utilizando soportes que
deberamos tirar una vez se realizar un backup posterior, pues son soportes
(los no regrabables) de un solo uso.
Los discos duros, si bien muchas veces no son contemplados como so-
portes de backup, son elementos que cumplen varias caractersticas intere-
santes. Son relativamente baratos (teniendo en cuenta la relacion capaci-
dad/precio), faciles de cambiar (alojados en carcasas extrables o con soporte
USB o Firewire) y muy rapidos. En este sentido se les puede ver en la mayora
de las ocasiones como los dispositivos mas interesantes a la hora de realizar
backup.
Los discos duros, como hemos adelantado, los podemos utilizar en car-
casas extrables. En este sentido el problema que vamos a tener es que si
queremos realizar un cambio, tendremos que apagar el sistema que los aloja
(salvo que sean disco de cambio en caliente). Tambien los podemos utilizar
en carcasas USB o Firewire, si bien las velocidades de transferencia seran
menores en este caso.
El software que podemos utilizar para realizar las copias de seguridad es
muy diverso. Si realizamos una comprobacion en alguna pagina dedicada a
ofrecer software, encontraremos gran cantidad de herramientas disponibles.
Hasta que punto es necesario una herramienta de este tipo?
Esta pregunta nos la tendremos que contestar, por supuesto. Hay muchas
herramientas comerciales cuyo coste es prohibitivo para muchos presupuestos.
Otras herramientas son gratuitas y por lo tanto facilmente accesibles, en-
tonces, debemos utilizarlas?
Ante esta pregunta hay m ultiples respuestas, y todo depende del admi-
nistrador que se la formule. Si estamos acostumbrados a utilizar alguna de
estas herramientas la respuesta sera inmediata, y sera la instalacion de la
misma en nuestro sistema, pero sin embargo si estamos acostumbrados a los
comandos habituales que Linux tiene en el sistema que nos pueden servir
para realizar backups, muchas veces nos decantaremos por realizar el backup
a nuestra manera.
Sea como fuere el soporte que hayamos utilizado para realizar la copia
de seguridad no puede abandonarse. Las cintas, los DVDs, los discos duros,
etc., cualquier soporte utilizado debera guardarse en un lugar seguro (siendo
aconsejable un armario ignfugo para evitar perder la informacion en un
incendio), y fundamentalmente alejados de la fuente.
En muchas ocasiones las copias de seguridad se dejan al lado del sistema
del que hemos hecho la copia. Esta practica es totalmente intolerable, pues
las copias de respaldo se realizan para evitar la perdida de informacion ante
imprevistos, y por supuesto si un equipo tiene un imprevisto, la probabilidad
de que el soporte cercano tambien lo tenga es alto. Que pasa si hay una
gotera encima del equipo? Que ocurre si se declara un fuego? En estos casos
habremos perdido el equipo y la copia de respaldo.
108 CAPITULO 12. BACKUP

Si nos decidimos por soluciones mas voluminosas, como por ejemplo un

equipo con varios discos duros que realice un backup de alg
un sistema pesado,
entonces la posibilidad de mantener este equipo dentro de un armario ignfugo
es irreal. En estos casos lo que deberemos hacer es alejar los equipos de
respaldo de los equipos de produccion, de tal forma que un problema en uno
no acarreara la perdida de datos, pues los antendremos en otro equipo.
Por supuesto si realizamos mas de una copia de seguridad, guardadas en
ubicaciones distintas, entonces podremos decir que realmente el backup es
altamente fiable.

12.1. Herramientas propias.

Como habamos indicado, muchos administradores tienden a no utilizar
software externo para realizar copias de seguridad, sino que utilizan herra-
mientas del sistema operativo que permite realizar respaldos sin mayor prob-
lema.

12.1.1. dump
dump es la herramienta por excelencia de backup en Linux.
Si bien a priori podramos pensar que es un comando complicado, su
utilizacion es sencilla una vez entendido su uso.
dump realiza una copia de seguridad de los archivos que necesiten ser
respaldados. Para saber que ficheros deben ser respaldados, dump mantiene
una base de datos donde tiene informacion de cuando fue respaldado un
fichero en concreto.
Para saber entonces si un fichero tiene que ser respaldado o no, lo que
hacemos es utilizar los diferentes niveles de backup que tiene dump. En este
sentido comentar que decimos que dump realiza backups de nivel 0, hasta
nivel 9. Un backup de nivel 0 es un backup completo, es decir, no nos importa
cuando fue respaldado o modificado un fichero, pues todos seran respaldados
en este momento.
A partir de este momento, un nivel indica que ficheros seran respaldados
o no. El nivel nos indicara que realicemos un backup de los ficheros que hayan
sido modificados despues de un backup de nivel inferior. Veamos esto con un
ejemplo:
El lunes realizamos un backup de grado 0. El lunes por tanto tenemos un
backup completo del sistema.
El martes realizamos un backup de grado 2. En este sentido todos los
ficheros que hayan sido modificados desde el lunes pasaran a formar parte de
este backup del martes, pues el grado 0 es de nivel inferior a grado 2.
Si el miercoles realizamos un backup de grado 1, entonces solo respaldare-
mos lo ficheros que hayan sido modificados respecto a la copia que hicimos
el lunes. Todo lo que haya sido modificado despues del backup de grado 2 y
12.1. HERRAMIENTAS PROPIAS. 109

que estuviera respaldado con este backup no se guardara, pues el grado 1 es

inferior al grado 2.
De esta forma podremos configurarnos un sistema de backup muy con-
creto que tenga en cuenta todas las necesidades de nuestra institucion.
El backup realizado con dump podremos guardarlos en una cinta (el de-
fecto que utiliza dump si no especificamos ning un otro dispositivo), o en
cualquier dispositivo que permita almacenar la informacion de dump (dis-
quetes, discos duros, etc.)
La sintaxis de dump es sencilla, para realizar un backup total, un backup
de grado 0, teclearemos:
dump 0 -f /tmp/backup.dump /directorio-a-respaldar
donde -f indica el dispositivo en el que realizaremos el backup. En este caso
hemos elegido el defecto que utiliza dump, que es la unidad de cinta.
A la hora de recuperar los archivos del backup, utilizaremos el comando
restore. Este comando lo podremos ejecutar de forma interactiva:
restore -if /tmp/backup.dump
con lo que obtendremos un prompt en el que podremos ir accediendo (cd) y
listando (ls) los distintos directorios que conforman el backup. Para recuperar
uno de los archivos o directorios que tenemos en el backup tendremos que
ejecutar la orden add nombre-directorio y al final, cuando hayamos elegido
todos los ficheros / directorios que deseemos, simplemente ejecutaremos la
orden extract y para salir quit.
Debemos tener muy en cuenta que lo que recuperemos sera almacenado
en el directorio desde el que lanzamos la orden restore, por lo tanto debemos
ser muy cuidadosos en este punto, pues podemos sobreescribir con lo recuper-
ado los archivos que tuvieramos en este directorio. Es mas que conveniente,
antes de ejecutar la orden restore, crear un directorio temporal donde nos
cambiaremos antes de ejecutar el comando restore.

12.1.2. tar
El comando tar es muy utilizado a la hora de realizar copias de seguridad,
pues es facil de transportar (el fichero obtenido) y de utilizar en otros sistemas
(los ficheros tar se pueden leer en multitud de sistemas operativos).
Este comando ademas tiene la ventaja de guardar la estructura original,
pero ademas guardar tanto los propietarios de los ficheros como sus marcas
de tiempo.
La forma de trabajar con este comando es equivalente a cualquier uso que
podamos haber hecho de este comando, simplemente ejecutaremos:
tar -cvf fichero-respaldo.tar /directorio-a-respaldar
Al ser una herramienta muy conocida por los administradores de sistemas,
es muy utilizada para estas tareas administrativas.
110 CAPITULO 12. BACKUP

12.1.3. cp/scp
Si bien muchas veces no consideramos las herramientas mas comunes o
habituales para realizar tareas administrativas complejas, para realizar una
copia de respaldo los comandos cp o scp dan buenos resultados.
El comando cp nos permitira realizar una copia (utilizando las opciones
-r y -p) de estructuras completas que conserve los propietarios de los ficheros.
Esta copia la podremos hacer a cualquier dispositivo que tengamos accesible
en nuestro sistema, y la utilizacion de cp es ampliamente conocida por todos
los administradores, por lo tanto su implementacion en un sistema de backup
es trivial.
El comando scp es equivalente a cp, pero con la ventaja de que puede
utilizarse por red. La velocidad de transferencia de datos mediante scp es
muy superior a la de otras herramientas disponibles, y es que por ejemplo
realizar copias de seguridad por red, utilizando dump o tar, muchas veces
vienen acompa nadas del uso de NFS que tiene tasas de transferencia muy
lentas y que hacen muy lentas las copias de seguridad.
El comando scp nos pedira la contrase na del equipo remoto con el fin
de poder realizar el backup de los archivos desde o hacia este equipo. Esta
peticion siempre la podremos evitar si configuramos ssh con este fin.
Al poder realizar este u
ltimo paso, muchos administradores prefieren esta
herramienta pues es facilmente aplicable, configurable y genera estructuras
muy accesibles. Hay que tener en cuenta que el acceso a informacion respal-
dada mediante dump debe ser accedida mediante restore, y la informacion
contenida en un fichero tar debe ser previamente desempaquetada para poder
acceder a ella, mientras que las estructuras obtenidas con scp son tal cual las
tenamos en origen, por lo tanto el acceso a estos respaldos es inmediato.

12.1.4. rsync
Este comando es mas que interesante a la hora de realizar copia de respal-
do, pues realiza una copia completa de un directorio origen a un destino
especificado como cp o scp, pero a
nadiendo ciertas ventajas:

rsync nos va a permitir, si lo ejecutamos como root, que los ficheros

de respaldo tengan las mismas propiedades (propiedad y marcas de
tiempo) que los ficheros originales.

Si la copia se interrumpe, podremos volver a lanzar la orden y solo se

copiara lo que previamente no se copio.

Permite ser ejecutado en sesiones posteriores con el fin de que solo se

copien los ficheros que hayan sido creados / modificados con posteri-
oridad, sin necesidad de realizar una copia total de nuevo como en el
caso de cp / scp.
12.1. HERRAMIENTAS PROPIAS. 111

Se puede encapsular dentro de una sesion ssh, para poder realizar una
copia desde o hacia un equipo remoto.

Una ejecucion tpica de este comando puede ser:

rsync -avz -e ssh /directorio-a-respaldar

usuario-remoto@maquina-de-backup:/directorio-de-backup

Donde la opcion a realmente es una combinacion de opciones (rlptgoD)

que nos permiten realizar backups recursivamente (r), copiar los enlaces
simbolicos (l), preservar los permisos (p), preservar la modificacion de tiem-
pos (t), preservar el grupo (g), preservar el propietario (o) y preservar los
dispositivos y ficheros especiales (D).
La opcion v se utiliza para trabajar con un mayor control sobre el progra-
ma, ya que se nos mostraran mensajes sobre la ejecucion que en condiciones
normales no se consideran necesarios (modo verbose).
La opcion z sirve para comprimir los ficheros en la transferencia. Aumenta
la carga en la cpu de origen y de destino, pero minimiza el impacto sobre la
red.
Como habamos indicado rsync permite encapsular mediante ssh, esto lo
podemos realizar mediante la opcion e seguida de la palabra ssh.
Finalmente tenemos una sintaxis parecida a la de scp, donde indicamos un
origen y un destino. El origen y el destino pueden ser directorios locales, de tal
forma que u nicamente tendramos que especificar su nombre, pero tambien
pueden ser directorios en maquinas remotas, de tal forma que tendramos que
indicar la forma de llegar a ellos gracias al usuario remoto que nos permitira el
acceso as como la IP o nombre de la maquina remota.
Captulo 13

Control de logs.

113
114 CAPITULO 13. CONTROL DE LOGS.

El sistema de logs de un ordenador es fundamental, y curiosamente es

lo menos utilizado. Cualquier anomala que presente el sistema operativo, o
la mayora de los programas instalados en nuestro sistema, dejara un rastro,
un comentario sobre lo ocurrido, en un fichero de registro, que nos permi-
tira poder solucionar el problema y as evitar que vuelva a ocurrir.
Logs hay de muchos tipos, desde errores mnimos en el uso de aplicaciones,
hasta intentos fallidos de entrada en el sistema. Nosotros nos centraremos en
los logs de seguridad, si bien mucho de lo que se hable a continuacion tambien
se puede aplicar a cualquier tipo de registro.
Fundamentalmente el demonio que gestiona los logs del sistema es rsyslog,
que se debe arrancar al inicio de la maquina y siempre debe estar operativo, es
decir, debemos asegurarnos de que en todos los directorios /etc/rc?.d (salvo
en los de reinicio y apagado por supuesto), exista un enlace simbolico que
comience por S y que apunte al demonio rsyslog (/etc/init.d/rsyslog), pues
si no tenemos bien configurado este punto, es posible que cuando cambiemos
de nivel de ejecucion se pare el demonio rsyslog y por lo tanto perderemos
todos los datos que posiblemente nos alerten de intrusiones.
Por supuesto lo primero que intenta hacer un hacker al acceder al sistema
es hacerse con el sistema de registro. Habitualmente se eliminan los rastros
de la entrada en el sistema, y se prepara el demonio para que no registre nada
de la actividad del hacker, para que este demonio siga haciendo su trabajo
y no alerte su ausencia de registros al administrador, pero que lo que reciba
este sea erroneo.
Es fundamental por lo tanto que estos registros se transfieran a otro
sitio diferente del ordenador cuanto antes, pues el hacker en este tipo de
operaciones estara rapidamente atrapado, ya que le sera muy complicado
evitar que los registros lleguen a manos del administrador si estos se han
transferido rapidamente a una cuenta de correo electronico en un servidor
externo, o bien se han transferido los logs tal cual a otro ordenador. Este
tipo de actuaciones se pueden realizar directamente desde la configuracion del
propio rsyslog, con herramientas que procesen los registros de forma rutinaria
o bien con trucos de administracion como por ejemplo copias programadas o
sincronizacion con otros ordenadores.

13.1. rsyslog.
La configuracion de este demonio la tenemos en el fichero
/etc/rsyslog.conf que esta compuesto de lneas que definen diferentes polticas
de registro.
Cada una de estas lneas esta compuesta de dos columnas. En la primera
se define la actividad y el grado de seriedad de los registros y en la segunda
donde quedaran grabados. Por ejemplo podemos tener la lnea:

cron.* /var/log/cron
13.1. RSYSLOG. 115

con la cual queremos decir que cualquier mensaje que provenga del cron,
quedara registrado en el fichero /var/log/cron. Hemos especificado cualquier
mensaje porque tenemos el smbolo * despues del punto que separa el proceso
que genera informes de la gravedad de los mismos. Si queremos registrar solo
ciertos mensajes del cron, lo que deberemos hacer es cambiar el asterisco
por el ndice de gravedad que deseemos, siendo estos, ordenados de menor a
mayor gravedad:

* debug. Mensaje de depuracion.

* info. Mensaje informativo.

* notice. Condicion normal, pero significativa.

* warning. Hay condiciones de advertencia.

* warn. El mismo caso que warning. En desuso.

* err. Hay condiciones de error.

* error. El mismo caso que err. En desuso.

* crit. Las condiciones son crticas.

* alert. Se debe tomar una accion correctora inmediatamente.

* emerg. El sistema esta inutilizable.

* panic. El mismo caso que emerg. En desuso.

Es decir, si queremos que cron registre solamente las entradas informativas

en el fichero /var/log/cron.info, tendramos que escribir:

cron.info /var/log/cron.info

Si precedemos al nombre del fichero donde queremos guardar el registro,

el smbolo menos (-), no sincronizaremos el disco despues de la escritura,
para mejorar las prestaciones de la maquina (sobre todo cuando realizamos
muchos registros de este tipo), pero hay que tener en cuenta que una cada
de la maquina con esta configuracion hara perder los u
ltimos registros (no
sincronizados).
Las facilidades sobre las que podemos guardar registros son:

* auth. Mensajes de seguridad o autorizacion. Es conveniente utilizar no

obstante authpriv.

* authpriv. Mensajes de seguridad o autorizacion.

* cron. Mensajes relacionados con el cron.

116 CAPITULO 13. CONTROL DE LOGS.

* daemon. Mensajes realacionados con otros demonios del sistema.

* kern. Mensajes del n
ucleo.
* lpr. Mensajes del subsistema de impresion.
* mail. Mensajes del subsistema de correo electronico.
* mark. Para uso interno exclusivamente, no debe usarse en aplicaciones.
* news. Mensajes del subsistema de news.
* security. El mismo caso que auth. En desuso.
* user. Mensajes genericos del nivel de usuario.
* uucp. Mensajes del sistema uucp.
* local0. Reservado para uso local.
* local7. Reservado para uso local.
Es decir, si queremos que todos los mensajes de naturaleza crtica, rela-
cionados con el kernel, se queden reflejados en el fichero
/var/log/kernel.critico, tendramos que configurar este fichero con la sigu-
iente lnea:
kern.crit /var/log/kernel.critico
En una misma lnea podemos incluir diferentes entradas, es decir, pode-
mos volcar a un mismo fichero diferentes fuentes de mensajes, para ello ten-
dremos que separar cada instancia mediante una coma si queremos utilizar el
mismo nivel de generacion de logs, o mediante un punto y coma si queremos
que sea diferente, es decir:
kern,mail.crit /var/log/mensajes.criticos
registrara todas las entradas crticas de mail y kern en /var/log/mensajes.-
criticos, mientras que:
kern.debug;mail.crit /var/log/mensajes.criticos
registrara todas las entradas crticas de mail y las entradas debug de kern
en el mismo fichero.
Ademas hay que tener en cuenta que podemos hacer uso de cualquier
fichero en nuestro sistema para registrar entradas de log. Como en linux
podemos decir que cualquier dispositivo se comporta como un fichero, lo que
podemos hacer es pasar mensajes por ejemplo a la consola, para ello lo u nico
que tendremos que hacer es escribir /dev/console en vez del archivo que
tuvieramos en mente, haciendose este tipo de configuraciones para mensajes
realmente preocupantes, como todos aquellos mensajes de emergencia que
produce el kernel:
kern.emerg /dev/console
13.2. LOGWATCH. 117

13.2. Logwatch.
Los logs deberan leerse a diario, ya que es la unica manera de saber el
estado de nuestra maquina. Ya que puede llegar a ser complicado su lectura,
ya que estamos hablando de diferentes archivos a los que tendremos que
acceder diariamente, discriminando las entradas ledas con anterioridad de las
no ledas, lo que suele hacerse es instalar (o programar) una herramienta que
genere informes de forma rutinaria que sean mandados por correo electronico,
de tal forma que podamos, diariamente por ejemplo, tener una idea correcta
del funcionamiento de nuestra maquina.
Una herramienta muy utilizada para este fin es Logwatch, herramienta
desarrollada con el fin de generar informes sencillos de leer por el admin-
istrador. Una vez tenemos instalada esta utilidad, deberamos configurarla
editando el fichero logwatch.conf debiendo modificar al menos las siguientes
tres entradas, si bien, como en todos los ficheros de configuracion, deberamos
examinar cada uno de los defectos que nos aparece para garantizarnos que
se acomodan a nuestra configuracion.

* MailTo = root

* Range = yesterday

* Detail = High

La primera nos sirve para configurar la cuenta de correo electronico a

la que queremos que mande el informe, en el ejemplo se dirigira al usuario
root. En la segunda entrada recogemos el rango del que queremos hacer
el informe, si programamos la tarea por ejemplo en el cron, la podemos
programar por ejemplo a las doce y un minuto de la noche, y as, con este
rango, justo en el primer minuto del nuevo da nos mandara un informe
con la actividad del da que acaba de terminar. En cuanto a la u ltima lnea,
comentar que se refiere al detalle con el que queremos que se realice el informe,
siendo conveniente que sea un detalle alto para que podamos tener toda la
informacion de nuestro sistema y no solamente parcial, si bien los informes
seran mucho menos rapidos de analizar.
Captulo 14

Sistema de cuotas.

119
120 CAPITULO 14. SISTEMA DE CUOTAS.

Un sistema de archivos que contemple cuotas es imprescindible en muchos

sistemas Linux. Hay que tener en cuenta que en un principio no hay discri-
minacion entre usuarios, y que cada uno de ellos puede alcanzar la capacidad
maxima del sistema de archivos donde tiene su home.
Salvo que tuvieramos un sistema de archivos independiente para cada uno
de los usuarios (algo impracticable y carente de sentido), si no existieran cuo-
tas asignadas a los directorios personales de los usuarios, cualquiera de ellos
podra ocupar todo el espacio que deseara, con el consiguiente contratiempo
para el resto de los usuarios.
Hay que tener en cuenta que el sistema de cuotas depende del kernel, por
lo tanto lo primero que hay que hacer es recompilar el kernel para que admita
la nueva version de cuotas, para ello lo que necesitamos es que este activa la
variable:

CONFIG_QFMT_V2=y

que esta en el men u File Systems, bajo el apartado VFS v0 quota format
support. Es muy probable que esta opcion este ya elegida en el kernel actual,
por lo tanto sera conveniente, antes de recompilarlo, comprobar en el fichero
de configuracion que se uso para este kernel si esta opcion estaba habilitada
o no.
Una vez que arrancamos con este kernel nuevo, lo que hacemos es modi-
ficar el fichero /etc/fstab incluyendo las opciones usrquota y grpquota en las
particiones donde queramos activar las cuotas a usuarios y grupos respecti-
vamente:

/dev/sda3 /home ext4 defaults,usrquota,grpquota 1 2

A partir de este momento, cada vez que montemos la particion sda3, se

activiran las cuotas de usuario y de grupo de tal forma que podremos hacer
uso de ellas e impedir por tanto que cualquier usuario almacene mas datos
de los que creamos convenientes.
Acabamos de comentar que debemos montar esta particion. Si ya estu-
viera montada, la podremos remontar sin mas que teclear:

mount -o remount /home

y chequeamos este sistema de archivos para que se generen los ficheros de

quotas con la informacion pertinente, esto lo hacemos tecleando:

/sbin/quotacheck -avugc

que buscara en todos los sistemas de archivos donde esten definidas la opcion
de cuotas, y creara los ficheros de cuotas. Debemos tener cuidado pues la op-
cion c es crear, aunque existan previamente, los ficheros de cuotas. En futuras
ejecuciones de quotacheck deberamos preguntarnos si realmente necesitamos
 121

esta opcion o podemos seguir utilizando los ficheros que ya tenemos. Deber-
emos prescindir de esta opcion por tanto en la mayora de los casos, y solo
utilizarla la primera vez que lo ejecutemos y si hemos tenido alg
un problema
con el sistema de cuotas.
Inmediatamente activaremos las quotas, para ello tecleamos:

quotaon -a

que activa las cuotas en todos los sistemas de archivos que tengan la opcion
de cuotas.
A partir de este momento ya podemos obtener las quotas de los sistemas
de archivos tecleando:

repquota /sistema-de-archivos

para ver las quotas de usuarios y:

repquota -g /sistema-de-archivos

para ver las quotas de grupos.

Podemos modificar las cuotas, tanto de usuarios como de grupos, sin mas
que teclear

edquota usuario

equota -g grupo

respectivamente.
Si queremos que un usuario recien creado tenga la misma cuota que otro,
lo que podemos hacer es teclear:

edquota -p usuario-original usuario-nuevo

donde usuario-original es un usuario que ya exista y usuario-nuevo el usuario

recien creado.
Si queremos que todos los usuarios tengan las mismas cuotas que tiene el
usuario pablo, podremos teclear:

cat /etc/passwd|cut -d : -f 1|grep -v pablo|while read user

do
edquota -p pablo $user
done
122 CAPITULO 14. SISTEMA DE CUOTAS.

Si nos fijamos correctamente, para activar el sistema de cuotas hemos

ejecutado un par de comandos (quotacheck y quotaon). Estos comandos por
tanto deben ser ejecutados cada vez que la maquina se inicie, por lo tanto la
forma mas comoda de llevarlo a cabo es crear un script que ejecute estos co-
mandos ordenadamente, y especificar que se ejecute siempre que se arranque
la maquina.
Un script que podramos utilizar podra ser:

#!/bin/bash

. /etc/init.d/functions

case "$1" in
start)
if [ -x /sbin/quotacheck ]
then
echo "Comprobando las cuotas. Puede llevar
su tiempo."
/sbin/quotacheck -avug
RETVAL=$?
fi
if [ -x /sbin/quotaon ]
then
echo "Arrancando las cuotas."
/sbin/quotaon -avug
RETVAL=$?
fi
;;
stop)
if [ -x /sbin/quotaoff ]
then
echo "Parando las cuotas."
/sbin/quotaoff
RETVAL=$?
fi
;;
*)
echo $"Usage: $0 {start|stop}"
exit 1
esac

exit 0

Si copiamos este script a /etc/init.d, podremos crear los enlaces simbolicos

correpondientes, en los directorios rc?.d necesarios, de tal forma que siempre
 123

que alcancemos estos niveles de ejecucion tendremos la seguridad de tener

activado el sistema de cuotas.
Captulo 15

Wake On Lan.

125
126 CAPITULO 15. WAKE ON LAN.

Cuando un administrador tiene un laboratorio de simulacion a su cargo,

que habitualmente esta a cierta distancia de su lugar de trabajo habitual, un
proceso que suele llevar bastante tiempo es arrancar todos los ordenadores
cuando se va a llevar a cabo un curso en el mismo.
Para evitar tener que ir a la sala e ir arrancando ordenador a ordenador,
podemos utilizar una facilidad que tienen ya la mayora de los ordenadores
existentes, que es Wake On Lan (WOL), que permite arrancarlos en remoto,
mandandoles una se nal concreta por red.
Primero tenemos que activar el WOL en los ordenadores, para ello a-
rrancamos el ordenador y accedemos a la BIOS. Si bien el men u que nos
encontremos puede variar mucho de un ordenador a otro, probablemente en-
contraremos un submen u relacionado con Power Management Setup o Wake
On Lan y habilitaremos esta opcion, saliendo de la BIOS grabando los cam-
bios realizados (salvo que no estemos seguros de haber realizado cualquier
otro cambio).
Y a partir de este momento podremos arrancar en remoto cualquiera de
estas maquinas, sin mas que ejecutar:

ether-wake MAC

donde MAC es la direccion MAC del ordenador remoto que tiene que ser
arrancado.
Captulo 16

Otras tareas administrativas.

127
128 CAPITULO 16. OTRAS TAREAS ADMINISTRATIVAS.

Las tareas del administrador muchas veces no pueden ser catalogadas con
un nombre concreto, no podemos decir que todos los lunes debemos hacer
algo en concreto, sino mas bien el trabajo cotidiano dependera de tantas
variables que es practicamente determinarle a priori.
No obstante hay varios comandos o aplicaciones que vamos a necesitar en
muchas ocasiones, o nos van a resultar de bastante ayuda en nuestro trabajo
cotidiano:

16.1. strace
Este comando nos permite realizar una traza de las llamadas al sistema y
se
nales que tiene la ejecucion que pasemos a este comando como argumento.
Es muy probable que alguno de nuestros usuarios nos pregunte por que tiene
un problema en concreto con un programa. Muchas veces la solucion de estas
cuestiones es practicamente inmediata debido a la diferencia de experiencia
entre el usuario y el administrador, pero otras muchas veces es muy compli-
cado conseguir la solucion del problema.
Para estar seguro de los pasos que realiza un comando en concreto, cada al
sistema, podemos utilizar strace, viendo as los posible problemas que pode-
mos estar teniendo en esta ejecucion para poder dar una solucion correcta al
usuario.
La ejecucion, por ejemplo, del comando hostname sabemos que nos da
como resultado una u nica lnea con el nombre de la maquina. Si ejecutamos
strace hostname
obtendremos unas 64 lneas, que nos describiran todos los pasos que ha real-
izado el sistema para darnos este resultado.
Con esto queremos decir que la informacion obtenida mediante este co-
mando debe ser tomada con tranquilidad, pues muchas veces es extremada-
mente densa, pero siempre de gran utilidad, pues gracias a ella podremos
obervar si hay alguna librera que no es encontrada o que tiene alguna irreg-
ularidad, explicaciones que sin la ejecucion de strace sera claremente com-
plicado obtener.

16.2. Ejecuci
on en varias m
aquinas.
Cuando tenemos que administrar un cluster con varios equipos, la mayora
de las veces estos son exactamente iguales, clones los unos de los otros, de tal
forma que es muy habitual tener que ejecutar el mismo comando en todos y
cada uno de ellos.
Esto, que de forma teorica parece terriblemente sencillo, puede ocuparnos
mucho tiempo innecesario.
Algo que podemos hacer para evitar estas demoras es permitir el acceso
mediante ssh sin contrase na. Por su puesto esta practica es muy insegura,
16.3. INTEGRIDAD DE LAS PARTICIONES. 129

pues si accedemos a la maquina principal, podremos acceder a cualquier otra,

pero si tenemos actualizados los sistemas, con anti troyanos, con tcpwrappers
y con una configuracion robusta de cortafuegos, la inseguridad que se plantea
con esta utilidad es menor que las ventajas que obtendremos.
Hay que tener en cuenta que lo que necesitamos es que las maquinas del
cl
uster acepten la entrada desde una maquina de administracion (lo contrario
no es necesario). Para ello lo que haremos en la maquina de administracion
es ejecutar:

ssh-keygen -t rsa

Pulsando enter en cada una de las preguntas, para aceptar los defectos (in-
cluso no establecer contrase
na).
Copiamos entonces el contenido de /var/root/.ssh/id rsa.pub en el archi-
vo $HOME/.ssh/authorized keys de la maquina a la que queramos entrar sin
contrasenya, es decir, a todas las maquinas del cl
uster.
De esta forma ya podramos teclear, en la maquina de administracion:

ssh maquina-remota hostname

y ejecutara el comando hostname en la maquina del cl

uster correspondiente.
Por supuesto lo interesante de este punto es crear un programa que nos
permita realizar la ejecucion de comandos en todos los equipos del cl uster,
para ello lo que podramos hacer es crear un bucle que ejecutara el comando
en todas y cada una de estas maquinas:

for maquina in "maquina1 maquina2 maquinan"

do
ssh $maquina $@
done

de tal forma que si este script le hemos llamado entodas, podramos ejecutar:

entodas hostname

y obtendramos el resultado de esta ejecucion en todas y cada una de las

maquinas del cl
uster.

16.3. Integridad de las particiones.

Cada vez que arrancamos un equipo, el sistema realiza una comprobacion
de las particiones si es necesario. Este proceso se realiza cuando ha pasado
un numero determinado de das desde la u ltima vez que se realizo la com-
probacion.
Teniendo en cuenta que los sistemas con Linux pueden permanecer mucho
tiempo arrancados, quizas es necesario realizar esta comprobacion sin esperar
al reinicio de la maquina.
130 CAPITULO 16. OTRAS TAREAS ADMINISTRATIVAS.

El comando que utilizaremos entonces es fsck, al que daremos la opcion -t

seguido del tipo de sistema de archivos de la particion que queramos escanear.
Esta orden la ejecutaremos sobre cada una de las particiones a analizar,
teniendo siempre en cuenta que la mejor forma de comprobarlas es cuando
estas no estan montadas, pues si lo estan la ejecucion del comando puede
resultar peligrosa, afectando a la informacion que se genere en el momento
de la ejecucion.
La forma de ejecutarlo entonces es sencilla, si queremos comprobar la
particion /dev/sda3 de nuestro sistema, ejecutaremos:

fsck -t ext3 /dev/sda3

16.4. Desfragmentaci
on.
Si somos usuarios de sistemas operativos de Microsoft, la desfragmentacion
formara parte de nuestras vidas, pues muchas veces habremos accedido a
los programas de desfragmentacion facilitados con el fin de aumentar el
rendimiento del sistema.
Este tipo de utilidades son de gran utilidades en sistemas de archivos como
fat32, ya que los archivos son creados al principio del disco y en orden, de tal
forma que si queremos aumentar el contenido de un archivo, lo mas probable
es que no podamos hacerlo a continuacion en el disco duro pues seguro que
ya tendremos algo mas grabado, necesitando por tanto que este archivo se
fragmente, es decir, lo que escribamos de nuevo tendra que ser almacenado
no a continuacion del archivo, sino donde haya espacio disponible en el disco.
En otros sistemas de archivos, como ext3 y ext4 (utilizados en Linux de
forma mayoritaria), no existe este tipo de problemas, pues lo que se hace es
tender a utilizar todo el disco duro.
Cuando escribimos un archivo, este se posiciona en una zona determinada
de la particion correspondiente. Al generar otro archivo, el sistema operati-
vo no lo posiciona a continuacion del primero, sino en cualquier otra zona
del disco. De esta forma podremos modificar el primero, aumentandolo en
tama no, sin tener que fragmentarlo, pues a continuacion lo mas probable es
que no haya nada.
Con este metodo lo que hacemos es permitir la utilizacion por igual de
todas las zonas del disco duro y ademas evitar la fragmentacion en gran
medida, por tanto es innecesario desfragmentar archivos en particiones ext3
o ext4.
Captulo 17

Actualizaciones.

131
132 CAPITULO 17. ACTUALIZACIONES.

Las actualizaciones son imprescindibles en cualquier sistema operativo,

bien sea de Microsoft, bien sea UNIX, de Apple, Linux, etc.
Los sistemas operativos son un compendio de miles de lneas de codigo
que contienen errores inevitablemente. Estos errores son descubiertos bien
por una b usqueda activa con el fin de mejorar los sistemas operativos o para
intentar valerse de vulnerabilidades encontradas para acceder a los sistemas.
Una vez es conocido un fallo en el operativo, la publicacion de un parche
para corregir el error es cuestion de tiempo.
Algunos sistemas operativos, como los desarrollados por Microsoft, man-
tienen la poltica de publicar las actualizaciones una vez al mes, mientras que
otros sistemas operativos, como Linux, suelen publicar las actualizaciones tan
pronto son obtenidas.
Cada distribucion de Linux suele tener una forma distinta de manejar
estas actualizaciones, pero todas tienen la misma idea com un:
Comprobar que software tenemos instalado. Buscar nuevas versiones del
software. Instalar las nuevas versiones.
En las distribuciones Linux no solo vamos a obtener las actualizaciones del
sistema operativo en s, sino tambien de la mayora del software que tenemos
instalado en el ordenador, de tal forma que es un proceso mucho mas rapido
y compacto que en otros sistemas operativos.
Las herramientras mas utilizadas para la actualizacion son:

yum
apt-get
yast

17.1. yum
yum (Yellowdog Updater Modified), es una herramienta que cada vez
se esta implementando con mayor intensidad en distribuciones que utilizan
paquetes de instalacion rpm, como por ejemplo Fedora Core.
Esta herramienta nos permite lista el software que tenemos instalado en
nuestro equipo, borrar paquetes que no necesitemos, instalar los que creamos
oportunos y actualizar por supuesto.
Para actualizar el sistema simplemente tendremos que teclear:

yum update -y

de tal forma que actualizara los paquetes que sean necesarios. La opcion -
y permitira que yum actualice el sistema sin nuestra interaccion, es decir,
asumira yes para las preguntas que tuviera necesidad de plantear en inter-
activo. Con esta opcion por tanto podremos programar esta tarea sin mayor
problema, de tal forma que, por ejemplo, todas las noches se ejecute y por
lo tanto el sistema se actualice.
17.2. APT-GET 133

17.2. apt-get
Esta aplicacion es nativa de la distribucion Debian, y por tanto es uti-
lizada en todas las distribuciones que se basan en Debian. Ademas esta he-
rramienta ha sido portada a otras distribuciones, de tal forma que ya no es
necesario utilizar paquetes .deb para poder utilizar esta herramientas, sino
que podemos tener sistemas operativos que utilicen paquetes .rpm por ejem-
plo, y poder utilizar apt-get.
La forma de utilizar este comando es equivalente a yum, es decir, ten-
dremos la posibilidad de listar el software que tenemos instalado en nuestro
equipo, podremos instalar nuevos paquetes, eliminar los que ya no nos in-
teresen y por supuesto actualizar el equipo.
Para realizar este u
ltimo punto, la actualizacion del equipo, ejecutaremos:

apt-get upgrade -y

que realizara una comprobacion de las actualizaciones del software instalado

en nuestro equipo, y las instalara sin realizar preguntas en interactivo, ya
que le hemos incluido la opcion -y.
Es conveniente sincronizar los paquetes que tenemos con respecto a sus
fuentes, para ello antes de ejecutar este comando sera interesante ejecutar:

apt-get update -y

Por supuesto la actualizacion mediante estos comandos tambien debe pro-

gramarse como una tarea diaria, con el fin de tener perfectamente actualizado
nuestro sistema.

17.3. yast
La herramienta yast la utiliza la distribucion SuSE. Esta herramienta
es una sucesion de men us que nos permiten realizar practicamente todas la
tareas de administracion.
Con respecto a yast comentar que hay autenticos forofos de esta herra-
mienta, pero tambien autenticos detractores, ya que muchas veces act
ua como
una verdadera caja negra.
Cuando arrancamos esta herramienta nos encontramos con una serie de
men us (17.1). Para poder programar la actualizacion del sistema tendremos
que elegir por tanto Actualizacion en lnea.
Dentro de este men u (17.2), encontraremos que podemos realizar una
actualizacion del sistema en este momento, pero tendremos que elegir Con-
figurar actualizaci
on totalmente para programar esta tarea.
Finalmente accederemos a un men u (17.3) en el que simplemente ten-
dremos que elegir cuando queremos realizar esta actualizacion automatica.
134 CAPITULO 17. ACTUALIZACIONES.

Figura 17.1: Aspecto de la herramienta yast. Accederemos al men u -

Actualizacion en lnea- para realizar una actualizacion del sistema.
17.3. YAST 135

Figura 17.2: Dentro del menu -Actualizacion en lnea-, elegiremos -Configurar

actualizacion totalmente- para programar la actualizacion.
136 CAPITULO 17. ACTUALIZACIONES.

Figura 17.3: Para llevar a cabo la actualizacion automatica del sistema, ele-
giremos la hora a la que querremos que se actualice.