Configuraciones de Umask

El comando umask puede usarse para determinar el modo por defecto de creación de ficheros en tu sistema. Es el complemento octal del modo de fichero deseado. Si los ficheros se crean sin tomar en cuenta sus configuraciones de permisos, el usuario inadvertidamente podría dar permiso de lectura o escritura a alguien que no debería tener este permiso. Normalmente, las configuraciones de umask incluyen 022, 027 y 077 (que es el más restrictivo). Normalmente el umask se pone en /etc/profile, así se aplica a todos los usuarios en el sistema. La máscara de creación de archivos puede calcularse restando el valor deseado de 777. En otras palabras, un umask de 777 supondría que los ficheros nuevos creados no contendrían permiso de lectura, escritura o ejecución para nadie. Una máscara de 666 causaría que los ficheros nuevos creados tengan una máscara de 111. Por ejemplo, puedes tener una línea que se parezca a ésta: # Set the user's default umask umask 033
Asegúrate de poner el umask de root en 077, lo que discapacitará el permiso de lectura, escritura y ejecución para otros usuarios, a menos que se cambie explicitamente usando chmod. En este caso, los directorios recién creados tendrían permisos 744, obtenido restando 033 de 777. Los ficheros nuevos creados usando el umask 033 tendrían permisos de 644.
Si estás usando Red Hat, y te sumas a su esquema de creación de ID de usuario y de grupo (Grupos Privados de Usuario), sólo es necesario usar 002 para un umask. Esto es debido al hecho de que la configuración por defecto es de un usuario por grupo.
Permisos de Fichero
Es importante asegurar que tus ficheros de sistema no están abiertos a la edición casual por usuarios y grupos que no deberían estar realizando tal mantenimiento del sistema.
Unix separa el control de acceso sobre ficheros y directorios conforme a tres características: propietario, grupo y otro. Siempre hay exactamente un dueño, cualquier número de miembros del grupo y todos los otros.
Una rápida explicación de los permisos de Unix:
Dueño - Qué usuario(s) y grupo(s) mantiene(n) el control de las configuraciones de permisos del nodo y del padre del nodo.
Permisos - Los bits que pueden ser establecidos o reestablecidos para permitir ciertos tipos de acceso. Los permisos para directorios pueden tener un significado diferente al del mismo conjunto de permisos para ficheros.
Lectura:
Ser capaz de ver los contenidos de un fichero
Ser capaz de leer un directorio
Escritura:
Ser capaz de añadir o cambiar un fichero
Ser capaz de borrar o mover ficheros en un directorio
Ejecución:
Ser capaz de ejecutar un programa binario o un script de shell
Ser capaz de buscar en un directorio, combinado con permiso de lectura
Atributo de Salvar Texto: (Para directorios)
El "bit inmutable" tiene también un significado diferente cuando se aplica a directorios que cuando se aplica a ficheros. Si el bit inmutable se pone en un directorio, entonces el usuario sólo puede borrar los ficheros de los que es dueño o para los que tiene concedido un permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está diseñado para directorios como /tmp, que son escribibles por todos, pero donde puede no ser deseable permitir a cualquier usuario borrar ficheros a su gusto. El bit inmutable se ve como t en un listado largo de directorio.
Atributo SUID: (Para Ficheros)
Esto describe el conjunto de permisos de identidad de usuario sobre el fichero. Cuando el modo de acceso al conjunto de identidad de usuario se configura como permisos de propietario, y el fichero es ejecutable, a los procesos que se ejecutan bajo él se les concede acceso a los recursos del sistema basándose en el usuario dueño del fichero, como opuesto al usuario que ha creado el proceso. Esto es la causa de muchos exploits por "desbordamiento de búfer" ("buffer overflow").
Atribut SGID : (Para Ficheros)
Si se configura en los permisos de grupo, este bit controla la posición del "paquete de identidad de grupo" de un fichero. Actúa de la misma manera que el SUID, excepto en que es el grupo el afectado. El fichero debe ser ejecutable para que esto tenga algún efecto.
Atributo SGID: (Para directorios)
Si pones el bit SGID en un directorio (con chmod g+s directory), los ficheros creados en ese directorio tendrán su configuración de grupo para el grupo del directorio.
Tú - El dueño del fichero
Grupo - El grupo al que perteneces
Cualquiera - Cualquiera en el sistema que no es el propietario o un miembro del grupo
Ejemplos de Fichero: -rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin 1st bit - directorio? (no) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (no) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (no) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(no)
Las siguientes líneas son ejemplos de los conjuntos mínimos de permisos que se requieren para realizar el acceso descrito. Si quieres puedes dar más permisos de los que están listados aquí, pues esto describe lo que hacen estos permisos mínimos sobre los ficheros: -r-------- Permite acceso de lectura al fichero por el dueño--w------- Permite al dueño modificar o borrar el fichero (Date cuenta que cualquiera con permiso de escritura en el directorio donde está el fichero puede sobreescribirlo y borrarlo)---x------ El dueño puede ejecutar ese programa, pero no scripts de shell, que requieren aún permiso de lectura---s------ Se ejecutará con ID Usuario = dueño efectivo --------s- Se ejecutará con ID Grupo = grupo efectivo-rw------T No pone al día "última fecha modificada". Normalmente se usa para ficheros swap---t------ Sin efecto. (anteriormente bit inmutable)
Ejemplo de Directorio: drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/ 1st bit - directorio? (sí, contiene muchos ficheros) 2nd bit - leer por dueño? (sí, por kevin) 3rd bit - escribir por dueño? (sí, por kevin) 4th bit - ejecutar por dueño? (sí, por kevin) 5th bit - leer por grupo? (sí, por usuarios) 6th bit - escribir por grupo? (no) 7th bit - ejecutar por grupo? (sí, por usuarios) 8th bit - leer por cualquiera? (sí, por cualquiera) 9th bit - escribir por cualquiera?(no) 10th bit - ejecutar por cualquiera?(sí, cualquiera)
Las líneas que siguen son ejemplos de los conjuntos mínimos de permisos que se requieren para ejecutar el acceso descrito. Si quieres, puedes dar más permisos de los aquí listados, pues esto describe lo que hacen estos permisos mínimos sobre directorios: dr-------- Los contenidos pueden listarse, pero los atributos del fichero no pueden ser leídosd--x------ Se puede entrar en el directorio, y usarse en paths de ejecución completosdr-x------ Los atributos del fichero pueden leerse por el dueñod-wx------ Los ficheros pueden ser creados/borrados, incluso si el directorio no es el activod------x-t Impide el borrado de ficheros por otros con acceso de escritura. Se usa en /tmpd---s--s-- Sin efecto
Los ficheros de configuración del sistema (normalmente en /etc) están usualmente en modo 640 (-rw-r-----) y el dueño es el root. Dependiendo de los requisitos de seguridad de tu sitio, puedes ajustar esto. Nunca dejes los ficheros de sistema escribibles por un grupo o por cualquiera. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deben ser legibles por el root y los directorios en /etc al menos no deben ser accesibles a otros.
Scripts de Shell SUID
Los scripts de shell SUID son un riesgo importante de seguridad y por esta razón el núcleo no les hace honores. Con independencia de lo seguro que tú consideres que es el script de shell, puede ser explotado para dar al cracker un shell de root.
Comprobar la Integridad con Tripwire Tripwire
Otra manera muy buena de detectar ataques locales sobre tu sistema (y también a la red) es correr un chequeador de integridad como Tripwire. Tripwire ejecuta varias comprobaciones tipo checksum en todos tus ficheros binarios y de configuración importantes y los compara contra una base de datos previa de valores de referencia bien conocidos. De este modo, todos los cambios en los ficheros se notarán.
Es una buena idea instalar Tripwire en un floppy y después ponerle físicamente la protección contra escritura en el floppy. De este modo, los intrusos no podrán entrometerse con el mismo Tripwire ni cambiar la base de datos. Una vez que tengas configurado Tripwire, es una buena idea ejecutarlo como parte de tus deberes normales de administración de seguridad para ver si algo ha cambiado.
Puedes incluso añadir una entrada crontab para ejecutar Tripwire desde tu floppy todas las noches y mandarte un "emilio" con los resultados por la mañana. Algo como: # set mailto MAILTO=kevin # run Tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire
te enviará por correo-e un informe cada mañana a las 5:15am.
Tripwire puede ser una bendición para detectar intrusos antes de que los notes de otro modo. Dado que cambian un montón de ficheros en el resultado del sistema, tienes que tener cuidado con lo que es la actividad del cracker y lo que es tu propia actividad.
Encontrarás grátis Tripwire en http://www.tripwiresecurity.com/. Los manuales y el soporte pueden comprarse.
Caballos Troyanos
Los "Caballos Troyanos" se denominan así por la artimaña que se cuenta en la "Iliada" de Homero. La idea es que un cracker distribuye un programa o binario que suena estupendo, y anima a otra gente a descargarlo y a ejecutarlo como root. Entonces el programa puede comprometer su sistema y ellos no se dan cuenta. Mientras piensan que el binario que acaban de bajarse hace una cosa (y muy bien podría hacerla), también compromete su seguridad.
Debes tener cuidado con qué programas instalas en tu máquina. Redhat proporciona comrpobaciones checksum MD5 y firmas PGP en sus ficheros RPM para que puedas verificar que estás instalando la cosa real. Otras distribuciones tienen similares métodos. ¡Nunca debes ejecutar como root cualquier binario desconocido, para el cual no tienes la fuente! Pocos atacantes quieren liberar el código fuente para escrutinio público.
Aunque puede ser complejo, asegúrate que obtienes la fuente de un programa desde su sitio de distribución auténtico. Si el programa se va a ejecutar como root, asegúrate de que o bien tú o bien alguien en quien confías ha mirado la fuente y la ha verificado.