SEGURIDAD EN UNIX Y REDES

Capítulo 5Programas seguros, inseguros ynocivos5.1 IntroducciónEn 1990 Barton P. Miller y un grupo de investigadores publicaron [MFS90], un artículo en el quese mostraba que demasiadas herramientas estándar (más del 25%) de Unix fallaban ante elementostan simples como una entrada anormal. Cinco años más tarde otro grupo de investigación, dirigidotambién por Barton P. Miller, realizó el estudio [MKL + 95], lamentablemente no publicado; las conclusionesen este último estudio fueron sorprendentes: el sistema con las herramientas más establesera Slackware Linux, un Unix gratuito y de código fuente libre que presentaba una tasa de fallosmuy inferior al de sistemas comerciales como Solaris o IRIX. Aparte de este hecho anecdótico, erapreocupante comprobar como la mayoría de problemas descubiertos en 1990 seguía presente en lossistemas Unix estudiados.Aunque por fortuna la calidad del software ha mejorado mucho en los últimos años 1 , y esa mejoralleva asociada una mejora en la robustez del código, los fallos y errores de diseño en aplicaciones oen el propio núcleo son una de las fuentes de amenazas a la seguridad de todo sistema informático.Pero no sólo los errores son problemáticos, sino que existen programas – como los virus – realizadosen la mayoría de situaciones no para realizar tareas útiles sino para comprometer la seguridad deuna máquina o de toda una red. Este tipo de programas sólamente compromete la seguridad cuandoafectan al administrador; si un virus infecta ficheros de un usuario, o si éste ejecuta un troyano, sólopodrá perjudicarse a sí mismo: podrá borrar sus ficheros, enviar correo en su nombre o matar susprocesos, pero no hacer lo mismo con el resto de usuarios o el root. El problema para la seguridadviene cuando es el propio administrador quien utiliza programas contaminados por cualquier clasede fauna, y para evitar esto hay una medida de protección básica: la prevención. Es crucial quelas actividades como administrador se reduzcan al mínimo, ejecutando como usuario normal lastareas que no requieran de privilegios. Cuando no quede más remedio que trabajar como root (porejemplo a la hora de instalar software en el sistema), no hemos de ejecutar nada que no provengade una fuente fiable, e incluso así tomar precauciones en caso de que el programa realice funcionesmínimamente delicadas para el sistema operativo (por ejemplo, probarlo antes en una máquina detesteo, o en entornos cerrados con chroot()). Es muy normal, sobre todo entre administradores deLinux, el recomendar que no se ejecute nada sin haber leído previamente el código fuente, o al menosque dicho código esté disponible; esto, aunque es una solución perfecta al problema, es inaplicableen la mayoría de situaciones. Por un lado, no todas las aplicaciones o sistemas tienen su códigoabierto a sus usuarios, por lo que nos estaríamos restringiendo a utilizar programas generalmenteno comerciales – algo que quizás no depende de nosotros, como administradores –. Por otro, resultaabsurdo pensar que un administrador tenga el tiempo necesario para leer (y lo más importante,1 En Unix, claro.69