Una desventaja añadida al sistema de auditoría en Unix puede ser la
complejidad que puede alcanzar una correcta configuración; por si la
dificultad del sistema no fuera suficiente, en cada Unix el sistema de logs tiene peculiaridades que pueden propiciar la pérdida de información
interesante de cara al mantenimiento de sistemas seguros. Aunque muchos de los
ficheros de log de los que hablaremos a continuación son comunes en
cualquier sistema, su localización, o incluso su formato, pueden variar entre
diferentes Unices.
Dentro de Unix hay dos grandes familias de sistemas: se trata de System
V y BSD; la localización de ficheros y ciertas órdenes relativas
a la auditoría de la máquina van a ser diferentes en ellas, por lo que
es muy recomendable consultar las páginas del manual antes de ponerse a
configurar el sistema de auditoría en un equipo concreto. La principal
diferencia entre ellos es el denominado process accounting o simplemente
accounting, consistente en registrar todos los programas ejecutados por
cada usuario; evidentemente, los informes generados en este proceso pueden
llegar a ocupar muchísimo espacio en disco (dependiendo del número de
usuarios en nuestro sistema) por lo que sólo es recomendable en situaciones
muy concretas, por ejemplo para detectar actividades sospechosas en una
máquina o para cobrar por el tiempo de CPU consumido. En los sistemas System V el process accounting está desactivado por defecto; se
puede iniciar mediante /usr/lib/acct/startup, y para visualizar los
informes se utiliza la orden acctcom. En la familia BSD los
equivalentes a estas órdenes son accton y lastcomm; en este
caso el process accounting está inicializado por defecto.
Un mundo aparte a la hora de generar (y analizar) informes acerca de las
actividades realizadas sobre una máquina Unix son los sistemas con el
modelo de auditoría C2 ([B$^+$85]); mientras que con el modelo
clásico se genera un registro tras la ejecución de cada proceso, en Unix
C2 se proporciona una pista de auditoría donde se registran los accesos
y los intentos de acceso de una entidad a un objeto, así como cada cambio
en el estado del objeto, la entidad o el sistema global. Esto se consigue
asignando un identificador denominado Audit ID a cada grupo de procesos
ejecutados (desde el propio login), identificador que se registra junto
a la mayoría de llamadas al sistema que un proceso realiza, incluyendo
algunas tan comunes como write(), open(), close() o read(). A nadie se le puede escapar la cantidad de espacio y de CPU necesarios
para mantener los registros a un nivel tan preciso, por lo que en la
mayoría de sistemas (especialmente en entornos habituales, como los
estudiados aquí) el modelo de
auditoría C2 es innecesario; y no sólo esto, sino que en muchas
ocasiones también se convierte en una monitorización inútil
([ALGJ98]) si no se dispone de mecanismos
para interpretar o reducir la gran cantidad de datos registrados: el
administrador guarda tanta información que es casi imposible analizarla en
busca de actividades sospechosas.
© 2002 Antonio Villalón Huerta
