Una herramienta fundamental para detección de intrusos es el registro de auditoría. Se utilizan varios registros de las actividades que va realizando el usuario como entrada para los sistemas detección intrusos.
Básicamente, dos de ellos son los más utilizados:
Registros de auditoría nativos. Prácticamente todos los sistemas operativos multiusuario incluyen un software de auditoría con el fin de registrar la actividad de los usuarios. La ventaja de utilizar esta información es que no se requiere ningún software adicional para recoger estos datos. La desventaja es que los registros de auditoría nativos pueden no tener la información necesaria que puede requerirse o que no esté en el formato conveniente.
Registros de auditoría específicos para detección. Se puede implementar una funcionalidad de recolección de datos que genere registros de auditoría que contienen información pensada únicamente para el sistema de detección de intrusos. Una ventaja de dicha estrategia es que puede realizarse de forma independiente del vendedor e implantarse en una amplia variedad de sistemas. La desventaja es que implica tener una sobrecarga extra, es decir, dos paquetes de auditoría ejecutándose en la misma máquina.
Un buen ejemplo de registros de auditoría específicos para detección son los desarrollados Dorothy Denning [DENN87]. Cada uno de los registros de auditoría tiene siguientes campos:
Sujeto. Iniciador de la acción. Un sujeto es típicamente un terminal de usuario o puede también ser un proceso que actúa de parte de un usuario o grupo de usuarios. La actividad parte de una serie de mandatos lanzados por estos sujetos. Los sujetos pueden agruparse en diferentes clases de acceso, y dichas clases pueden estar solapadas.
Acción. Operación realizada por el sujeto utilizando un objeto; por ejemplo acceso, lectura, operación de E/S, ejecución.
Objeto. El receptor de las acciones. Los ejemplos incluyen ficheros, programas, mensajes, registros, terminales, impresoras y estructuras creadas por los usuarios o los programas. Cuando un sujeto es el receptor de una acción, por ejemplo un correo electrónico, entonces el sujeto se considera un objeto. Los sujetos pueden agruparse por tipos. La granularidad de los objetos puede variar por el tipo de objeto y por el entorno. Por ejemplo, las acciones o las bases de datos pueden auditarse para toda la base de datos en conjunto o a nivel de registro.
Condiciones de excepción. Denota qué condiciones de excepción, si se dan, se lanzarían como respuesta.
Utilización de recursos. Una lista de los elementos cuantitativos en los cuales los elementos calculan la cantidad de recursos utilizados (por ejemplo, número de líneas impresas o mostradas, número de registros leídos o escritos, tiempo de procesador, unidades de E/S utilizadas, tiempo de sesión transcurrido).
Sello de tiempo. Un sello único de fecha y hora que identifica cuándo tuvo lugar esta acción.
Muchas de las operaciones de los usuarios constituyen varias acciones elementales. Por ejemplo, la copia de un fichero implica la ejecución de un programa de usuario, el cual incluye una verificación de acceso y el desarrollo de la copia propiamente dicha, más la lectura de un fichero, más la escritura de otro fichero. Consideremos el mandato
lanzado por Pepe para copiar un fichero ejecutable
JUEGO desde el directorio actual al directorio
<Dir>. Se generarían los siguientes registros
de auditoría:
En este caso, la operación de copia se ha abortado debido a que Pepe no tiene permisos escritura en <Dir>. La división de las operaciones de usuario en acciones elementales trae consigo tres ventajas:
1. Debido a que los objetos son las entidades del sistema bajo protección, la utilización de acciones elementales permite una auditoría de todo comportamiento que se refiere a un objeto. De esta forma, el sistema puede detectar intentos maliciosos de controles de acceso (notando esta anomalía en el número de la condición de excepción devuelto) y puede detectar las acciones maliciosas que han tenido éxito notando la anomalía en el conjunto de objetos accesibles por dicho sujeto.
2. Los registros de auditoría basados en un objeto sencillo y en una acción sencilla simplifican el modelo de implementación.
3. Debido a la estructura uniforme y sencilla de los registros de auditoría específicos para detección, es relativamente sencillo obtener esta información, o al menos parte de ella, proyectando directamente los registros de auditoría nativos actuales en los registros específicos para la detección.
Control de acceso
Una forma de protegerse de los ataques de contraseñas es denegar el acceso al oponente al fichero de contraseñas. Si la parte del fichero de contraseñas cifradas se encuentra accesible sólo para los usuarios con el nivel de privilegios adecuados, el oponente no podrá leerlo sin conocer previamente la contraseña del usuario privilegiado. [SPAF92] remarca diferentes fallos en esta estrategia:
1. Debido a que los objetos son las entidades del sistema bajo protección, la utilización de acciones elementales permite una auditoría de todo comportamiento que se refiere a un objeto. De esta forma, el sistema puede detectar intentos maliciosos de controles de acceso (notando esta anomalía en el número de la condición de excepción devuelto) y puede detectar las acciones maliciosas que han tenido éxito notando la anomalía en el conjunto de objetos accesibles por dicho sujeto.
2. Los registros de auditoría basados en un objeto sencillo y en una acción sencilla simplifican el modelo de implementación.
3. Debido a la estructura uniforme y sencilla de los registros de auditoría específicos para detección, es relativamente sencillo obtener esta información, o al menos parte de ella, proyectando directamente los registros de auditoría nativos actuales en los registros específicos para la detección.
Control de acceso
Una forma de protegerse de los ataques de contraseñas es denegar el acceso al oponente al fichero de contraseñas. Si la parte del fichero de contraseñas cifradas se encuentra accesible sólo para los usuarios con el nivel de privilegios adecuados, el oponente no podrá leerlo sin conocer previamente la contraseña del usuario privilegiado. [SPAF92] remarca diferentes fallos en esta estrategia:
- Muchos sistemas, incluyendo la mayoría de sistemas UNIX, son susceptibles a intromisiones de una forma que no venga anticipada. Una vez que el atacante ha conseguido acceder de alguna forma al sistema, puede tener una lista de contraseñas de forma que puede utilizar diferentes cuentas a lo largo de distintas sesiones de conexión para reducir el riesgo de ser detectado. O, un usuario que ya dispone de una cuenta puede desear utilizar otra para acceder a datos privilegiados o sabotear el sistema.
- Un accidente en la protección puede hacer que el fichero de contraseñas sea legible, comprometiendo de esta forma todas las cuentas.
- Algunos de los usuarios pueden tener cuentas en otras máquinas bajo otros dominios de protección, y en algunos casos utilizar la misma contraseña. Por tanto, si las contraseñas pueden leerse por cualquiera en otra máquina, una máquina diferente puede encontrarse comprometida bajo estas circunstancias. De esta forma, una estrategia más efectiva sería obligar a los usuarios a asignar contraseñas que sean difíciles de adivinar.
