• Author / Uploaded
• Junior Sumosa

• Categories
• Cortafuegos (informática)
• Contraseña
• Autenticación
• Distribución de Linux
• Enrutador (Computación)

Citation preview

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 0 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

interesante

un

objetivo

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 '; 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 = 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 . 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