1.5. Mantenimiento del Sistema

1.5.1. 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 Cap�tulo 12, 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 Cap�tulo 9.

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.