SEGURIDAD EN UNIX Y REDES

5.4. FAUNA Y OTRAS AMENAZAS 73cubre también a estas llamadas: asociar un descriptor y un nombre de fichero sin restringir el modode acceso. Para esto se utilizaría un modo especial de apertura, O ACCESS – que sería necesarioimplementar –, en lugar de los clásicos O RDONLY, O WRONLY o O RDWR; este nuevo modo garantizaríaque si el objeto existe se haría sobre él un open() habitual pero sin derecho de escritura o lectura(sería necesario efectuar una segunda llamada a la función, con los parámetros adecuados), y si noexiste se reserva un nombre y un inodo de tipo ‘reservado’, un tipo de transición que posteriormentesería necesario convertir en un tipo de fichero habitual en Unix (directorio, socket, enlace. . . ) conlas llamadas correspondientes.5.4 Fauna y otras amenazasEn el punto anterior hemos hablado de problemas de seguridad derivados de errores o descuidosa la hora de programar; sin embargo, no todas las amenazas lógicas provienen de simples errores:ciertos programas, denominados en su conjunto malware o software malicioso, son creados con laintención principal de atacar a la seguridad 3 . En esta sección vamos a hablar de algunos tipos demalware, sus características y sus efectos potenciales.Para prevenir casi todo el software malicioso que pueda afectar a nuestros sistemas es necesariauna buena concienciación de los usuarios: bajo ningún concepto han de ejecutar software que noprovenga de fuentes fiables, especialmente programas descargados de páginas underground o ficherosenviados a través de irc. Evidentemente, esto se ha de aplicar – y con más rigor – al administradorde la máquina; si un usuario ejecuta un programa que contiene un virus o un troyano, es casi imposibleque afecte al resto del sistema: en todo caso el propio usuario, o sus ficheros, serán los únicosperjudicados. Si es el root quien ejecuta el programa contaminado, cualquier archivo del sistemapuede contagiarse – virus – o las acciones destructivas del malware – troyano – afectarán sin límitesa todos los recursos del sistema. Aparte de descargar el software de fuentes fiables, es recomendableutilizar las ‘huellas’ de todos los programas (generalmente resúmenes md5 de los ficheros) paraverificar que hemos bajado el archivo legítimo; también es preferible descargar el código fuente ycompilar nosotros mismos los programas: aparte de cuestiones de eficiencia, siempre tenemos laposibilidad de revisar el código en busca de potenciales problemas de seguridad.Otra medida de seguridad muy importante es la correcta asignación de la variable de entorno$PATH, especialmente para el administrador del sistema. Esta variable está formada por todos losdirectorios en los que el shell buscará comandos para ejecutarlos; podemos visualizar su contenidomediante la siguiente orden:anita:~# echo $PATH/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/sbin:/usr/dt/bin:/usr/openwin/bin:/usr/share/texmf/binanita:~#Cuando un usuario teclea una órden en la línea de comandos, el shell busca en cada uno de estosdirectorios un ejecutable con el mismo nombre que el tecleado; si lo encuentra, lo ejecuta sin más, ysi no lo encuentra se produce un mensaje de error (el clásico ‘command not found’). Esta búsquedase realiza en el orden en que aparecen los directorios del $PATH: si por ejemplo se hubiera tecleado‘ls’, en nuestro caso se buscaría en primer lugar /sbin/ls; como – seguramente – no existirá,se pasará al siguiente directorio de la variable, esto es, se intentará ejecutar /usr/sbin/ls. Estefichero tampoco ha de existir, por lo que se intentará de nuevo con /bin/ls, la ubicación normaldel programa, y se ejecutará este fichero.¿Qué problema hay con esta variable? Muy sencillo: para que sea mínimamente aceptable, ningunode los directorios del $PATH ha de poseer permiso de escritura para los usuarios normales; esto3 Realmente, algunos de ellos no son necesariamente nocivos; es su uso indebido y no la intención de su programadorlo que los convierte en peligrosos.