A lo largo de este libro, se discutirá principalmente cuestiones de instalación y configuración. Sin embargo, la administración de un sistema, es mucho más que eso—después de activar un servicio, también se deberá mantenerlo en correcto funcionamiento. Para la mayoría de éstos, será suficiente con una pequeñas revisiones, pero para otros servicios, como lo son el correo o las noticias, será necesario ejecutar rutinas de verificación para mantener el sistema en óptimo estado. Se discutirán estas tareas, en los capítulos siguientes.
La tarea mínima de mantenimiento es comprobar regularmente el sistema y los ficheros de registro de cada aplicación buscando condiciones de error y eventos inusuales. Por lo general, es posible hacer esto escribiendo un par de scripts de órdenes y ejecutándolos periódicamente mediante la orden
cron. Se podrá encontrar algunos de estos scripts en distribuciones fuente de algunas aplicaciones importantes como
inn o C News. Tras obtenerlos, sólo se tendrá que retocarlos para adecuarlos a nuestras necesidades y preferencias.
La salida de cualquiera de los trabajos de nuestro
cron, se debería enviar a una cuenta de administración. Por defecto, muchas aplicaciones enviarán informes de errores, estadísticas de uso, o resúmenes del fichero de registro a la cuenta de root. Ésto solo tiene sentido si se entra al sistema como root frecuentemente. Una idea mucho mejor es redirigir el correo de root a nuestra cuenta personal, estableciendo un alias de correo como se describe en
y en
.
De todos modos, por muy cuidadoso que sea configurando su máquina, la ley de Murphy garantiza que
surgirá algún problema en el futuro. Por lo tanto, el mantenimiento de un sistema implica también estar disponible para quejas. Generalmente la gente espera que se pueda contactar con el administrador del sistema al menos por correo electrónico, como root. Sin embargo, existen otras denominaciones para direcciones de correo usadas comúnmente para contactar a los posibles encargados de la administración de respectivos servicios del sistema. Por ejemplo, las quejas sobre el mal funcionamiento del correo se dirigirán generalmente al postmaster (encargado del correo). Del mismo modo, los problemas con el sistema de noticias pueden ser comunicados a newsmaster o al usenet. El correo al hostmaster se debería redirigir a la persona encargada de los servicios básicos de red del nodo, y del servicio de nombres DNS si esta funcionando un servidor de nombres.
Seguridad del Sistema
Otro aspecto muy importante de la administración de sistemas en un entorno de red es proteger al sistema y a sus usuarios, de intrusos. Los sistemas que son administrados descuidadamente ofrecen muchos huecos a los malintencionados: los ataques van desde averiguar las claves hasta acceder a nivel de Ethernet, y el daño causado puede ser desde mensajes de correo falsos hasta pérdida de datos o violación de la privacidad de los usuarios. Mencionaremos algunos problemas concretos cuando discutamos el contexto en el que pueden ocurrir, y algunas defensas comunes contra ellos.
En esta sección se comentarán algunos ejemplos y técnicas básicas para poder lidiar con la seguridad del sistema. Por supuesto, los temas relatados aquí no pueden tratar exhaustivamente todos los aspectos de seguridad con los que uno se puede encontrar; sirven meramente para ilustrar los problemas que pueden surgir. Por tanto, la lectura de un buen libro sobre seguridad es absolutamente obligada, especialmente en un sistema en red.
La seguridad del sistema comienza con una buena administración del mismo. Esto incluye comprobar la propiedad y permisos de todos los ficheros y directorios vitales, monitorizar el uso de cuentas privilegiadas, etc. El programa COPS, por ejemplo, sirve para comprobar nuestro sistema de ficheros y ficheros de configuración generales, en busca de permisos inusuales u otras anomalías. También es conveniente usar un sistema de claves que fuerce ciertas reglas en las claves de los usuarios que las hagan difíciles de adivinar. El sistema de claves ocultas (shadow password), por ejemplo, requiere que una clave tenga al menos cinco letras, entre las cuales se encuentren tanto mayúsculas como minúsculas, números y caracteres no-alfabéticos.
Cuando un servicio se hace accesible a la red, asegúrese de darle el “menor privilegio”. Esto significa, en una palabra que no se deberán permitir acciones que no son imprescindibles, para que se trabaje como se diseñó el servicio originalmente. Por ejemplo, el usuario debería hacer sus programas con setuid root, o alguna otra cuenta privilegiada, sólo si realmente se necesitara. También, si se quiere usar un servicio sólo para una aplicación muy limitada, el administrador del sistema no debe vacilar en configurar el servicio tan restrictivamente como la aplicación especial lo permita. Por ejemplo, si se quiere permitir a máquinas sin disco arrancar desde un nodo en especial, se debe facilitar el servicio TFTP (
Trivial File Transfer Protocol? de modo que se puedan obtener los ficheros de configuración básicos del directorio
/boot. Sin embargo, cuando se usa sin restringir, TFTP permite a cualquier usuario de cualquier lugar del mundo leer cualquier fichero de su sistema. Si esto no es lo que desea, luego se debe restringir el servicio TFTP solamente al directorio
/boot[1]
Pensando en la misma línea, se podría restringir ciertos servicios a usuarios que acceden desde ciertos nodos, digamos desde nuestra red local. En
, presentaremos
tcpd, que hace esto para una variedad de aplicaciones de red. Se explorarán otros métodos más sofisticados para restringir el acceso a nodos o servicios particulares en
.
Otro punto importante a tener en cuenta es evitar software “peligroso”. Claro que cualquier software que se utilice puede resultar peligroso, dado que el software puede tener fallos que gente astuta pueda explotar para acceder a nuestro sistema. Cosas como ésta ocurren, y no hay protección segura contra ello. Este problema afecta al software libre y a productos comerciales por igual[2]. De cualquier modo programas que requieran privilegio especial son inherentemente más peligrosos que otros, ya que cualquier fallo aprovechable en éstos puede tener consecuencias desastrosas.[3] Si instala un programa setuid con propósitos de red, sea muy cuidadoso y no deje de leerse toda la documentación, de manera tal de no crear una brecha en la seguridad del sistema por accidente.
Otra fuente a considerar deberían ser aquellos programas que permiten registrarse en el sistema, o la ejecución de órdenes con autentificación limitada. Las órdenes
rlogin,
rsh y
rexec, son muy útiles pero ofrecen un muy ligero método de autentificación para aquellos que hagan uso de ellas. Un método de autentificación se basa en la confianza del nombre del nodo llamado, el cual fue obtenido de un servidor de nombres, (se hablará de estos más adelante), que pudo haber sido falseado. Hoy en día, debería ser una práctica común el reemplazar completamente los comandos
r con la colección de herramientas
ssh. Las herramientas
ssh usan un método de autentificación mucho más confiable, además de proporcionar otros servicios como encriptación y compresión.
Nunca se debería de olvidar que nuestras precauciónes pueden fallar, por muy cuidadosas que estas sean. Por eso se debería asegurar de que la detección de los posibles intrusos es relativamente rápida. Comprobar los ficheros de actividad es un buen comienzo, pero el intruso probablemente sea bastante listo, y borrará cualquier huella que haya dejado. Sin embargo, hay herramientas como
tripwire, (escrito por Gene Kim y Gene Spafford), [4]que permite comprobar ficheros vitales del sistema para ver si sus contenidos o permisos han cambiado.
tripwire realiza varias e intensas sumas de verificación (checksums) sobre estos ficheros y almacena los resultados en una base de datos. En las siguientes ejecuciones, se reevalúan y comparan dichas sumas de verificación con las almacenadas, detectándose así cualquier posible modificación.
Notas
|| [1] || Se volverá a retomar este tema en
. ||
|| [2] || Ha habido sistemas UNIX comerciales, (por los que hay que pagar un montón de dinero), que venían con un script de shell setuid-root que permitía a los usuarios obtener privilegios de root utilizando un simple y conocido truco. ||
|| [3] || En 1988, el gusano RTM llevó a gran parte de Internet a un colapso, en parte por explotar un agujero que había en algunos programas, incluyendo a
sendmail. Este agujero ya ha sido reparado con creces. ||
|| [4] || del que ya hay disponible una traducción en tldp-es ||
