Conceptos y terminología de auditoría

Los siguientes términos se usan para describir el servicio de auditoría. Algunas definiciones incluyen enlaces a descripciones más completas.

Tabla 28-1 Términos de auditoría de Oracle Solaris

Eventos de auditoría

Las acciones del sistema relacionadas con la seguridad se pueden auditar. Estas acciones auditables se definen como eventos de auditoría. Los eventos de auditoría se muestran en el archivo /etc/security/audit_event. Cada uno de los eventos de auditoría se define en el archivo mediante un número de evento, un nombre simbólico, una descripción breve y el conjunto de clases de auditoría al que pertenece el evento. Para obtener más información sobre el archivo audit_event, consulte la página del comando man audit_event(4).

Por ejemplo, la entrada siguiente define el evento de auditoría para la llamada del sistema exec():

7:AUE_EXEC:exec(2):ps,ex

Al preseleccionar para la auditoría la clase de auditoría ps o la clase de auditoría ex, las llamadas del sistema exec() se registran en la pista de auditoría.

La auditoría de Oracle Solaris maneja eventos atribuibles y no atribuibles. La política de auditoría divide los eventos en síncronos y asíncronos, de la siguiente manera:

• Eventos atribuibles: eventos que se pueden atribuir a un usuario. La llamada del sistema exec() se puede atribuir a un usuario, por lo tanto, se considera un evento atribuible. Todos los eventos atribuibles son eventos síncronos.

• Eventos no atribuibles: eventos que ocurren en el nivel de interrupción de núcleo o antes de que un usuario sea autenticado. La clase de auditoría na maneja los eventos de auditoría que no son atribuibles. Por ejemplo, el inicio del sistema es un evento no atribuible. La mayoría de los eventos no atribuibles son eventos asíncronos. Sin embargo, los eventos no atribuibles que tienen procesos asociados, como inicios de sesión fallidos, son eventos síncronos.

• Eventos síncronos: eventos que están asociados con un proceso en el sistema. La mayoría de los eventos del sistema son eventos síncronos.

• Eventos asíncronos: eventos que no están asociados con ningún proceso, por lo que no hay ningún proceso disponible para bloquear y más tarde reactivar. Los eventos de salida y entrada de la PROM, y de inicio del sistema inicial son ejemplos de eventos asíncronos.

Cuando la clase a la que un evento de auditoría pertenece está preseleccionada para la auditoría, el evento se registra en la pista de auditoría. Por ejemplo, al preseleccionar las clases de auditoría ps y na para la auditoría, las llamadas del sistema exec() y las acciones de inicio del sistema, entre otros eventos, se registran en la pista de auditoría.

Además de los eventos de auditoría que define el servicio de auditoría de Oracle Solaris, las aplicaciones de terceros pueden generar eventos de auditoría. Los números de evento de auditoría de 32768 a 65535 están disponibles para aplicaciones de terceros.

Clases de auditoría y preselección

Cada uno de los eventos de auditoría pertenece a una clase de auditoría o a clases de auditoría. Las clases de auditoría son contenedores prácticos para un gran número de eventos de auditoría. Cuando se preselecciona una clase para auditar, se especifica que todos los eventos de esa clase se deben registrar en la pista de auditoría. Puede preseleccionar para eventos de un sistema y para eventos iniciados por un usuario concreto. Una vez que el servicio de auditoría se está ejecutando, puede agregar clases de auditoría a las clases preseleccionadas o eliminarlas de dichas clases de manera dinámica.

• Preselección de todo el sistema: especifique valores predeterminados de todo el sistema para la auditoría en las líneas flags, naflags y plugin del archivo audit_control. El archivo audit_control se describe en Archivo audit_control. Consulte también la página del comando man audit_control(4).

• Preselección específica de usuario: especifique adiciones a los valores predeterminados de auditoría de todo el sistema para usuarios individuales en la base de datos audit_user.

  La máscara de preselección de auditoría determina las clases de eventos que se auditarán para un usuario. La máscara de preselección de auditoría del usuario es una combinación de valores predeterminados de todo el sistema y las clases de auditoría que se especifican para el usuario. Para obtener información más detallada, consulte Características de auditoría de proceso.

  La base de datos audit_user puede ser administrada localmente o por un servicio de nombres. Solaris Management Console proporciona la interfaz gráfica de usuario (GUI) para administrar la base de datos. Para obtener detalles, consulte la página del comando man audit_user(4).

• Preselección dinámica: especifique clases de auditoría como argumentos para el comando auditconfig a fin de agregar esas clases de auditoría a un proceso o una sesión, o eliminarlas de un proceso o una sesión. Para obtener más información, consulte la página del comando man auditconfig(1M).

Un comando de postselección, auditreduce, permite seleccionar registros de los registros de auditoría preseleccionados. Para obtener más información, consulte Examen de la pista de auditoría y la página del comando man auditreduce(1M).

Las clases de auditoría se definen en el archivo /etc/security/audit_class. Cada entrada contiene la máscara de auditoría para la clase, el nombre para la clase y un nombre descriptivo para la clase. Por ejemplo, las definiciones de clase ps y na aparecen en el archivo audit_class, de la siguiente manera:

0x00100000:ps:process start/stop
0x00000400:na:non-attribute

Hay 32 clases de auditoría posibles. Las clases incluyen las dos clases globales: all y no. Las clases de auditoría se describen en la página del comando man audit_class(4).

La asignación de eventos de auditoría a clases es configurable. Puede eliminar eventos de una clase, agregar eventos a una clase y crear una nueva clase para colocar eventos seleccionados. Para conocer el procedimiento, consulte Cómo cambiar una pertenencia a clase de un evento de auditoría.

Registros de auditoría y tokens de auditoría

Cada registro de auditoría registra la aparición de un único evento auditado. El registro incluye información, como quién realizó la acción, qué archivos fueron afectados, qué acción se intentó realizar y dónde y cuándo ocurrió la acción. El siguiente ejemplo muestra un registro de auditoría login:

header,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login
return,success,0

El tipo de información que se guarda para cada uno de los eventos de auditoría se define mediante un conjunto de tokens de auditoría. Cada vez que un registro de auditoría se crea para un evento, el registro contiene algunos de los tokens o todos los tokens que se definen para el evento. La naturaleza del evento determina qué tokens se registran. En el ejemplo anterior, cada línea empieza con el nombre del token de auditoría. El contenido del token de auditoría sigue al nombre. Juntos, los cuatro tokens de auditoría componen el registro de auditoría login.

Para obtener una descripción detallada de la estructura de cada token de auditoría con un ejemplo de salida de praudit, consulte Formatos de token de auditoría. Para obtener una descripción de la cadena binaria de tokens de auditoría, consulte la página del comando man audit.log(4).

Módulos de complemento de auditoría

Puede especificar módulos de complemento de auditoría para manejar los registros que la preselección ha colocado en la cola de la auditoría. Los complementos son entradas en el archivo audit_control.

• Complemento audit_binfile.so: maneja la entrega de la cola de la auditoría a los archivos de auditoría binarios. En el archivo audit_control, si no se especifica ningún complemento y la entrada dir tiene un valor, el daemon de auditoría utiliza este complemento.

• Complemento audit_syslog.so: maneja la entrega de registros seleccionados de la cola de la auditoría a los registros syslog.

Para ver la sintaxis del archivo audit_control, consulte la página del comando man audit_control(4). Para obtener más ejemplos, consulte las tareas en Configuración de archivos de auditoría (mapa de tareas).

Para obtener información sobre los complementos, consulte las páginas del comando man audit_binfile(5), audit_syslog(5) y audit_control(4).

Registros de auditoría

Los registros de auditoría se recopilan en registros de auditoría. La auditoría de Oracle Solaris proporciona dos modos de salida para registros de auditoría. Los registros que se denominan archivos de auditoría almacenan registros de auditoría en formato binario. El conjunto de archivos de auditoría de un sistema o sitio proporcionan un registro de auditoría completo. El registro de auditoría completo se denomina pista de auditoría.

La utilidad syslog recopila y almacena resúmenes en versión de texto del registro de auditoría. Un registro syslog no está completo. El siguiente ejemplo muestra una entrada syslog para un registro de auditoría login:

Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

Un sitio puede almacenar registros de auditoría en ambos formatos. Puede configurar los sistemas del sitio para utilizar el modo binario, para utilizar el modo syslog o para utilizar ambos modos. En la siguiente tabla, se comparan registros de auditoría binarios con registros de auditoría syslog.

Tabla 28-2 Comparación de registros de auditoría binarios con registros de auditoría syslog

Los registros binarios proporcionan la mayor seguridad y cobertura. La salida binaria cumple los requisitos de certificaciones de seguridad, como el perfil de protección de acceso controlado de criterios comunes (CAPP). Los registros se escriben en un sistema de archivos que se protege para evitar que sea espiado. En un único sistema, todos los registros binarios se recopilan y se muestran en orden. La indicación de hora del GMT en registros binarios permite realizar una comparación exacta cuando los sistemas en una pista de auditoría se distribuyen entre zonas horarias. El comando praudit -x permite ver los registros en un explorador, en XML. También puede utilizar secuencias de comandos para analizar la salida XML.

En contraste, los registros syslog proporcionan una mayor comodidad y flexibilidad. Por ejemplo, puede recopilar los datos de syslog de un gran variedad de orígenes. Además, al supervisar eventos audit.notice en el archivo syslog.conf, la utilidad syslog registra un resumen de registros de auditoría con la indicación de hora actual. Puede utilizar las mismas herramientas de análisis y de gestión que ha desarrollado para mensajes syslog de una gran variedad de orígenes, incluidos estaciones de trabajo, servidores, cortafuegos y enrutadores. Los registros se pueden consultar en tiempo real y se pueden almacenar en un sistema remoto.

Si usa syslog.conf para almacenar registros de auditoría de manera remota, está protegiendo los datos del registro para evitar que los modifique o elimine un agresor. Por otro lado, cuando los registros de auditoría se almacenan de manera remota, los registros son susceptibles a ataques de red, como denegación de servicio y direcciones de origen simuladas. También, el UDP puede eliminar paquetes o puede entregar paquetes que no funcionan. El límite en entradas syslog es de 1024 caracteres, por lo que algunos registros de auditoría podrían estar truncados en el registro. En un único sistema, no se recopilan todos los registros de auditoría. Los registros podrían no aparecer en orden. Debido a que cada registro de auditoría se indica con la fecha y la hora del sistema local, usted no se puede basar en la indicación de hora para construir una pista de auditoría para varios sistemas.

Para obtener más información sobre registros de auditoría, consulte lo siguiente:

• audit_syslog(5)

• audit.log(4)

• Cómo configurar registros de auditoría syslog

Almacenamiento de la pista de auditoría

Un directorio de auditoría contiene archivos de auditoría en formato binario. Una instalación típica utiliza muchos directorios de auditoría. El contenido de todos los directorios de auditoría compone la pista de auditoría. Los registros de auditoría se almacenan en directorios de auditoría en el siguiente orden:

• Directorio de auditoría principal: un directorio donde los archivos de auditoría de un sistema se colocan en condiciones normales.

• Directorio de auditoría secundario: un directorio donde los archivos de auditoría de un sistema se colocan si el directorio de auditoría principal está lleno o no está disponible.

• Directorio de último recurso: un directorio de auditoría local que se usa si el directorio de auditoría principal y todos los directorios de auditoría secundarios no están disponibles.

Los directorios se especifican en el archivo audit_control. Un directorio no se utiliza hasta que un directorio que está antes en la lista está lleno. Para obtener un archivo audit_control anotado con una lista de entradas de directorio, consulte el Ejemplo 30-3.

Colocar los archivos de auditoría en el directorio root de auditoría predeterminado ayuda al revisor de auditoría cuando revisa la pista de auditoría. El comando auditreduce usa el directorio root de auditoría para encontrar todos los archivos en la pista de auditoría. El directorio root de auditoría predeterminado es /etc/security/audit. Este directorio está simbólicamente enlazado a /var/audit. Los archivos de auditoría en directorios que se denominan /var/audit/nombre de host/archivos son fácilmente encontrados por el comando auditreduce. Para obtener más información, consulte Comando auditreduce.

Examen de la pista de auditoría

El servicio de auditoría proporciona comandos para combinar y reducir archivos de la pista de auditoría. El comando auditreduce puede fusionar archivos de auditoría de la pista de auditoría. El comando también puede filtrar archivos para localizar eventos particulares. El comando praudit lee los archivos binarios. Las opciones para el comando praudit ofrecen una salida que es adecuada para las secuencias de comandos y para la presentación del explorador.