Seguridad del Sistema (Manual Linux)

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 comúnes 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 archivos y archivos 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 archivos 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 /boot17
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 igual18. De cualquier modo programas que requieran privilegio especial son inherentemente más peligrosos que otros, ya que cualquier falla aprovechable en estos puede tener consecuencias drásticas.19 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 ingresar al 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), que permite comprobar archivos 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 ejecuciónes, se reevalúan y comparan dichas sumas de verificación con las almacenadas, detectándose así cualquier posible modificación.