Auditoría de sistemas UNIX. Parte 4. Los permisos de los ficheros del directorio /etc

Continuamos con nuestro mini curso de Auditoría UNIX, y esta vez, hacemos escala en una verificación corta, pero a su vez, crítica. Se trata de evaluar los permisos de los ficheros del directorio /etc

Este directorio es común en la mayoría de sistemas UNIX. /etc hace referencia, o eso eso se dice, a «etc cétera», es decir, un directorio donde encontraremos lo que no encontramos en el resto de directorios. Una especie de cajón de sastre, para que nos entendamos. Suele ser bastante voluminoso, con lo que normalmente, no dará tiempo a analizar toda su profundidad (ls recursivo). Por tanto, debemos establecer un mínimo, y ese mínimo serán algunos ficheros situados en la raíz del directorio /etc, aquellos que tradicionalmente se consideran más críticos. Los ficheros mínimos que debe contener /etc son:

/etc/resolv.conf
/etc/hosts
/etc/inittab
/etc/rc.d/rc.S
/etc/fstab

Habitualmente, se incluyen muchos más ficheros. La variabilidad no es muy elevada, pero existe, si comparamos distintas plataformas. Por ejemplo, en un sistemas Linux es frecuente hallar, entre otros:

/etc/passwd
/etc/fdprm
/etc/fstab
/etc/group
/etc/inittab
/etc/magic
/etc/motd
/etc/mtab
/etc/shadow
/etc/login.defs
/etc/profile, /etc/csh.login, /etc/csh.cshrc
/etc/securetty
/etc/shells
/etc/termcap

El objetivo de la auditoría es, en este caso, verificar que los parámetros de protección de esos ficheros son razonables. Para ello, debemos listar los contenidos de /etc, forzando la aparición de archivos ocultos, así como desplegando permisosos, propietario y grupos. Para ello, se utiliza el comando ls, tal y como sigue:

ls -al /etc | more

Donde -a implica forzar que se muestren ficheros ocultos, -l implica el modo «long» que mostrará los detalles, y more hace que podamos visualizarlo con pausas.

Lo normal es que esos ficheros vayan con permisos 644, sean propiedad del root y pertenezcan al grupo sys, si bien es relativamente frecuente que propietario y grupo sean bin, en virtud a la instalación que tienen algunos sistemas por defecto. Llegados a este punto, tenemos que hacer uso de una guía de militarización, en la que se nos dirá qué ficheros debemos mirar y qué permisos, propietario y grupo se recomienda que tengan. Por ejemplo, para UNIX en general, os recomiendo el libro del profesor Villalón Huerta Seguridad en Unix y Redes. Versión 2.1, que aún datando de 2002, es un excelente referente bibliográfico.

Usar una guía o libro sobre fortificación de la plataforma que estemos auditando no es un consejo gratuíto. UNIX tiene patrones comunes, pero existe una enorme variabilidad en los detalles. Un ejemplo de esa varianza la tenemos, volviendo al ejemplo de Linux, en la auditoría de permisos del fichero /etc/securetty, que enumera los terminales desde los que el súper usuario puede autenticarse directamente contra el sistema. Lo que en Linux es /etc/securetty …

Es /etc/security/user en un sistema AIX.
Es /etc/ttys en FreeBSD, NetBSD y OpenBSD.
Es /etc/default/login en IRIX, Solaris, Reliant y NRC Unix.
Es /dev/default/login en SCO Unixware.
Es /etc/securettys en Tru64 y Ultrix.

Es también /etc/securetty en HP-UX.

Según la plataforma que estemos auditando, en algunas ocasiones encontraremos guías libres que podemos descargar y usar, y en otras ocasiones, lo recomendable, bien por su calidad o por ausencia de material libre, será la compra. Ya es tarea de cada auditor saber pertrecharse de la bibliografía que considere adecuada y necesaria.

Resumen

Es fundamental revisar con hincapié el directorio /etc y comprobar que os ficheros que contiene, críticos en el sistema, estén adecuadamente protegidos por los permisos, propietario y grupos aconsejados por la guía de militarización correspondiente.

Cada sistema tiene sus propias peculiaridades, pero es relativamente frecuente que los permisos más aconsejables para este tipo de ficheros sean 644, es decir, lectura para propietario, grupo y otros, y escritura sólo para el propietario. En cuanto a propietario y grupo, es frecuente que el primero sea root y el segundo, sys, siendo bastante frecuente que la instalación por defecto deje propietario y grupos a bin, opción generalmente válida según la naturaleza de la fortificación del sistema.

No debe olvidarse que los enlaces simbólicos, aunque no representan al fichero al que apuntan, sí pueden ser adulterados si no están debidamente protegidos, con lo que deben estudiarse igualmente.