ADMINISTRADOR

Enero, 2008

1
 INDICE DE CONTENIDO

INTRODUCCIÓN................................................................................
...........................4
OBJETIVO GENERAL...........................................................................
..........................5
OBJETIVOS ESPECÍFICOS............................................................................................5
INSTALACIÓN SEGURA DE LINUX...................................................................
..............6
Elección de los medios de instalación.....................................................................6
HERRAMIENTAS GENÉRICAS DE ADMINISTRACIÓN......................................................6
EL SISTEMA LINUX COMO ROUTER..................................................................
............7
CORTAFUEGOS............................................................................................................
.8
Clasificación de Cortafuegos ..................................................................................8
Terminología de Cortafuegos......................................................................
.............9
FIREWALLS SOBRE LINUX.......................................................................
...................12
Iptables.........................................................................................................
.........13
Firewall Personal Firestarter.................................................................................
..15
Configuración.........................................................................
...............................16
SEGURIDAD...................................................................................
............................18
ARCHIVOS DEL SISTEMA....................................................................................
........20
/etc/passwd.........................................................................
..................................20
/etc/shadow....................................................................................
.......................20
/etc/groups..........................................................................
..................................20
/etc/gshadow..................................................................................
.......................20
/etc/login.defs.............................................................................................
...........21
/etc/shells..................................................................................
............................21
/etc/securetty........................................................................
................................21
Seguridad de archivos / Sistema de archivos........................................................21
PLUGGABLE AUTHENTICATION MODULES (PAM).......................................................22
SEGURIDAD DE CONTRASEÑAS...................................................................
..............23
Almacenamiento de Contraseñas......................................................................
....24
SEGURIDAD BÁSICA DE SERVICIOS DE RED..............................................................24

2
 ps...................................................................................................................
........24
lsof..............................................................................................................
...........25
ARCHIVOS BÁSICOS DE CONFIGURACIÓN DE RED....................................................25
tcp_wrappers.......................................................................................
..................26
TCP/IP Y SEGURIDAD DE REDES................................................................................27
Mejorar los aspectos de TCP/IP..................................................................
............27
Seguridad PPP....................................................................
...................................28
Seguridad IP (IPSec).................................................................
.............................29
DOMAIN NAME SYSTEM (DNS)...........................................................................
........29
El archivo host.conf.......................................................................
........................30
Variables de entorno.............................................................................................
.31
LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP).............................................32
OpenLDAP ........................................................................................................
.....32
Configuración de OpenLDAP .............................................................................
....32
Servicios de Directorio y LDAP..............................................................................33
Herramientas Gráficas de Administración.............................................................35
Descripciones ..............................................................................
.........................35
SHELLS Y SCRIPTS..................................................................................
...................36
Shells interactivos....................................................................
.............................37
Shells Disponibles.............................................................................................
.....40
Programación scripts en Bash...............................................................................42
Variables en Bash............................................................................
......................43
Comparaciones..............................................................................................
........44
OPTIMIZAR EL SISTEMA.........................................................................
....................45
Resolver los problemas de memoria principal.......................................................45
Mucha utilización de CPU......................................................................................46
Reducir el número de llamadas..............................................................
...............46
Mucha utilización de disco...................................................................................
..47
ENLACES DE INTERÉS...........................................................................................
.....48

3
 INTRODUCCIÓN

Los profundos cambios sociales exigen a los ciudadanos el aprendizaje de toda una serie de
herramientas básicas indispensables para desenvolverse en la nueva sociedad, la Sociedad
de la Información. El Sistema Operativo GNU/Linux ha tenido un gran auge en los últimos
años y cada vez son más las personas que optan por este sistema como herramienta de
trabajo para llevar a cabo su labor diaria.

El módulo de Administrador tiene como propósito fundamental preparar a profesionales para

administrar adecuadamente servidores bajo Sistema Operativo GNU/Linux,
proporcionándoles los conocimientos prácticos para ello y generándoles un sentido de
análisis y creatividad para que puedan actuar adecuadamente ante las diversas situaciones
en su trabajo diario.

La labor de un Administrador del Sistema Operativo GNU/Linux en el mundo laboral actual,

exige un alto nivel de conocimientos técnicos que deben ser aplicados de forma exitosa para
garantizar un alto nivel en la calidad de servicios, sin embargo, es necesario ir más allá para
lograr el uso de los recursos técnicos y humanos de forma eficiente. En este sentido, este
módulo profundiza los conceptos y técnicas vistas en el módulo de soporte así como adiciona
nuevos conceptos referentes a los distintos servicios que puede proveer un servidor bajo
GNU/Linux y cuál es la mejor forma de implementarlos.

4
OBJETIVO GENERAL

Capacitar al participante para administrar adecuadamente servidores bajo Sistema Operativo

GNU/Linux

OBJETIVOS ESPECÍFICOS

Al finalizar el curso el participante estará en la capacidad de:

 Instalar el Sistema Operativo GNU/LINUX Debian Etch de manera segura.

 Aplicar la automatización de tareas mediante la programación de scripts.

 Manejar las herramientas genéricas de administración.

 Instalación y configuración de cortafuegos

 Configurar y administrar eficientemente los servicios de autenticación de usuarios

de red.

5
INSTALACIÓN SEGURA DE LINUX

Una adecuada instalación de Linux es el primer paso para tener un sistema estable y seguro.
Hay varios trucos que hacen más fácil la instalación, así como algunos asuntos que es mejor
llevarlos a cabo durante la instalación como la estructura de un disco duro.

Elección de los medios de instalación

Este es el elemento número uno, que afectará a la velocidad de instalación y en buena

medida la seguridad. Uno de los métodos preferidos por los usuarios es la instalación vía ftp,
ya que colocar temporalmente una tarjeta de red en una máquina es algo rápido e indoloro, y
alcanzar velocidades superiores a 1 Megabyte/seg acaba siendo una instalación rápida.

La instalación desde el CD-ROM suele ser la más fácil, ya que se puede arrancar desde
ellos, el Linux encuentra el CD sin tener que apuntar a directorios o tener que preocuparse
por los nombres de archivos con mayúsculas o minúsculas (al contrario que ocurre en la
instalación basada en disco duro). Se trata de un medio original de Linux.

 FTP – rápida, requiere una tarjeta de red, y un servidor de ftp.

 HTTP – también rápida, y algo más segura que hacer una llamada a un FTP público
Samba.

 NFS – no tan rápida, pero puesto que el NFS está implementado en la mayoría de las
redes UNIX existentes.

 CDROM– si se tiene un lector de CDROM rápido, la mejor apuesta es introducir el CD

y arrancar desde él, pulsar ENTER unas cuantas veces y ya está listo. Ahora, se
puede arrancar desde la mayoría de los CDROM's de Linux.

 Disco duro – generalmente la más tediosa, las ventanas confunden los nombres de
archivo, la instalación desde una partición ext2 suele ser algo menos tediosa.

 Imágenes ISO en CD.

HERRAMIENTAS GENÉRICAS DE ADMINISTRACIÓN

En el campo de la administración, también se pueden tomar en cuenta algunas herramientas,

como las pensadas de forma genérica para la administración:

6
  Linuxconf: esta es una herramienta genérica de administración donde se agrupan los
diferentes aspectos de administración en una interfaz de menús textual; ésta se puede
utilizar en casi cualquier distribución GNU/Linux, y soporta diversos detalles propios de
cada una.

 Webmin: esta es otra herramienta de administración pensada para una interfaz Web;
funciona con una serie de plugins que pueden se añadidos para cada servicio que se
desea administrar; normalmente cuenta con formularios donde se especifican los
parámetros de configuración de los servicios; además, ofrece la posibilidad, si se
activa, de permitir la administración remota desde cualquier máquina con navegador.

 Los entornos de escritorio de Gnome y KDE se sirven del concepto de “Panel de

control”, el cual permite la gestión, tanto el aspecto visual de las interfaces gráficas,
como tratar algunos parámetros de los dispositivos del sistema.

EL SISTEMA LINUX COMO ROUTER

Un sistema Linux puede funcionar haciendo la función de router, simplemente se conecta a

dos o más redes y sabiendo, a partir de su tabla de rutas, por qué interfaz puede alcanzar
cada red, dirige los paquetes entre una y otra red. Este será un funcionamiento como router
estático. Para ello es necesario que la característica IP forwarding (o routing entre interfaces)
esté activada en el núcleo del sistema. Si no está activada, cuando llegue un paquete por
una interfaz, no podrá dirigirse hacia otra interfaz, porque no estará permitido el routing entre
ellos.

Se puede comprobar si está activo el IP forwarding con el comando:

[root@linux entrega04-1]# cat /proc/sys/net/ipv4/ip_forward

En este caso, la salida 0 indica que no está activado el routing del kernel. Se puede activar
mediante el comando:

#echo 1 >/proc/sys/net/ipv4/ip_forward

Los dos métodos siguientes, harían el cambio permanente. El primero consiste en cambiar el
archivo de configuración del kernel (/etc/sysctl.conf), colocando el siguiente valor:

7
 net.ipv4.ip_forward = 1

Otra opción para que Linux funcione como router, es la de instalar un servidor especializado
de routing en nuestro sistema Linux. La sola capacidad de routing, nos permite conectar
varias redes, pero nos surge otro problema mayor: la seguridad. Esto hace que la mayoría de
sistemas Linux (y no Linux) que interconectan redes, incorporen capacidades de seguridad,
como los cortafuegos.

CORTAFUEGOS

Un cortafuegos (o firewall) es un componente o conjunto de componentes que restringen el

acceso entre una red protegida e Internet, o entre varias redes. Incluye tanto componentes
hardware como software, configuraciones y definición de políticas de seguridad.

Esquema de red con cortafuegos

Su propósito es doble, proteger los sistemas y servicios internos de los ataques del exterior, y
controlar los accesos hacia Internet de nuestros usuarios.

Clasificación de Cortafuegos

Según el nivel de la pila de protocolos sobre el que trabajan, se pueden clasificar los
cortafuegos en:

 Cortafuegos de Nivel de red: el control de tráfico a nivel de red consiste en analizar

todos los paquetes que llegan a una interfaz de red, y decidir si se les deja pasar o no,
en base al contenido de los mismos: protocolo, dirección de origen, dirección de
destino, puerto origen y puerto destino fundamentalmente.

Su operación se asemeja a la de un guardia de tráfico que en un cruce decide qué

8
 carros pueden pasar y cuáles no, dependiendo de su origen y su destino. Puesto que
analizar esta información es muy sencillo, este tipo de cortafuegos suelen ser muy
rápidos y transparentes al usuario. Se suelen denominar de filtrado de paquetes
(packet a filter). Una mejora sobre este tipo de cortafuegos, serían los de Inspección
de Estado (Stateful Inspection) que además, inspeccionan en el interior de los
paquetes para comprobar si cumplen las políticas de seguridad.

 Cortafuegos de Nivel de Aplicación: se basan en la instalación de intermediarios

(proxies), también conocidos como pasarelas (application gateways). El cliente,
situado en un lado del cortafuegos, habla con un intermediario situado en el propio
cortafuegos. Este intermediario lo identifica, registra sus peticiones y, si está permitido,
las encamina hacia el verdadero servidor situado al otro lado del cortafuegos. La
contestación regresa por el mismo camino, quedando igualmente registrada.

El control se hace interceptando las comunicaciones a nivel de aplicación, modificando

el protocolo para incluir medidas adicionales de seguridad. El cortafuegos debe
conocer los detalles del protocolo de cada servicio que intercepta, analizar su correcto
funcionamiento y añadir los pasos de control precisos a los mismos. Por ejemplo,
squid es un proxy que debe conocer el protocolo HTTP para recoger las peticiones de
los navegadores cliente y redirigirlas al servidor destino. El cortafuegos es, por tanto,
mucho más inteligente y posee a un control más fino de todo el proceso de
comunicación, aunque esto supone una mayor carga de trabajo y penalización en
eficiencia. Además, normalmente exigen realizar modificaciones en la aplicación del
usuario, como por ejemplo, decirle al navegador que utilice el proxy.

Terminología de Cortafuegos

En una arquitectura de sistema cortafuegos, encontramos una serie de términos o

componentes como son:

 host bastión: (también se denomina gates) es un sistema especialmente asegurado,

pero que puede recibir ataques por estar accesible desde Internet. Tiene como función
ser el punto de contacto de los usuarios de la red interna de una organización con otro
tipo de redes. El host bastión filtra tráfico de entrada y salida, y también oculta la
configuración de la red hacia fuera.

9
  filtrado: también se conoce como screening, y a los dispositivos que lo implementan se
les denomina chokes.

De la combinación de estos elementos, filtrado y host bastión, surgen las siguientes

arquitecturas de cortafuegos:

 Cortafuegos de filtrado de paquetes (Screening Router ): un firewall sencillo puede

consistir en un dispositivo capaz de filtrar
paquetes, un choke. Basado en aprovechar
la capacidad de algunos routers -
denominados screening routers para hacer
un enrutado selectivo, es decir, para
bloquear o permitir el tránsito de paquetes
mediante listas de control de acceso en
función de ciertas características de las
tramas, de forma que el router actúe como
pasarela de toda la red.

 Dual-Homed Host (Host en dos

zonas): este modelo de cortafuegos
está formado por máquinas equipadas
con dos tarjetas de red y denominadas
dual-homed hosts, en las que una de
las tarjetas se conecta a la red interna
para proteger y la otra a la red externa.
En esta configuración el choke y el
bastión coinciden en el mismo equipo.

10
 Screened Host: un paso más en términos de seguridad de los cortafuegos es la
arquitectura screened host o choke-gate,
que combina un router con un host
bastión, y donde el principal nivel de
seguridad proviene del filtrado de
paquetes (es decir, el router es la primera
y más importante línea de defensa). En la
máquina bastión, único sistema accesible
desde el exterior, se ejecutan los proxies
de las aplicaciones, mientras que el
choke se encarga de filtrar los paquetes que se puedan considerar peligrosos para la
seguridad de la red interna, permitiendo únicamente la comunicación con un reducido
número de servicios.

 Screened Subnet (DMZ): la arquitectura Screened Subnet, también conocida como

red perimetral o Zona Desmilitarizada (De-Militarized Zone o DMZ) añade un nivel más
de seguridad en las arquitecturas de cortafuegos, situando una subred (la DMZ) entre
las redes externa e interna, de forma que se consiguen reducir los efectos de un
ataque con éxito al host
bastión. En los modelos
anteriores, si la seguridad
del host bastión se ve
comprometida, la amenaza
se extiende
automáticamente al resto de
la red. Como la máquina
bastión es un objetivo
interesante para muchos
piratas, la arquitectura DMZ intenta aislarla en una red perimetral de forma que un
intruso que accede a esta máquina, no consiga un acceso total a la subred protegida.

Screened subnet es la arquitectura más segura, pero también la más compleja; se

utilizan dos routers, denominados exterior e interior, conectados ambos a la red

11
 perimetrala. En esta red DMZ, que constituye el sistema cortafuegos, se incluye el
host bastión y también se podrán incluir sistemas que requieran un acceso controlado,
como batería de modems, el servidor web o el servidor de correo, que serán los
únicos elementos visibles desde fuera de nuestra red.

FIREWALLS SOBRE LINUX

Los cortafuegos pueden estar basados en la combinación de un hardware y un software

especializado, constituyendo cajas preparadas para realizar esa función, como por ejemplo
los Nokia o IP, los Cisco PIX o las cajas de StoneSoft. Otros, sin embargo, están construidos
sobre un sistema operativo de propósito general, que se blinda y prepara para funcionar
como cortafuegos. En este caso, podemos tener un sistema operativo Solaris, Windows o
Linux sobre los que se ejecuta un software como el Firewall-1 de Check Point.

Linux se puede encontrar en las dos opciones. Hay empresas que utilizan linux sobre un
hardware específico, dando una caja lista para ser utilizada como cortafuegos, como el
iForce de Sun Microsystems. También podemos coger un sistema Linux sobre un PC e
instalar un cortafuegos. Lo más normal, en ambos casos, es utilizar las características de
cortafuegos que incorpora el propio kernel de Linux: iptables.

Un sistema cortafuegos puede ofrecer sus servicios a una red que se sitúa detrás de él,
denominándose cortafuegos de la red, o el cortafuegos protege a la propia máquina en la
que se ejecuta, denominándose cortafuegos personal.

Para un cortafuegos de red, se puede utilizar distribuciones especializadas, que incorporan

facilidades de administración por medio de navegador, integran proxys y utilidades
adicionales. Se puede encontrar en este segmento a SmoothWall (www.smoothwall.org) o
IPCop (www.ipcop. org). El proceso a seguir consiste en descargarse la imagen ISO de la
distribución, grabar el CD e iniciar la instalación. El proceso es muy guiado y va haciendo las
preguntas correspondientes para configurar el cortafuegos a gusto del usuario.

Para un cortafuegos personal, trabajamos con nuestra distribución favorita y se configura

iptables para añadir seguridad. Sin embargo, el trabajar directamente con iptables puede ser
muy engorroso y existen interfaces gráficas que nos permiten la configuración y el trabajo de
forma más fácil.

12
Iptables

La principal herramienta de cortafuegos para Linux a partir de los kernels 2.4 es iptables,
estos reemplazan al anterior ipchains de los kernels de la versión 2.2 y a ipfwadm de los
kernels 2.0. La función de iptables es la de establecer, mantener e inspeccionar las reglas de
filtrado de paquetes IP en el núcleo de Linux.

Iptables decide qué paquete de información puede pasar, según unos criterios que se
almacenan en unas listas. Las listas se componen de reglas con un orden determinado,
donde la última regla introducida será la última regla en aplicarse.

Cuando un paquete llega, se mira en qué lista debe aplicarse. En esa lista (iptables las llama
tablas) se empieza por la primera regla. Si la regla no es aplicable al paquete, se pasa a la
siguiente regla. Cuando una regla es aplicable (match) al paquete, se ejecuta la acción que
haya sido definida en la regla (descartar el paquete, aceptarlo, enrutarlo, etc).

Recorrido de un paquete utilizando iptables

Cuando iptables recibe el paquete (1), se comprueba si el destino final es nuestra propia
máquina o es otra, porque estemos funcionando como router/gateway o cortafuegos. Para
los paquetes que van a la propia máquina se aplican las reglas INPUT (2) y para paquetes
que van a otras redes o máquinas se aplican las reglas FORWARD (4). Las reglas de
OUTPUT (3) se aplican cuando un paquete es enviado desde nuestra máquina al exterior.
INPUT,OUTPUT y FORWARD son los tres tipos de reglas de filtrado (FILTER). Antes de
aplicar esas reglas es posible aplicar reglas de NAT y de MANGLE.

13
La estructura de un comando iptables es la siguiente :

iptables -t [tabla] -[opciones] [regla] [criterio] -j [acción]

donde cada elemento significa lo siguiente:

 -t [tabla] --> esta parte del comando especifica cuál es la tabla en la que aplicamos la
regla. Existen 3 tipos de tablas: FILTER, NAT y MANGLE, siendo filter la tabla por
defecto si se omite esta parte del comando.

Filter, es la tabla donde se añaden las reglas relacionadas con el filtrado de paquetes.
Nat, se refiere a las conexiones que serán modificadas por el firewall, como por
ejemplo, a enmascarar conexiones, realizar redirecciones de puertos, etc. y Mangle
es parecido a Nat, pero tiene la posibilidad de modificar más valores del paquete.

 -[opciones] --> las opciones básicas del comando son las siguientes :

A, para añadir (Append ) una regla.

L, es para listar (List) las reglas.

F, es para borrar (Flush) todas las reglas o en el caso de que INPUT,

FORWARD o OUTPUT sean dados como argumento, se borrarán las reglas
asociadas sólo a esa clase.

P, establece la política (Policy) por defecto del firewall. Por defecto es

aceptar todas las conexiones.

 [regla] --> reglas válidas son INPUT, FORWARD y OUTPUT.

 [criterio] --> aquí es donde se especificarán las características del paquete que
casará con esta regla. Algunos ejemplos son:

-s : dirección de origen (source). Puede ser una dirección IP o una red. -s

192.168.1.0/24

-d : dirección de destino. -d 84.56.73.3

-p : tipo de protocolo (TCP,UDP,ICMP). -p TCP

-sport : puerto de origen

14
 -dport: puerto de destino --dport 23

-i = in-interface : el interfaz por el que se entra -i eth0

-o = -out-interface: el interfaz por el que se sale -o ppp0

 -j [accion] --> aquí establecemos qué es lo que hay que hacer con el paquete. Las
posibles acciones son :

ACCEPT: aceptar el paquete.

REJECT o DROP: desechar el paquete. La diferencia entre ellos reside en

que DROP descartará el paquete silenciosamente y REJECT emitirá un
paquete ICMP Port Unreachable, indicando que está cerrado el puerto.

REDIRECT redirigir el paquete a donde se indique en el criterio del

comando.

LOG archiva el paquete para su posterior análisis.

Hay dos maneras de implementar un firewall, según la política por defecto que
especifiquemos:

 Política por defecto ACEPTAR: se aceptan por defecto todos los paquetes. Sólo se
denegará lo que se diga explícitamente. El equivalente será la política de acceso a un
bingo: pueden entrar todas las personas, excepto aquellas cuyo DNI aparezca en la
lista de acceso prohibido.

 Política por defecto DENEGAR: Todo está denegado, y sólo se permitirá pasar por el
firewall aquello que se permita explícitamente. El equivalente sería el acceso a la
cámara de cajas de seguridad de un banco. El acceso está prohibido a todo el mundo
y se habilita una lista de personas autorizadas a entrar. Para un cortafuegos, se
recomienda aplicar esta política por defecto.

Firewall Personal Firestarter

En realidad es un interface gráfico para iptables, muy útil para configurar nuestro
cortafuegos, ya sea como cortafuegos personal o como cortafuegos para proteger una red.
Lo primero que haremos es instalarlo. Para ello utilizamos el siguiente comando:

15
 #apt-get install firestarter

Podemos lanzar el cortafuegos ejecutando desde la línea de comandos #firestarter. Esta

opción mostrará las conexiones activas en nuestra máquina en tiempo real.

Configuración

La forma más fácil es con el asistente, que podemos llamar desde la entrada Cortafuegos y
Ejecutar asistente, desde el menú principal.

Si pulsamos Adelante, pasamos a una ventana en la que se puede seleccionar el interfaz de

nuestro sistema que se conecta a Internet. En esta opción estamos seleccionando el firewall
personal que protege nuestra máquina del mundo exterior. Además, seleccionamos que el
cortafuegos se active al conectarnos a Internet.

16
La siguiente pantalla nos permite decidir si el firewall de nuestro sistema además funcionará
como pasarela para otros sistemas, convirtiéndose en el guardián de nuestra red. Para ello,
debemos contar con otra interfaz de red distinta de la anterior, que se conectará a la red
protegida. En este caso, como solamente queremos un firewall personal, no activamos la
opción Activar la compartición de la conexión a Internet. Si quisiéramos que éste sea el
cortafuegos de nuestra red, debemos especificar la interfaz conectada a la red de área local
interna y si queremos activar el servidor de DHCP para dar direcciones automáticamente.

17
Ya se ha terminado una configuración básica del cortafuegos para uso personal. Podemos
guardar las reglas e iniciar el cortafuegos.

SEGURIDAD

Hoy en día existen muchos elementos que afectan la seguridad de un computador. Por
ejemplo:

 ¿Está en red la máquina?

 ¿Hay cuentas interactivas de usuarios (telnet/ssh)?

 ¿Se utilizan las máquinas como estaciones de trabajo o se trata de un servidor?

Esta última es de gran relevancia, pues las Estaciones de Trabajo y los Servidores
tradicionalmente son muy diferentes, aunque la línea se difumina con la introducción de
potentes y baratos PCs, a medida que los sistemas operativos se aprovechan de ello. Sin
embargo, la principal diferencia entre los computadores no suele estar en el hardware, ni
siquiera en el Sistema Operativo, sino en los paquetes de software que traen instalados y en
el modo en que los usuarios acceden a la máquina (interactivamente, en la consola, etc.). En
este sentido, se mencionan algunas reglas de carácter general que permitirán ahorrar
bastantes penurias:

 Mantener a los usuarios alejados de los servidores. Es decir, no proporcionarles shells

de login interactivos, a menos que sea un requerimiento absoluto.

18
  Bloquear las estaciones de trabajo.

 Utilizar la criptografía allí donde sea posible para almacenar claves en texto simple,
números de tarjetas de crédito y otro tipo de información delicada.

 Escanear regularmente la red en busca de puertos abiertos, software instalado que no

debería estar ahí, compararlo con resultados anteriores.

Es importante resaltar que la seguridad no es una solución, es un modo de vida. Hablando

en términos generales, las estaciones de trabajo/servidores son utilizados por gente que no
se suele preocupar en absoluto por la tecnología que llevan por debajo, lo único que quieren
es tener listo su trabajo y recoger su correo de forma periódica. Sin embargo, hay muchos
usuarios que tendrán la habilidad suficiente como para modificar sus estaciones de trabajo,
para bien o para mal. A esto hay que añadirle que la mayoría de los usuarios tienen acceso
físico a sus estaciones de trabajo, lo cual quiere decir que hay que bloquearles el acceso si
se quiere hacer las cosas bien.

 Utilizar las claves de las BIOS para mantener a los usuarios alejados de la BIOS.

 Configurar la máquina para que arranque únicamente del disco duro adecuado.

 No dar acceso de root a los usuarios, utilizar sudo para proporcionar acceso a
comandos privilegiados cuando sea necesario.

 Utilizar cortafuegos para que incluso si se instalan servicios estos no sean accesibles
al resto del mundo.

 Observar regularmente la tabla de procesos, puertos abiertos, software instalado,

entre otros en busca de cambios.

 Establecer políticas de seguridad escrita que los usuarios puedan entender, y

fortalecerla.

 Borrar todo tipo de objetos peligrosos (ejemplo, compiladores), a menos que sean
necesarios en un sistema.

Con la configuración adecuada, una estación Linux es casi a prueba de usuarios (nada es
100% seguro), y generalmente mucho más estable.

19
ARCHIVOS DEL SISTEMA

/etc/passwd

El archivo de contraseñas es sin discusión el archivo más crítico en Linux (y en la mayoría de

otros Unix). Contiene el mapa de nombres de usuarios, identificaciones de usuarios y la ID
del grupo primario al que pertenece esa persona. También puede contener el archivo real,
aunque es más probable (y mucho más seguro) que utilice contraseñas con shadow para
mantener las contraseñas en /etc/shadow.

Las contraseñas se guardan utilizando un hash de un sólo sentido (el hash utilizado por
defecto es crypt, las distribuciones más nuevas soportan MD5, que es significativamente más
robusto). Las contraseñas no pueden obtenerse a partir de la forma cifrada, sin embargo, se
puede tratar de encontrar una contraseña utilizando fuerza bruta para pasar por el hash
cadenas de texto y compararlas, una vez que encuentres una que coincide, sabes que has
conseguido la contraseña. Esto no suele ser un problema por sí mismo, el problema surge
cuando los usuarios escogen claves que son fácilmente adivinables.

/etc/shadow

El archivo de shadow alberga pares de nombres de usuario y contraseñas, así como

información contable, como la fecha de expiración, y otros campos especiales. Este archivo
debería protegerse a toda costa, y sólo el root debería tener acceso de lectura a él.

/etc/groups

El archivo de grupos contiene toda la información de pertenencia a grupos, y opcionalmente

elementos como la contraseña del grupo (generalmente almacenado en gshadow en los
sistemas actuales). Un grupo puede no contener miembros (por ejemplo, no está usado),
sólo un miembro o múltiples miembros, y la contraseña es opcional (y no se suele usar).

/etc/gshadow

Similar al archivo shadow de contraseñas, este archivo contiene los grupos, contraseñas y
miembros. De nuevo, este archivo debería ser protegido a toda costa, y sólo el usuario root
debería tener permiso de lectura al mismo.

20
/etc/login.defs

Este archivo permite definir algunos valores por defecto para diferentes programas como
useradd y expiración de contraseñas. Tiende a variar ligeramente entre distribuciones e
incluso entre versiones, pero suele estar bien comentado y tiende a contener los valores por
defecto.

/etc/shells

El archivo de shells contiene una lista de shells válidos, si el shell por defecto de un usuario
no aparece listado aquí, quizás no pueda hacer login interactivamente.

/etc/securetty

Este archivo contiene una lista de tty's desde los que el root puede hacer un login. Los tty's
de la consola suelen ir de /dev/tty1 a /dev/tty6. Los puertos serie son /dev/ttyS0 y superiores
por lo general.

Si se quiere permitir al root hacer login vía red, entonces se debe añadir /dev/ttyp1 y
superiores (si hay 30 usuarios conectados y el root intenta conectar, el root aparecerá como
procedente de /dev/ttyp31). Generalmente, sólo se debería permitir conectar al root desde
/dev/tty1, y es aconsejable deshabilitar la cuenta de root, sin embargo antes de hacer esto,
se debe instalar sudo o un programa que permita al root acceder a comandos.

Seguridad de archivos / Sistema de archivos

En Linux, el sistema de archivos ext3 (EXTendido, versión 3). Algo así como el standard
UNIX de toda la vida soporta permisos de archivos (lectura, escritura, ejecución, sticky bit,
suid, guid, etc.), propiedad de archivos (usuario, grupo, otros), y otro tipo de estándares.

Una de sus desventajas es que no se puede hacer journaling. Sin embargo, Linux tiene
excelente software RAID, soportando bastante bien los Niveles 0, 1 y 5 (RAID no tiene que
ver con la seguridad, pero por supuesto tiene que ver con la estabilidad).

Las utilidades básicas para interactuar con archivos son: "ls", "chown", "chmod" y "find".
Otras incluyen ln (para creación de enlaces), stat (muestra información de un archivo) y
muchas más. En cuanto a la creación y mantenimiento de sistemas de archivos por sí
mismos, se tienen "fdisk" (el viejo fdisk), "mkfs" (MaKe FileSystem, que formatea

21
particiones), y "fsck" (FileSystem ChecK, que suele arreglar problemas).

Un sistema Linux se puede comprometer con facilidad si se consigue acceso a ciertos

archivos, por ejemplo la capacidad para leer un archivo de claves sin shadow da como
resultado la posibilidad de ejecutar contraseñas cifradas contra crack, encontrando con
facilidad las contraseñas débiles.

La mayor parte de la seguridad son los permisos de usuarios. En Linux, un archivo es

'propiedad' de 3 entidades separadas, un Usuario, un Grupo y Otros (que es el resto). El
usuario root es el que puede asignar a qué usuario pertenece un archivo y a qué grupo,
puede también cambiar los permisos de un archivo y ver/editar el mismo.

Linux no aporta todavía protección a los usuarios sobre el root (lo cual muchos lo consideran
algo bueno). Igualmente, cualquiera que sea dueño del directorio en que está el objeto (sea
un usuario/grupo/otros con los permisos adecuados sobre el directorio padre) puede,
potencialmente, editar los permisos (y puesto que el root es dueño de / puede hacer cambios
que involucren cualquier lugar del sistema de archivos).

PLUGGABLE AUTHENTICATION MODULES (PAM)

PAM para Linux, es una suite de librerías compartidas que permiten al administrador local del
sistema escoger cómo autentifican a los usuarios las aplicaciones. PAM introduce una capa
de middleware entre la aplicación y el mecanismo real de autentificación. Una vez que el
programa está PAMificado, podrá ser utilizado por el programa cualquier método de
autentificación que soporte PAM. Además de esto, PAM puede manejar cuentas y datos de
sesiones, lo cual no suelen hacer bien los mecanismos habituales de autentificación.

Por ejemplo, usando PAM se puede deshabilitar con facilidad el acceso de login a los
usuarios normales entre las 6pm y las 6am, y cuando hagan login, se les puede autentificar
vía escáner retinal. Por defecto, los sistemas las versiones más recientes de Debian son
conscientes de PAM.

De esta forma, en un sistema con soporte PAM, todo lo que se debe hacer para implementar
el shadow en contraseñas es convertir los archivos de contraseñas y de grupos, y
posiblemente añadir una o dos líneas a algunos archivos de configuración de PAM (si no las
tienen ya añadidas).

22
En resumen, PAM proporciona una gran cantidad de flexibilidad al manejar la autentificación
de usuarios con el único requerimiento de uno o dos módulos PAM para manejarlo. Es
necesario este tipo de flexibilidad si se pretende que Linux sea un sistema operativo de tipo
empresarial. Las distribuciones que no vengan como "PAMificadas" se pueden convertir, pero
requiere mucho esfuerzo ya que se tiene que recompilar todos los programas con soporte
PAM, instalar PAM, entre otras. En este sentido, probablemente sea más fácil cambiarse a
una distribución PAMificada si va a suponer un requisito.

Otros beneficios de un sistema orientado a PAM es que ahora se puede hacer uso de un
dominio NT para autentificar usuarios, lo cual quiere decir que se pueden plantar estaciones
Linux en una red Microsoft ya existente sin tener que comprar NIS / NIS+ para NT y pasar
por todo el proceso de instalarlo.

SEGURIDAD DE CONTRASEÑAS

En todo sistema operativo tipo UNIX se dan varias constantes, y una de ellas es el archivo
/etc/passwd y la forma en que funciona. Para que la autentificación de usuario funcione
correctamente se necesitan (como mínimo) algún tipo de archivo(s) con UID a mapas de
nombres de usuarios, GID a mapas de nombres de grupos, contraseñas para todos los
usuarios y demás información variada. El problema es que todo el mundo necesita acceso al
archivo de contraseñas y durante muchos años, la solución ha sido bastante simple y
efectiva, simplemente, se hace un hash de las contraseñas y se guarda el hash, cuando un
usuario necesite autentificar, toma la contraseña que introduce, la pasa por el hash y si
coincide, evidentemente se trataba de la misma contraseña. El problema que tiene esto es
que la potencia computacional ha crecido enormemente, y ahora se puede tomar una copia
del archivo de contraseñas e intentar abrirlo mediante fuerza bruta en una cantidad de tiempo
razonable. Para resolver esto hay varias soluciones:

 Utilizar un algoritmo de hashing "mejor", como MD5.

 Almacenar las contraseñas en alguna otra parte. Linux ha implementado la segunda

desde hace tiempo, se llama contraseñas con shadow. En el archivo de contraseñas,
se reemplaza la contraseña por una 'x', lo cual le indica al sistema que verifique tu
contraseña contra el archivo shadow (se hace lo mismo con el archivo de grupos y sus
contraseñas).

23
Almacenamiento de Contraseñas

Esto es algo que la mayoría de los usuarios no suelen tener en cuenta. ¿Cómo se pueden
almacenar las contraseñas de forma segura? El método más obvio es memorizarlas, pero
suele tener sus inconvenientes, si se administran 30 sitios diferentes, por lo general se
tendrán 30 contraseñas diferentes, y una buena contraseña tiene más de 8 caracteres de
longitud, y por lo general no es la cosa más fácil de recordar. Esto conduce a que mucha
gente utilice la misma contraseña en diferentes sistemas. Una mejor opción es almacenar las
contraseñas en un formato cifrado, generalmente de forma electrónica en el computador o en
el palm pilot, de forma que sólo hay que recordar una contraseña para desbloquear el resto.
Para esto se puede utilizar algo tan simple como PGP o GnuPG.

SEGURIDAD BÁSICA DE SERVICIOS DE RED

ps

El programa ps muestra el estado de procesos (información disponible en el sistema de

archivos virtual /proc). La opción más comúnmente utilizada es "ps -xau", que muestra algo
así como toda la información que siempre se quiere saber.

La forma más fácil de aprender a leer la salida de ps es irse a la página del manual de ps y
aprender a qué se refiere cada campo (la mayoría se explican por sí mismos, tales como el
% CPU, mientras que algunos como SIZE son un poco más oscuros: SIZE es el número de
páginas de memoria de 4k que está utilizando un programa).

Para averiguar qué programas se están ejecutando, una apuesta segura es hacer 'man
<nombre_de_comando>'; lo cual casi siempre suele sacar la página del manual que
pertenece a ese servicio (como httpd). Te darás cuenta de que servicios como telnet, ftpd,
identd y otros no aparecen aunque estén ahí. Esto es debido a que se ejecutan desde inetd,
el "superservidor".

Para encontrar estos servicios, se debe mirar en /etc/inetd.conf o en la salida de "netstat -vat"
la cual informa acerca de casi cualquier cosa relacionada con la red. Es especialmente
buena para sacar listados de conexiones y sockets activos. Al usar netstat se puede
encontrar qué interfaces están activas y en qué puertos.

24
lsof

lsof es un práctico programa cuya idea es similar a la de ps, excepto en que muestra qué
archivos/etc están abiertos, lo cual puede incluir sockets de red. Desafortunadamente, el lsof
mucha información, de modo que será necesario utilizar grep o redireccionarlo mediante less
("lsof | less") para hacerlo más cómodo de leer.

ARCHIVOS BÁSICOS DE CONFIGURACIÓN DE RED

Hay varios archivos de configuración importantes, que controlan qué servicios ejecuta Linux y
cómo lo hacen. Muchos de ellos se encuentran en diferentes localizaciones dependiendo de
cómo se instalará Linux y los servicios. Los lugares habituales son:

 archivo de configuración del servidor Inetd:

/etc/inetd.conf

archivos de inicio de varios tipos: /etc/rc.d/* /etc/*

Lo mejor que se puede hacer es imaginarse qué servicios se quieren ejecutar, y

deshabilitar/borrar el resto.

inetd.conf es el responsable de iniciar los servicios, generalmente aquellos que no necesitan

ejecutarse de continuo, o que están basados en sesiones (como telnet o ftpd). Ello es debido
a que la sobrecarga que supondría ejecutar un servicio constantemente (como telnet) sería
mayor que el costo de inicio ocasional cuando el usuario quisiera utilizarlo.

Para algunos servicios (como DNS) que sirven a muchas conexiones rápidas, la sobrecarga
de arrancar servicios cada pocos segundos sería mayor que tenerlo constantemente
ejecutándose. De igual forma ocurre con servicios como DNS y el correo, donde el tiempo es
crítico, sin embargo unos pocos segundos de retraso en empezar una sesión de ftp no le
hacen daño a nadie. El servicio en sí se llama inetd y se ejecuta al arrancar, de modo que se
le puede parar/arrancar/recargar manipulando el proceso inetd. Cada vez que se hagan
cambios a inetd.con, hay que reiniciar inetd para hacer efectivos los cambios, killall –1 inetd
lo reiniciará correctamente. Como de costumbre, las lineas del inetd.conf se pueden
comentar con un # (lo cual es una forma muy simple y efectiva de deshabilitar servicios como
rexec). Se aconseja desabilitar tantos servicios de inetd.conf como sea posible, por lo

25
general los que se suelen usar son ftp, pop e imap. Se debería reemplazar telnet y los
servicios por el SSH y servicios como systat/netstat y finger proporcionan demasiada
información. El acceso a programas arrancados por inetd se puede controlar con facilidad
mediante el uso de TCP_WRAPPERS.

tcp_wrappers

Usar tcp_wrappers hace que el asegurar servidores contra intrusos externos sea bastante
simple. tcp_wrappers se controla desde dos archivos:

/etc/hosts.allow /etc/hosts.deny

Primero se comprueba hosts.allow, y las reglas se comprueban desde la primera a la última.

Si encuentra una regla que permita específicamente entrar (por ejemplo, una regla que
permita entrar al host, dominio, máscara de subred, etc.) y deja conectarse al servicio. Si no
se puede encontrar ninguna regla que corresponda en hosts.allow, entonces va a comprobar
hosts.deny en busca de una regla que deniegue la entrada. De nuevo se comprueban las
reglas de hosts.deny desde la primera a la última, y la primera regla que encuentre que
deniega acceso (por ejemplo, una regla que deshabilite el host, dominio, máscara de subred,
etc.) significa que no deja entrar. Si tampoco se puede encontrar una regla que deniegue la
entrada, entonces por defecto deja entrar.

Si se deja activado un servicio que no debería figurar en inetd.conf y no se tiene una política
de denegación por defecto, se pueden tener problemas. Es más seguro (y lleva un poco más
de trabajo, pero a la larga es menor que tener que reinstalar el servidor) tener reglas de
denegación por defecto para el cortafuegos y tcp_wrappers, de modo que si se olvida algo
por accidente, por defecto no tendrá acceso. Si se instala algo para lo cual necesitan tener
acceso los usuarios y se olvida poner reglas, enseguida se quejarán y se podrá rectificar el
problema rápidamente. Fallar por precaución y denegar accidentalmente algo es más seguro
que dejarlo abierto.

/etc/services

El archivo de servicios es una lista de números de puertos, el protocolo y el nombre

correspondiente. El formato es: nombre-de-servicio puerto/protocolo alias # comentario
(opcional). Por ejemplo: time 37/udp timserver

26
 rlp 39/udp resource # localización de recursos

name 42/udp nameserver

whois 43/tcp nicname # generalmente al sri-nic

domain 53/tcp

domain 53/udp

Por ejemplo, este archivo se utiliza cuando se ejecuta 'netstat -a', y por supuesto no se utiliza
cuando se ejecuta 'netstat -an'.

TCP/IP Y SEGURIDAD DE REDES

El TPC/IP se creó en una época y en una situación donde la seguridad no era algo que
concerniera demasiado. Inicialmente, 'Internet' (entonces llamada Arpanet), consistía en unos
pocos hosts, todo eran sitios académicos, grandes empresas o gobiernos. Todo el mundo se
conocía, y acceder a Internet era un asunto serio. La suite de protocolos TCP/IP es bastante
robusta, pero no está prevista para la seguridad (por ejemplo, autentificación, verificación,
cifrado, etc.).

Interceptar paquetes, leer la carga de los datos, y demás, es algo bastante fácil en el Internet
de hoy en día. Los ataques más comunes son los ataques de negación de servicio, ya que
son los más fáciles de ejecutar y los más difíciles de impedir, seguidos del sniffing de
paquetes, escaneo de puertos y otras actividades relacionadas.

Los nombres de hosts no apuntan siempre a la dirección IP correcta, y las direcciones IP's no
siempre se pueden resolver al nombre de host adecuado. Si es posible, no se debe utilizar
autentificación basada en nombres de hosts. Puesto que el envenenamiento de cachés DNS
es algo relativamente sencillo, confiar la autentificación en una dirección IP reduce el
problema al spoofing, lo cual es algo más seguro, pero de ningún modo completamente
seguro. No existen mecanismos extendidos para verificar quién envió los datos y quién los
está recibiendo, excepto mediante el uso de sesiones o cifrado a nivel IP.

Mejorar los aspectos de TCP/IP

Se examina la red con el comando atsar, o también con netstat -i o con netstat -s | more,
para analizar si existen paquetes fragmentados, errores, drops, overflows, entre otros, que

27
puedan estar afectando a las comunicaciones y con esto al sistema; por ejemplo, en un
servidor de NFS, NIS, Ftp o Web.

Si se detectan problemas, se debe analizar la red para considerar las siguientes actuaciones:

 Fragmentar la red a través de elementos activos que descarten paquetes con

problemas, o que no son para máquinas del segmento.

 Planificar dónde estarán los servidores para reducir el tráfico hacia éstos, así como
también los tiempos de acceso.

 Ajustar los parámetros del kernel (/proc/sys/net/), por ejemplo, para obtener mejoras
en el throughput hacer: echo 600 > /proc/sys/net/core/netdev max backlog (por defecto
300).

Seguridad PPP

PPP permite conexiones TCP/IP, IPX/SPX y NetBEUI sobre líneas serie, la esencia de una
conexión PPP consiste en dos dispositivos informáticos (un computador, un Palm Pilot, un
servidor de terminales, entre otros, conectados sobre enlaces de serie. Ambos extremos
llaman al PPP, se negocia la autentificación y se establece el enlace. PPP no tiene soporte
real para cifrado, de modo que si se necesita un enlace seguro hay que invertir en algún tipo
de software VPN.

La mayoría de los sistemas llaman a PPP de la siguiente manera: se hace un login al equipo
y luego se invoca al login shell del PPP; por supuesto que esto significa que el nombre de
usuario y contraseña se envían en texto claro sobre la línea, y que hay que tener una cuenta
en ese tipo de equipo. En este caso el PPP no negocia la autentificación en absoluto.

Un método algo más seguro de gestionarlo es utilizar PAP (Password Authentification

Protocol - Protocolo de Autentificación de Contraseñas). Mediante PAP, la autentificación se
hace internamente mediante PPP, de modo que no se requiere una cuenta real en el
servidor. Sin embargo el nombre de usuario y la contraseña se siguen enviando en texto
claro, pero al menos el sistema es algo más seguro dada la inexistencia de cuentas de
usuario reales.

El tercer (y mejor) método para la autentificación es utilizar CHAP (Challenge Handshake

28
Authentication Protocol, Protocolo de Autentificación Desafío-Respuesta). Ambas partes se
intercambian llaves públicas y las utilizan para cifrar los datos que se envían durante la
secuencia de autentificación, de modo que el nombre de usuario y la contraseña están
relativamente a salvo de intrusos, y sin embargo las transmisiones de datos se hacen con
normalidad.

Seguridad IP (IPSec)

Seguridad IP (IPSec) es el cifrado del tráfico de red. No se puede cifrar la información de la

cabecera ni el trailer, pero se puede cifrar la carga útil. Esto permite asegurar protocolos
como POP/WWW sin tener que cambiarlos de ninguna forma, puesto que el cifrado se hace
en el nivel IP. También permite conectar de forma segura LANs y clientes entre sí, sobre
redes inseguras (como Internet).

DOMAIN NAME SYSTEM (DNS)

El direccionamiento en TCP/IP se basa en números de 32 bits. Evidentemente, esos

números no son fáciles de recordar, mientras que si lo es el nombre que se le asigna a cada
máquina. Existe una aplicación que es capaz de traducir nombres a direcciones IP, y es
conocida como sistema de resolución de nombres (DNS), la cual es
una aplicación que encuentra la dirección IP correspondiente a una máquina de la que se
conoce su nombre, no se tienen que incluir rutinas para ello, ya que en las librerías
estándares (libc) existen ya rutinas preparadas, como gethostbyname(3) o gethostbyaddr(3).

En otros sistemas las rutinas se encuentran en otras librerías distintas de la libc pero esto no
sucede en Linux. Al conjunto de rutinas que hacen estas tareas se les conoce como “sistema
de resolución”. En una red pequeña no es difícil mantener una tabla /etc/hosts en cada
máquina, y modificarla. Pero resulta complicado cuando hay muchas máquinas ya que, en
principio, cada una necesita una copia de /etc/hosts.

Una solución a esto es compartir esta y otras bases de datos con el NIS, o sistema
desarrollado por Sun Microsystems y conocido también como de información de red páginas
amarillas. En este caso, las bases de datos como la de /etc/hosts se mantienen en un
servidor NIS central y los clientes accederán a ellas de forma transparente al usuario. En
todo caso, esta solución solo es aconsejable para redes pequeñas o medianas, ya que
implican mantener un archivo central /etc/hosts que puede crecer mucho, y luego distribuirlo

29
entre los servidores NIS.

En Linux, como en muchos otros sistemas Unix, el servicio de nombres se realiza mediante
un programa llamado named. Al iniciarse, carga un conjunto de archivos maestros en su
cache y espera peticiones de procesos locales o remotos.

Cuando hablamos del “sistema de resolución”, no nos referiremos a una aplicación en

particular, sino a la biblioteca de resolución es decir, un conjunto de funciones que pueden
encontrarse en las bibliotecas estándar del lenguaje C. Las rutinas principales son
gethostbyname(2) y gethostbyaddr(2), que buscan la dirección IP de una máquina a partir
del nombre y viceversa. Es posible configurarlas para que simplemente miren en el archivo
hosts local (o remoto, si se usa NIS). Otras aplicaciones, como smail, pueden incluir
diferentes rutinas para esto y necesitan cierto cuidado.

El archivo host.conf

El archivo host.conf es fundamental para controlar la configuración del sistema de resolución

de nombres. Se encuentra en el directorio /etc e indica al sistema de resolución que servicios
debe usar y en que orden.

Las opciones del archivo host.conf deben estar en lineas distintas. Los campos deben
separarse por blancos (espacios o tabuladores). Las opciones disponibles son las siguientes:

 order: determina el orden en el que los servicios de resolución se usan. Opciones

válidas son bind para usar el servidor de nombres, hosts para buscar en /etc/hosts y
nis para buscar con NIS. Puede especificarse cualquiera de las anteriores, y el orden
de aparición determina qué servicio se prueba en primer lugar para intentar resolver el
nombre.

 multi: va con las opciones on u off y determina si una máquina del archivo /etc/hosts
puede tener distintas direcciones IP o no. Esta opción no tiene efecto en peticiones vía
NIS o DNS.

 nospoof: DNS le permite encontrar un nombre de máquina perteneciente a una

dirección IP dada utilizando el dominio in-addr.arpa. Los intentos de los servidores de
nombres de proporcionar un nombre falso se conocen en Inglés como spoofing. Para
evitar esto, el sistema puede configurarse para comprobar si las direcciones IP

30
 originales están de hecho asociadas con el nombre obtenido. Si no, el nombre será
rechazado y se retornará un error. Esta opción se activa poniendo nospoof on.

 alert: esta opción puede ir con las palabras on u off, si se activa, cualquier intento de
dar nombre falso sera anotado con un mensaje enviado al sistema de registros syslog.

 trim: lleva un nombre de dominio como argumento que se quitará a los nombres antes
de buscar su dirección. Es útil para las entradas del archivo hosts, que podrán así ir
solos los nombres de máquinas, sin el dominio. Cuando se busque una máquina con
el nombre de dominio local este será eliminado, haciendo que la búsqueda en el
archivo /etc/hosts tenga éxito. Esta opción puede ir repetida con varios dominios, de
modo que su máquina podría ser local a diversos dominios.

Variables de entorno

Existen algunas variables de entorno que establecen opciones que tienen mas prioridad
sobre las puestas en el archivo host.conf. Estas son:

 resolv host conf: específica un archivo alternativo a /etc/host.conf.

 resolv serv order: establece la opción equivalente a la orden order del archivo
anterior. los servicios pueden ser hosts, bind y/o nis, separados por comas, espacios,
puntos o puntos y coma.

 resolv spoof check: determina la política seguida frente a los nombres falsos. Estará
completamente desactivada con la opción off. con las opciones warn y warn off se
realizaran comprobaciones contra los nombres falsos, pero en el primer caso se
mandaran los avisos al registro. un valor * activa las comprobaciones contra nombres
falsos, pero las anotaciones en el registro se dejan como diga el archivo host.conf.

 resolv multi: el valor on activa la opción “multi”, y el valor off la desactiva

 resolv override trim domains: esta variable lleva una lista de dominios por defecto,
similar a la puesta en el archivo host.conf con la opción trim.

 resolv add trim domains: esta variable lleva una lista de dominios por defecto que se
añade a las que se dan en el archivo host.conf.

31
LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL (LDAP)

LDAP es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio

ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también
es considerado una base de datos (aunque su sistema de almacenamiento puede ser
diferente) al que pueden realizarse consultas.

Habitualmente, almacena la información de login (usuario y contraseña) y es utilizado para

autenticarse aunque es posible almacenar otra información (datos de contacto del usuario,
ubicación de diversos recursos de la red, permisos, certificados, etc).

En conclusión, LDAP es un protocolo de acceso unificado a un conjunto de información sobre

una red.

OpenLDAP

Se trata de una implementación libre del protocolo que soporta múltiples esquemas por lo
que puede utilizarse para conectarse a cualquier otro LDAP. Tiene su propia licencia, la
OpenLDAP PUBLIC LICENSE, al ser un protocolo independiente de la plataforma, varias
distribuciones LINUX

OpenLDAP tiene cuatro componentes principales:

 slapd - demonio LDAP autónomo.

 slurpd - demonio de replicación de actualizaciones LDAP autónomo.

 Rutinas de biblioteca de soporte del protocolo LDAP.

 Utilidades, herramientas y clientes.

Configuración de OpenLDAP

 Archivos de Configuración: /etc/openldap/*

 Información sobre la configuración: configurar los servidores slapd y slurpd puede

ser complejo. Asegurar el directorio LDAP, especialmente si se están almacenando
datos no públicos como bases de datos de contraseñas, puede ser también una tarea
desafiante. Se necesita modificar los archivos /etc/openldap/slapd.conf y
/etc/openldap/ldap.conf para ajustar OpenLDAP a las necesidades particulares.

32
 Los recursos que pueden ayudar con tópicos tales como, elegir un directorio de
configuración, controladores y definiciones de bases de datos, ajustes del control de
acceso, lanzarlos como un usuario diferente a root y establecer el entorno chroot,
incluyen:

 La página de manual de slapd

 La página de manual de slapd.conf

 La Guía del Administrador de OpenLDAP 2.2

 Los documentos que se encuentran en http://www.openldap.org/pub/

Servicios de Directorio y LDAP

En el contexto de las redes de computadores, se denomina directorio a una base de datos

especializada que almacena información sobre los recursos, u "objetos", presentes en la red
(tales como usuarios, computadores, impresoras, etc.) y que pone dicha información a
disposición de los usuarios de la red. Por este motivo, esta base de datos suele estar
optimizada para operaciones de búsqueda, filtrado y lectura más que para operaciones de
inserción o transacciones complejas. Existen diferentes estándares que especifican servicios
de directorio, siendo el denominado X.500 tal vez el más conocido.

El estándar X.500 define de forma nativa un protocolo de acceso denominado DAP (Directory
Access Protocol) que resulta muy complejo (y computacionalmente pesado) porque está
definido sobre la pila completa de niveles OSI. Como alternativa a DAP para acceder a
directorios de tipo X.500, LDAP (Lightweight Directory Access Protocol) ofrece un protocolo
ligero casi equivalente, pero mucho más sencillo y eficiente, diseñado para operar
directamente sobre TCP/IP. Actualmente, la mayoría de servidores de directorio X.500
incorporan LDAP como uno de sus protocolo de acceso.

LDAP permite el acceso a la información del directorio mediante un esquema cliente-servidor,

donde uno o varios servidores mantienen la misma información de directorio (actualizada
mediante réplicas) y los clientes realizan consultas a cualquiera de ellos. Ante una consulta
concreta de un cliente, el servidor contesta con la información solicitada y/o con un puntero
donde conseguir dicha información o datos adicionales (normalmente, el "puntero" es otro
servidor de directorio).

33
Internamente, el modelo de datos de LDAP (derivado de X.500, pero algo restringido) define
una estructura jerárquica de objetos o entradas en forma de árbol, donde cada objeto o
entrada posee un conjunto de atributos. Cada atributo viene identificado mediante un nombre
o acrónimo significativo, pertenece a un cierto tipo y puede tener uno o varios valores
asociados. Toda entrada viene identificada unívocamente en la base de datos del directorio
mediante un atributo especial denominado nombre distinguido o dn (distinguished name). El
resto de atributos de la entrada depende de qué objeto esté describiendo dicha entrada. Por
ejemplo, las entradas que describen personas suelen tener, entre otros, atributos como cn
(common name) para describir su nombre común, sn (surname) para su apellido, mail para
su dirección de correo electrónico, etc. La definición de los posibles tipos de objetos, así
como de sus atributos (incluyendo su nombre, tipo, valor(es) admitido(s) y restricciones), que
pueden ser utilizados por el directorio de un servidor de LDAP la realiza el propio servidor
mediante el denominado esquema del directorio. Es decir, el esquema contiene las
definiciones de los objetos que pueden darse de alta en el directorio.

El nombre distinguido de cada entrada del directorio es una cadena de caracteres formada
por pares <tipo_atributo>=<valor> separados por comas, que representa la ruta invertida que
lleva desde la posición lógica de la entrada en el árbol hasta la raíz del mismo. Puesto que se
supone que un directorio almacena información sobre los objetos que existen en una cierta
organización, cada directorio posee como raíz (o base, en terminología LDAP) la ubicación
de dicha organización, de forma que la base se convierte de forma natural en el sufijo de los
nombres distinguidos de todas las entradas que mantiene el directorio. Existen dos formas de
nombrar, o estructurar, la raíz de un directorio LDAP:

 Nombrado "tradicional": formado por el país y estado donde se ubica la organización,

seguida por el nombre de dicha organización. Por ejemplo, la raíz o base de la
Universidad Politécnica de Valencia podría ser algo así: "o=UPV, st=Valencia, c=ES".

 Nombrado basado en nombres de dominio de Internet (es decir, en DNS): este

nombrado utiliza los dominios DNS para nombrar la raíz de la organización. En este
caso, la base de la UPV sería: "dc=upv, dc=es". Este es el nombrado que vamos a
utilizar puesto que permite localizar a los servidores de LDAP utilizando búsquedas
DNS.

A partir de esa base, el árbol se subdivide en los nodos y subnodos que se estime oportuno

34
para estructurar de forma adecuada los objetos de la organización, objetos que se ubican
finalmente como las hojas del árbol. De esta forma, el nombre distinguido de cada entrada
describe su posición en el árbol de la organización (y vice-versa), de forma análoga a un
sistema de archivos típico, en el que el nombre absoluto (unívoco) de cada archivo equivale
a su posición en la jerarquía de directorios del sistema, y vice-versa.

Herramientas Gráficas de Administración

Entre las diferentes herramientas gráficas con las que se puede manipular un directorio de
tipo LDAP en Linux, existe una denominada Directory Administrator, sencilla y cómoda para
su instalación.

Para instalarlo se debe descargar el paquete directory-administrator y ejecutar el comando:

# apt-get install directory-administrator

Una vez instalado, se invoca su ejecutable (directory-adminstrator). La primera vez que se

ejecuta, lanza un asistente que pide la información sobre el servidor de LDAP, la base del
directorio, una credencial para la conexión ("dn" y contraseña), etc. Una vez terminado el
asistente, debería aparecer la ventana principal, donde se visualizará un objeto por cada
usuario y grupo dado de alta en el directorio.

Antes de seguir, se tiene que ir a las opciones de configuración para activar la codificación
de contraseñas "md5" y para desactivar el uso del atributo "authPassword" para almacenar la
contraseña. A partir de ese momento, ya se está en condiciones de añadir, modificar y borrar
usuarios y grupos del directorio, mediante una simple interacción con la herramienta.

Si esta herramienta se convierte en la herramienta fundamental de gestión de usuarios y

grupos en el dominio Linux, se necesita tener en mente un par de precauciones: en primer
lugar, si se desea mantener la filosofía de grupos privados, se debe crear el grupo privado de
un usuario antes que el propio usuario, ya que en este último paso sólo se puede
seleccionar su grupo primario. Y en segundo lugar, se tiene que gestionar manualmente los
directorios de conexión de los usuarios que se crean.

Descripciones

 ldapadd --> abre una conexión a un servidor LDAP, enlaza y añade entradas.

35
  ldapcompare --> abre una conexión a un servidor LDAP, enlaza y hace una
comparación usando los parámetros especificados.

 ldapdelete --> abre una conexión a un servidor LDAP, enlaza y borra una o más
entradas.

 ldapmodify --> abre una conexión a un servidor LDAP, enlaza y modifica entradas.

 ldapmodrdn --> abre una conexión a un servidor LDAP, enlaza y modifica el RDN de
las entradas.

 ldappasswd --> es una herramienta para establecer la contraseña de un usuario

LDAP.

 ldapsearch --> abre una conexión a un servidor LDAP, enlaza y hace una búsqueda
usando los parámetros especificados.

 ldapwhoami --> abre una conexión a un servidor LDAP, enlaza y realiza una
operación whoami.

 slapadd --> se usa para añadir entradas especificadas en el formato Intercambio de

Directorio de LDAP (LDIF) en una base de datos slapd.

 slapcat --> se usa para generar una salida LDAP LDIF basada en el contenido de una
base de datos slapd.

 slapd --> es el servidor LDAP independiente.

 slapindex --> se usa para regenerar índices slapd basados en el contenido actual de
una base de datos.

 slappasswd --> es una utilidad de contraseñas OpenLDAP.

 slurpd --> es el servidor réplica LDAP independiente.

 liblber y libldap --> estas librerías dan soporte a los programas LDAP y suministran
funcionalidad a otros programas que interactuan con LDAP.

SHELLS Y SCRIPTS

Shell, es un término genérico que se utiliza para nombrar a un programa que sirve de

36
interfaz entre el usuario y el núcleo (kernel) del sistema GNU/Linux. Es una utilidad que le
permite a los usuarios interactuar con el kernel por medio de la interpretación de comandos
que éstos mismos introducen en la línea de comandos o en los archivos de tipo shell script.

Estos shell son los que los usuarios ven del sistema, ya que el resto del sistema operativo
permanece esencialmente oculto a sus ojos. El shell se encuentra escrito de la misma forma
que un proceso (programa) de usuario; no se encuentra integrado en el kernel, sino que se
ejecuta de la misma forma que un programa más del usuario.

Al arrancar el sistema GNU/Linux, éste suele presentarle a los usuarios una interfaz de cara
determinada; esta interfaz puede ser tanto de texto, como gráfica. Dependiendo de los
modos, o niveles, de arranque del sistema, ya sea con los diferentes modos de consola de
texto o con modos donde directamente se cuente con un arranque gráfico en X Window.

Para el caso de los modos de arranque gráfico, la interfaz se compone de algún

administrador de acceso por medio del cual se gestiona el proceso de login del usuario
desde una interfaz gráfica, en la que se le pide la información de entrada correspondiente,
como su identificador de usuario y su clave de acceso, o passsword.

En GNU/Linux son muy comunes los gestores o administradores de acceso: xdm que es
propio de X Window, gdm (Gnome), y kdm (KDE), así como también algún otro asociado a
diferentes administradores de ventanas (window managers). Al validar el acceso, el usuario
se encuentra dentro de la interfaz gráfica de X Window con algún administrador de ventanas,
como Gnome o KDE. Si se desea interactuar desde un shell interactivo, sólo se debe abrir
alguno de los programas de emulación de terminal disponibles. Si se accesa por modo
consola, en texto, una vez validados se obtendrá el acceso directo al shell interactivo.

Otro ejemplo de la obtención de un shell interactivo es el acceso remoto a la máquina, ya sea

por medio de cualquiera de las posibilidades de texto como telnet, rlogin, ssh, o las gráficas
como los emuladores X Window.

Shells interactivos

Al iniciar un shell interactivo, se muestra un prompt de cara al usuario, el cual le indica que
puede introducir una línea de comando. Después de introducirla, el shell asume la
responsabilidad de validarla y poner los procesos necesarios en ejecución, mediante una

37
serie de fases:

 Leer e interpretar la línea de comandos.

 Evaluar los caracteres “comodín” como $ * ? u otros.

 Gestionar las redirecciones de E/S necesarias, los pipes y los procesos en segundo
plano (background) necesarios (&).

 Manejar señales.

 Preparar la ejecución de los programas.

En general, las líneas de comandos pueden ser ejecuciones de comandos del sistema,
comandos propios del shell interactivo, puestas en marcha de aplicaciones o shell scripts.

Estos shell scripts son archivos de texto que contienen secuencias de comandos de sistema,
sumado a una serie de comandos propios del shell interactivo, más las estructuras de control
necesarias para procesar el flujo del programa (tipo while, for, entre otros).

Los archivos script se ejecutan de forma directa por el sistema bajo el nombre que se le haya
dado a dicho archivo. Para ejecutarlos, se invoca el shell junto con el nombre del archivo, o
bien se le conceden permisos de ejecución al shell script.

De cierta forma, se puede ver el shell script como código de un lenguaje interpretado que se
ejecuta sobre el shell interactivo correspondiente. Para el administrador, los shell scripts son
muy importantes básicamente por dos razones:

1. La configuración del sistema y de la mayoría de los servicios proporcionados se llevan

a cabo por medio de herramientas proporcionadas en forma de shell scripts.

2. La forma principal para automatizar los procesos de administración es por medio de la

creación de shell scripts por parte del administrador.

Todos los programas que se invocan por medio de un shell poseen tres archivos
predefinidos, especificados por los correspondientes descriptores de archivos (file handles).
Estos archivos son por defecto:

1. standard input (entrada estándar): es la que en general se le asigna al teclado del

terminal o consola; utiliza el descriptor número 0, también, en UNIX los archivos

38
 utilizan descriptores enteros.

2. standard output (salida estándar): en general, se le asigna a la pantalla del terminal,

utiliza el descriptor 1.

3. standard error (salida estándar de errores): éste en general se le asigna a la pantalla

del terminal; utiliza el descriptor 2.

Esto destaca el hecho de que cualquier programa ejecutado desde el shell tendrá por defecto
la entrada asociada al teclado del terminal, su salida hacia la pantalla y, en el caso de
producirse errores, también los envía a la pantalla. Por otro lado, los shells normalmente
ofrecen los tres mecanismos presentados a continuación:

1. Redirección: ya que los dispositivos de E/S y los archivos se tratan de la misma forma
en UNIX, el shell los trata a todos sólo como archivos. Desde el punto de vista del
usuario, se pueden redefinir los descriptores de los archivos para que los flujos de
datos de un descriptor vayan a cualquier otro descriptor; a esto se le conoce como
redirección.

2. Tuberías (pipes): la salida estándar de un programa puede ser utilizada como entrada
estándar de otro por medio de estas tuberías o pipes. Varios programas pueden ser
conectados entre sí mediante éstas para formar lo que se denomina un pipeline.

3. Concurrencia de programas de usuario: los usuarios pueden ejecutar varios

programas al mismo tiempo, indicando que su ejecución se va a producir en segundo
plano (background), en términos opuestos a primer plano (o foreground), donde se
tiene un control exclusivo de pantalla. Otro uso consiste en permitir trabajos largos en
segundo plano al usuario, interactuar con el shell con otros programas en primer
plano.

En el caso de los shells UNIX/Linux estos tres aspectos suponen en la práctica:

1. Redirección: un comando va a poder recibir su entrada o salida desde otros archivos o

dispositivos.

2. Pipes: encadenamiento de varios comandos, con transmisión de sus datos: comando1

| comando2 | comando3.

39
 Esta instrucción indica que comando1 recibirá una posible entrada de teclado, enviará
su salida a comando2, que la recibirá como entrada, y éste producirá salida hacia
comando3, que la recibe y produce su salida hacia salida estándar, la pantalla, por
defecto.

3. Concurrencia en segundo plano: cualquier comando ejecutado con el ‘&’ al final de la

línea se ejecuta en segundo plano y el prompt del shell se devuelve de forma
inmediata al mismo tiempo que continúa su ejecución.

Se le puede dar seguimiento a la ejecución de los comandos con el comando ps y sus

opciones, el cual permite ver el estado de los procesos en el sistema. También se cuenta con
la orden kill, la cual permite eliminar los procesos que todavía se encuentren en ejecución, o
que hayan incurrido en alguna condición de error: kill pid permite “matar” el proceso número
pid, donde pid que es el identificador asociado al proceso, que es un número entero que el
sistema le asigna y que puede obtenerse por medio del comando ps.

Shells Disponibles

La independencia del shell con respecto al kernel del sistema operativo, sabiendo que el
shell es sólo una capa de interfaz, permite disponer de varios de éstos en el sistema. Algunos
de los más comunes son:

 El shell Bash (bash): el shell Linux por defecto.

 El shell Bourne (sh): éste ha sido desde siempre el shell estándar UNIX, y el que todos
los UNIX poseen en alguna versión. En general, es el shell por defecto del
administrador (root). El Bash en GNU/Linux es a menudo una versión mejorada del
Bourne. El indicador, o prompt, por defecto es a menudo un ’$’ (en root un ’#’).

 El shell Korn (ksh): este es un superconjunto del Bourne, ya que se mantiene cierta
compatibilidad, escrito en AT&T por David Korn a mediados de los ochenta, donde se
hizo cierta mezcla de funcionalidades del Bourne y del C, más algún agregado. El
prompt por defecto es el $.

 El shell C (csh): tiene unos cuantos agregados interesantes al Bourne, como un

histórico de comandos, alias, aritmética desde la línea de comandos, completa los
nombres de los archivos y control de trabajos en segundo plano. El prompt por defecto

40
 para los usuarios es ‘%’, una ventaja de los scripts en C shell es que, como su nombre
indica, su sintaxis se basa en el lenguaje C.

Aspectos que son comunes a todos los shells

 Todos permiten la escritura de shell scripts que son luego interpretados al ser
ejecutados ya sea por el nombre, si el archivo cuenta con permiso de ejecución, o ya
sea pasándolo como parámetro al comando del shell.

 Los usuarios del sistema cuentan con un shell por defecto asociado a ellos. Esta
información se proporciona al crear las cuentas de los usuarios. El administrador
asigna un shell a cada usuario, o bien si no se asigna el shell por defecto, bash en
GNU/Linux. Esta información se guarda en el archivo de passwords en /etc/passwd.

 Cada shell es realmente un comando ejecutable, que se encuentra presente en los

directorios /bin en GNU/Linux (o /usr/bin).

 Se pueden escribir shell scripts en cualquiera de éstos, pero se debe ajustar a la

sintaxis de cada uno, que es normalmente diferente, ya que a veces existen sólo
pequeñas diferencias. La sintaxis de las construcciones, así como los comandos
internos, se encuentran bien documentados en la página man de cada shell.

 Cada shell cuenta con algunos archivos de arranque asociados, llamados archivos de
inicialización, donde cada usuario puede adaptarlos a sus necesidades, incluyendo
código, variables, caminos (path).

 La potencia en la programación radica en la combinación de la sintaxis de cada shell

(de sus construcciones), con los comandos internos de cada shell, y una serie de
comandos UNIX muy utilizados en los scripts, como por ejemplo los grep, sed, awk.

 Si como usuarios se utiliza un shell determinado, nada impide arrancar una copia
nueva de shell, llamada subshell, ya sea el mismo u otro diferente. Sólo se invoca por
el nombre del ejecutable, ya sea el sh, bash, csh o ksh. También, al ejecutar un shell
script se lanza un subshell con el shell que corresponda para ejecutar el script
solicitado.

41
Diferencias básicas entre los shells

 Bash es el shell por defecto en GNU/Linux, si no se especifica lo contrario al momento

de crear la cuenta del usuario. En otros sistemas UNIX suele ser el shell Bourne (sh).
Bash es compatible con sh, además incorpora algunas características de los otros
shells, csh y ksh.

 Archivos de arranque: sh, ksh cuentan con .profile, en la cuenta del usuario, y se
ejecuta en el login del usuario, además el ksh suele poseer un .kshrc el cual se
ejecuta a continuación; el csh utiliza .Login, que se ejecuta al iniciarse el login del
usuario una sola vez, .logout, antes de la salida de la sesión del usuario, y .cshrc, que
es parecido al .profile, en cada subshell C que se inicia. Bash utiliza el .bashrc y el
.bash_profile. Además, el administrador puede colocar variables y caminos comunes
en el archivo /etc/profile que se ejecutará antes que los archivos con los que cuente
cada usuario. Los archivos de inicialización de los shell se colocan en la cuenta del
usuario al ser creada, en general, se copian del directorio /etc/skel, donde el
administrador puede dejar unos esqueletos de los archivos preparados.

 Los scripts de configuración del sistema o de servicios suelen escribirse en shell

Bourne (sh), ya que la mayoría de los UNIX así los tenían. En GNU/Linux también se
pueden encontrar algunos en Bash.

 Se puede identificar en qué shell se ejecuta el script por medio del comando file, por
ejemplo file <nombrescript>. O también al examinar la primera línea del script, que
suele ser: #!/bin/nombre, donde nombre es bash, sh, csh, ksh ... Esta línea le dice, en
el momento de ejecutar el script, qué shell se debe utilizar a la hora de interpretarlo, o
sea, qué subshell hay que lanzar para su ejecución. Es muy importante que todos los
scripts la contengan, ya que si no, se intentarán ejecutar en el shell por defecto, que
en este caso es Bash, y la sintaxis puede no corresponder, lo que genera muchos
errores sintácticos durante la ejecución.

Programación scripts en Bash

Todos los scripts Bash deben comenzar con la línea: #!/bin/bash. Esta línea le indica al shell
utilizado por el usuario, el que se tenga activo en ese momento, con qué shell se debe
ejecutar el script que aparezca a continuación.

42
El script puede ser ejecutado de dos formas diferentes:

 Por ejecución directa desde la línea de comandos, siempre que se cuente con permiso
de ejecución. En caso contrario, se coloca el permiso con: chmod +x script.

 Por ejecución mediante el shell, se hace un llamado al shell explícitamente: bash

script.

Se debe tener en cuenta que sea cuál sea el método de ejecución, siempre se está creando
un subshell donde se va a ejecutar el nuevo script.

Variables en Bash

La asignación de variables se realiza por: variable = valor , el valor de la variable puede ser
visualizado con: echo $variable, donde ’$’ hace referencia al valor de la variable.

La variable por defecto sólo puede ser visualizada en el script, o en el shell. Si ésta debe ser
visible fuera del script, a nivel de shell o de cualquier shell hijo, o subshell, que se genere
después, será necesario “exportarla” además de asignarla. En este caso, se pueden hacer
dos cosas:

1. Asignar y exportar después: var = valor

export var

2. Exportar en la asignación: export var = valor

En los scripts Bash se tienen algunas variables predeterminadas accesibles:

 $1-$N: con esta variable se guardan los argumentos pasados como parámetros al
script desde la línea de comandos.

 $0 : con esta variable se guarda el nombre del script, que sería el parámetro 0 de la
línea de comandos.

 $* : con esta variable se guardan todos los parámetros del 1 al N.

 $ : con esta variable se guardan todos los parámetros, pero con comillas dobles (“ ”)
en cada uno de ellos.

 $? ,“Status”: con esta variable se guarda el valor devuelto por el último comando

43
 ejecutado. Ésta es útil para verificar las condiciones de error, ya que UNIX suele
devolver 0 si la ejecución ha sido correcta, y un valor diferente como código de error.

Otro elemento importante en las asignaciones es el uso de las comillas:

 Las “dobles” permiten que sea considerado todo como una unidad.

 Las ‘simples’ son parecidas, pero se ignoran los caracteres especiales que se
encuentren dentro.

 Las inclinadas hacia la izquierda `comando`, son utilizadas para evaluar el interior, si
existe alguna ejecución o sustitución que hacer. En primer lugar, se ejecuta el
contenido y se sustituye lo que había por el resultado de la ejecución.

Por ejemplo: var = `ls` guarda el listado del directorio en $var.

Comparaciones

Para el caso de las condiciones a menudo se utiliza la orden test expresión o directamente
[expresión]. Las condiciones disponibles pueden ser agrupadas por:

 Comparación numérica: -eq, -ge, -gt, -le, -lt, -ne, correspondiendo a: igual que, más
grande o igual que (ge), más grande que, menor o igual que (le), menor que, distinto
que.

 Comparación de cadenas: = , ! = , -n, -z, correspondiendo a cadenas de caracteres:

iguales, diferentes, con longitud mayor que 0, longitud igual a cero o vacío.

 Comparación de archivos: -d, -f -r, -s, -w, -x. El archivo es: un directorio, un archivo
ordinario, es legible, es no vacío, es escribible, es ejecutable.

 Booleanos entre expresiones: !, -a, -o, condiciones de not, and y or.

44
OPTIMIZAR EL SISTEMA

A continuación se presentan algunas recomendaciones para optimizar el sistema en función

de los datos obtenidos:

Resolver los problemas de memoria principal

Se debe procurar que la memoria principal pueda recibir un porcentaje elevado de procesos
en ejecución, ya que si no es así, el sistema operativo podrá paginar e ir al swap; esto
significa que la ejecución de ese proceso se degradará de forma. Si se agrega memoria, el
tiempo de respuesta mejorará bastante. Para esto, se debe tener en cuenta el tamaño de los
procesos (SIZE) en estado R y agregarle la que utiliza el kernel, que se puede obtener con el
comando dmesg.

Luego se deberá comparar con la memoria física y analizar si el sistema se encuentra

limitado por la memoria; se podrá ver mucha actividad de paginación con atsar -r y -p. Las
soluciones para la memoria son obvias, o se incrementa la capacidad o se reducen las
necesidades. Por el coste actual de la memoria se recomienda más incrementar su tamaño,
que emplear muchas horas para ganar un centenar de bytes por quitar, ordenar o reducir
requerimientos de los procesos en su ejecución. Reducir los requerimientos puede llevarse a
cabo reduciendo las tablas del kernel, quitando módulos, limitando el número máximo de
usuarios, reduciendo los buffers, etc.; todo lo cual degradará el sistema, el llamado efecto
burbuja, y las prestaciones serán peores, en algunos casos, el sistema puede quedar
totalmente no operativo.

Otro aspecto que se puede reducir es la cantidad de memoria de los usuarios eliminando
procesos redundantes y cambiando la carga de trabajo. Para esto, se deberá darle
seguimiento a los procesos que están durmiendo (zombies) y eliminarlos, o aquellos que no
progresan en su entrada/salida, se debe saber si son procesos activos, cuánto de CPU llevan
gastado y si los ‘usuarios están por ellos’. Si se cambia la carga de trabajo se utiliza la
planificación de colas para que los procesos que necesitan una gran cantidad de memoria se
puedan ejecutar en horas de poca actividad, por ejemplo, por la noche lanzándolos con el
comando at.

45
Mucha utilización de CPU

En general, ofrece el tiempo idle, los valores bajos. Con ps o top se deben analizar los
procesos que ‘devoran CPU’ y tomar ciertas decisiones como, posponer su ejecución;
pararlos temporalmente; cambiar la prioridad, que es el menos conflictivo de todos, y se
puede utilizar el comando renice prioridad PID; optimizar el programa, para la próxima vez; o
cambiar la CPU, o agregar otra. Como ya se mencionó, GNU/Linux utiliza el directorio /proc
para mantener todas las variables de configuración del kernel que pueden ser analizadas y,
en cierto caso, ‘ajustadas’, para lograr prestaciones diferentes o mejores.

Para lograrlo, se debe utilizar el comando systune dump > /tmp/sysfile para obtener todas las
variables y sus valores en el archivo /tmp/sysfile. Este archivo se puede editar, cambiar la
variable correspondiente y luego utilizar el comando systune -c /tmp/sysfile para cargarlas
una vez más en el /proc. El comando systune también lee por defecto si no tiene la opción -c
de /etc/systune.conf.

En el caso de GNU/Linux, a diferencia de otros sistemas operativos, es un valor fijo dentro

del código, ya que se encuentra optimizado para las diferentes funcionalidades, sin embargo,
es posible tocarlo. Se puede “jugar”, a riesgo del que lo hace, con las variables TICK_SCALE
(o NICE_TO_TICKS) en (Debian) kernel-source-2.4.18/kernel/sched.c, que por defecto, se
ajusta para que el timeslice sea aproximadamente de 50 milisegundos.

Reducir el número de llamadas

Otra práctica común y recomendada para mejorar las prestaciones es reducir el número de
llamadas al sistema de mayor coste en tiempo de CPU. Estas llamadas son las invocadas,
en general, por el shell fork() y exec(). Una configuración inadecuada de la variable PATH
puede tener una relación desfavorable de ejecución, ya que la llamada exec() no guarda
nada en caché, el directorio actual (indicado por ./). Para esto, siempre se deberá configurar
la variable PATH con el directorio actual como última ruta. Por ejemplo, en bash (o en
.bashrc) se hace: export PATH = $PATH. Si no es así, no se encuentra el directorio actual, o
si se encuentra, se rehace la variable PATH para ponerlo como última ruta. Se debe tener en
cuenta que una alta actividad de interrupciones puede afectar a las prestaciones de la CPU
con relación a los procesos que ejecuta.

46
Por medio del monitoreo (atsar -I) se puede mirar cual es la relación de interrupciones por
segundo y tomar las decisiones con respecto a los dispositivos que las causan.

Mucha utilización de disco

Después de la memoria, un tiempo de respuesta bajo puede ser debido al sistema de discos.
En primer lugar, se debe verificar que se disponga de tiempo de CPU, por ejemplo, idle >
20%, y que el número de entrada/salida sea elevado, por ejemplo, > 30 entrada/salida/s,
utilizando atsar -u y atsar -d. Las soluciones pasan por:

 En un sistema multidisco: planificar dónde se encontrarán los archivos más

utilizados para equilibrar el tráfico hacia éstos. En situaciones críticas, se puede
considerar la compra de un sistema de discos RAID que realizan este ajuste de
forma automática.

 Se debe tener en cuenta que se obtienen mejores prestaciones sobre dos discos
pequeños que sobre uno grande del tamaño de los dos anteriores.

 En el caso de los sistemas con un único disco, en general se realizan, desde el

punto de vista del espacio, cuatro particiones de la siguiente forma, desde fuera
hacia dentro: /, swap, /usr, /home; este genera pésimas respuestas de
entrada/salida porque si, por ejemplo, un usuario compila desde su directorio
/home/user y el compilador se encuentra en /usr/bin, la cabeza del disco se
moverá por toda su longitud. En este caso es mejor unir las particiones /usr y
/home en una sola, que es más grande, aunque puede representar algunos
inconvenientes con respecto al mantenimiento.

 Incrementar los buffers de la caché de entrada/salida.

47
 ENLACES DE INTERÉS

www.ldap-es.org

http://www.bdat.net/documentos/ldap/

http://platea.pntic.mec.es/~jmartine/router/router.html

http://www.iec.csic.es/CRIPTONOMICON/consejos/cortafuegoslinux.html

http://roble.pntic.mec.es/~sgonzale/linux/cortafuegos.html

http://www.masadelante.com/faq-cortafuegos.htm

http://www.wikilearning.com/tutorial/manual_practico_de_iptables/9755

http://club.telepolis.com/jagar1/Unix/Scripts.htm

48