Auditorias de sistemas con auditctl, Kali, Linis

auditctl

Auditorias de sistemas con auditctl.

En este articulo se muestran todas las actuacioes dirigidas para auditar nuestro sistema, los aspectos mas importantes son los usuarios, los sistemas y las redes, para personalozar nuestra auditoria habra que tener en cuenta una serie de parametros, que nos ayuden a configurar nuestros scripts, para dicho analisis, en el documento adjunto se muestran todos los comando dirigidos a ejecutar el analisis, con lo que tendremos que tener en cuenta:

Auditoría del sistema

La auditoría no proporciona seguridad adicional a su sistema; más bien, puede utilizarse para descubrir violaciones de las políticas de seguridad utilizadas en su sistema. Estas violaciones pueden evitarse además con medidas de seguridad adicionales como SELinux.

Auditoría Linux

El sistema de Auditoría de Linux proporciona una manera de rastrear la información relevante para la seguridad en su sistema. Basado en reglas preconfiguradas, Audit genera entradas de registro para registrar tanta información como sea posible sobre los eventos que están ocurriendo en su sistema. Esta información es crucial para que los entornos de misión crítica puedan determinar quién ha violado la política de seguridad y las acciones que ha realizado.

La siguiente lista resume parte de la información que Audit es capaz de registrar en sus archivos de registro:

Fecha y hora, tipo y resultado de un evento.
Etiquetas de sensibilidad de sujetos y objetos.
Asociación de un evento con la identidad del usuario que lo ha provocado.
Todas las modificaciones de la configuración de Auditoría y los intentos de acceso a los archivos de registrhttps://7bfa25248c.clvaw-cdnwnd.com/28cae5c138c1390a6b4fa440901bd7e6/200001164-5550e55510/Auditar%20Informaci%C3%B3n%20del%20Sistema-0.pdf?ph=7bfa25248co de Auditoría.
Todos los usos de los mecanismos de autenticación, como SSH, Kerberos y otros.
Cambios en cualquier base de datos de confianza, como /etc/passwd.
Intentos de importar o exportar información hacia o desde el sistema.
Incluya o excluya eventos en función de la identidad del usuario, las etiquetas de sujetos y objetos, y otros atributos.

El uso del sistema Audit también es un requisito para una serie de certificaciones relacionadas con la seguridad. Audit está diseñado para cumplir o superar los requisitos de las siguientes certificaciones o guías de cumplimiento:

Perfil de protección de acceso controlado (CAPP)
Perfil de protección de seguridad etiquetado (LSPP)
Control de acceso basado en conjuntos de reglas (RSBAC)
Manual operativo del Programa Nacional de Seguridad Industrial (NISPOM)
Ley Federal de Gestión de la Seguridad de la Información (FISMA)
Industria de las tarjetas de pago
Guías técnicas de aplicación de la seguridad (STIG)

La auditoría ha sido verificada por:

Evaluado por National Information Assurance Partnership (NIAP) y Best Security Industries (BSI).
Certificado para LSPP/CAPP/RSBAC/EAL4 en Red Hat Enterprise Linux 8.
Certificado para el Perfil de Protección del Sistema Operativo / Nivel de Garantía de Evaluación 4 (OSPP/EAL4 ) en Red Hat Enterprise Linux 8 y 9.

Casos de uso

Vigilancia del acceso a los archivos

La auditoría puede rastrear si se ha accedido a un archivo o a un directorio, si se ha modificado, si se ha ejecutado o si se han cambiado los atributos del archivo. Esto es útil, por ejemplo, para detectar el acceso a archivos importantes y tener un rastro de Auditoría disponible en caso de que uno de estos archivos se corrompa.

Supervisión de las llamadas del sistema

La auditoría puede configurarse para generar una entrada de registro cada vez que se utiliza una llamada del sistema en particular. Esto puede utilizarse, por ejemplo, para rastrear los cambios en la hora del sistema mediante la supervisión de las llamadas al sistema settimeofday, clock_adjtime, y otras relacionadas con la hora.

Grabación de los comandos ejecutados por un usuario

La auditoría puede rastrear si un archivo ha sido ejecutado, por lo que se pueden definir reglas para registrar cada ejecución de un comando en particular. Por ejemplo, se puede definir una regla para cada ejecutable en el directorio /bin. Las entradas de registro resultantes pueden buscarse por ID de usuario para generar un registro de auditoría de los comandos ejecutados por usuario.

Grabación de la ejecución de los nombres de ruta del sistema

Además de vigilar el acceso a los archivos que traduce una ruta a un inodo en la invocación de la regla, Auditoría puede ahora vigilar la ejecución de una ruta incluso si no existe en el momento de la invocación de la regla, o si el archivo es reemplazado después de la invocación de la regla. Esto permite que las reglas sigan funcionando después de actualizar el ejecutable de un programa o incluso antes de instalarlo.

Registro de eventos de seguridad

El módulo de autenticación pam_faillock es capaz de registrar los intentos fallidos de inicio de sesión. La auditoría puede configurarse para registrar también los intentos de inicio de sesión fallidos y proporciona información adicional sobre el usuario que intentó iniciar sesión.
Búsqueda de eventos

Audit proporciona la utilidad ausearch, que se puede utilizar para filtrar las entradas del registro y proporcionar una pista de auditoría completa basada en varias condiciones.
Ejecución de infAuditoría Linux.

Arquitectura del sistema de auditoría

El sistema de auditoría consta de dos partes principales: las aplicaciones y utilidades del espacio de usuario y el procesamiento de las llamadas al sistema del lado del núcleo. El componente del núcleo recibe las llamadas al sistema de las aplicaciones del espacio del usuario y las filtra a través de uno de los siguientes filtros: user, task, fstype, o exit.

Una vez que una llamada al sistema pasa el filtro exclude, es enviada a través de uno de los filtros mencionados, el cual, basado en la configuración de la regla de Auditoría, la envía al demonio de Auditoría para su posterior procesamiento.

El demonio de Auditoría del espacio de usuario recoge la información del kernel y crea entradas en un archivo de registro. Otras utilidades de espacio de usuario de Auditoría interactúan con el demonio de Auditoría, el componente de Auditoría del kernel o los archivos de registro de Auditoría:

auditctl
Las restantes utilidades de Auditoría toman el contenido de los archivos de registro de Auditoría como entrada y generan una salida basada en los requerimientos del usuario. Por ejemplo, la utilidad aureport genera un informe de todos los eventos registrados.

En RHEL 8, la funcionalidad del demonio despachador de Auditoría (audisp) está integrada en el demonio de Auditoría (auditd). Los archivos de configuración de los plugins para la interacción de los programas analíticos en tiempo real con los eventos de Audit se encuentran por defecto en el directorio /etc/audit/plugins.d/.

Configuración de auditd para un entorno seguro

La configuración por defecto de auditd debería ser adecuada para la mayoría de los entornos. Sin embargo, si su entorno tiene que cumplir con políticas de seguridad estrictas, se sugieren los siguientes ajustes para la configuración del demonio de auditoría en el archivo /etc/audit/auditd.conf:

archivo_de_registro El directorio que contiene los archivos de registro de Auditoría (normalmente /var/log/audit/) debería residir en un punto de montaje separado. Esto evita que otros procesos consuman espacio en este directorio y proporciona una detección precisa del espacio restante para el demonio de Auditoría. archivo_de_registro_máximo Especifica el tamaño máximo de un solo archivo de registro de Auditoría, debe establecerse para hacer uso completo del espacio disponible en la partición que contiene los archivos de registro de Auditoría. max_log_file_action Decide qué acción se lleva a cabo una vez que se alcanza el límite establecido en max_log_file, debería establecerse en keep_logs para evitar que se sobrescriban los archivos de registro de auditoría. espacio_izquierdo Especifica la cantidad de espacio libre que queda en el disco para que se active una acción establecida en el parámetro space_left_action. Debe establecerse un número que dé al administrador tiempo suficiente para responder y liberar espacio en el disco. El valor de space_left depende de la velocidad a la que se generan los archivos de registro de auditoría.

acción_espacio_izquierda Se recomienda establecer el parámetro space_left_action en email o exec con un método de notificación apropiado. espacio_administrador_izquierdo Especifica la cantidad mínima absoluta de espacio libre para la cual se desencadena una acción establecida en el parámetro admin_space_left_action, debe establecerse en un valor que deje suficiente espacio para registrar las acciones realizadas por el administrador. admin_space_left_action Se debe establecer en single para poner el sistema en modo monopuesto y permitir al administrador liberar algo de espacio en el disco. disk_full_action Especifica una acción que se desencadena cuando no hay espacio libre disponible en la partición que contiene los archivos de registro de Auditoría, debe establecerse en halt o single. Esto asegura que el sistema se apague o funcione en modo monopuesto cuando Audit no pueda registrar más eventos. acción_error_disco Especifica una acción que se desencadena en caso de que se detecte un error en la partición que contiene los archivos de registro de auditoría, debe establecerse en syslog, single, o halt, dependiendo de sus políticas locales de seguridad en relación con el manejo de los fallos de hardware. descarga Debe establecerse en incremental_async. Funciona en combinación con el parámetro freq, que determina cuántos registros pueden enviarse al disco antes de forzar una sincronización con el disco duro. El parámetro freq debe ajustarse a 100. Estos parámetros aseguran que los datos de los eventos de Auditoría estén sincronizados con los archivos de registro en el disco, manteniendo un buen rendimiento para las ráfagas de actividad.

El resto de las opciones de configuración deben establecerse de acuerdo con su política de seguridad local.

Inicio y control de la auditoría

Una vez configurado auditd, inicie el servicio para recoger la información de auditoría y almacenarla en los archivos de registro. Utiliza el siguiente comando como usuario root para iniciar auditd:

# service auditd start

Para configurar auditd para que se inicie en el momento del arranque:

# systemctl enable auditd

Se pueden realizar otras acciones en auditd utilizando el comando service auditd action donde action puede ser uno de los siguientes:

stop Para auditd. restart Reinicia auditd. reload o force-reload Recarga la configuración de auditd desde el archivo /etc/audit/auditd.conf. rotate Rota los archivos de registro en el directorio /var/log/audit/. resume Reanuda el registro de eventos de Auditoría después de haber sido suspendido previamente, por ejemplo, cuando no hay suficiente espacio libre en la partición del disco que contiene los archivos de registro de Auditoría. condrestart o try-restart Reinicia auditd sólo si ya está en marcha. status Muestra el estado de funcionamiento de auditd.

Comprensión de los archivos de registro de auditoría

Por defecto, el sistema de Auditoría almacena las entradas de registro en el archivo /var/log/audit/audit.log; si se activa la rotación de registros, los archivos audit.log rotados se almacenan en el mismo directorio.

Añada la siguiente regla de auditoría para registrar cada intento de lectura o modificación del archivo /etc/ssh/sshd_config:

# auditctl -w /etc/ssh/sshd_config -p warx -k sshd_config

Si el demonio auditd se está ejecutando, por ejemplo, el siguiente comando crea un nuevo evento en el archivo de registro de auditoría:

$ cat /etc/ssh/sshd_config

Este evento en el archivo audit.log tiene el siguiente aspecto:

type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config" type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman" type=PATH msg=audit(1364481363.243:24287): item=0 inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1364481363.243:24287) : proctitle=636174002F6574632F7373682F737368645F636F6E666967

El evento anterior consta de cuatro registros, que comparten el mismo sello de tiempo y número de serie. Los registros siempre comienzan con la palabra clave type=. Cada registro consta de varios name=value pares separados por un espacio en blanco o una coma. A continuación se presenta un análisis detallado del suceso anterior:

Primer disco

type=SYSCALL El campo type contiene el tipo de registro. En este ejemplo, el valor SYSCALL especifica que este registro fue activado por una llamada del sistema al kernel. msg=audit(1364481363.243:24287):

El campo msg registra:

un sello de tiempo y un ID único del registro en la forma audit(time_stamp:ID). Varios registros pueden compartir la misma marca de tiempo e ID si se generaron como parte del mismo evento de auditoría. El sello de tiempo utiliza el formato de tiempo Unix - segundos desde las 00:00:00 UTC del 1 de enero de 1970.
varios pares de eventos específicos name=value proporcionados por el kernel o las aplicaciones del espacio de usuario.

arch=c000003e El campo arch contiene información sobre la arquitectura de la CPU del sistema. El valor, c000003e, está codificado en notación hexadecimal. Cuando busque registros de auditoría con el comando ausearch, utilice la opción -i o --interpret para convertir automáticamente los valores hexadecimales en sus equivalentes legibles para el ser humano. El valor c000003e se interpreta como x86_64. syscall=2 El campo syscall registra el tipo de llamada al sistema que se envió al kernel. El valor, 2, puede ser comparado con su equivalente legible por humanos en el archivo /usr/include/asm/unistd_64.h. En este caso, 2 es la llamada al sistema open. Tenga en cuenta que la utilidad ausyscall le permite convertir los números de las llamadas al sistema en sus equivalentes legibles para el ser humano. Utilice el comando ausyscall --dump para mostrar un listado de todas las llamadas al sistema junto con sus números. Para más información, consulte la página de manual ausyscall(8). success=no El campo success registra si la llamada al sistema registrada en ese evento concreto tuvo éxito o fracasó. En este caso, la llamada no tuvo éxito. exit=-13

El campo exit contiene un valor que especifica el código de salida devuelto por la llamada al sistema. Este valor varía según la llamada al sistema. Puede interpretar el valor a su equivalente legible para humanos con el siguiente comando:

# ausearch --interpret --exit -13

Tenga en cuenta que el ejemplo anterior asume que su registro de auditoría contiene un evento que falló con el código de salida -13.

a0=7fffd19c5592, a1=0, a2=7fffd19c5592, a3=a Los campos a0 a a3 registran los cuatro primeros argumentos, codificados en notación hexadecimal, de la llamada al sistema en este evento. Estos argumentos dependen de la llamada al sistema que se utilice; pueden ser interpretados por la utilidad ausearch. items=1 El campo items contiene el número de registros auxiliares PATH que siguen al registro syscall. ppid=2686 El campo ppid registra el ID del proceso padre (PPID). En este caso, 2686 era el PPID del proceso padre como bash. pid=3538 El campo pid registra el ID del proceso (PID). En este caso, 3538 era el PID del proceso cat. auid=1000 El campo auid registra el ID de usuario de la auditoría, es decir, el loginuid. Este ID se asigna a un usuario al iniciar la sesión y es heredado por todos los procesos, incluso cuando la identidad del usuario cambia, por ejemplo, al cambiar de cuenta de usuario con el comando su - john. uid=1000 El campo uid registra el ID del usuario que inició el proceso analizado. El ID de usuario puede ser interpretado en nombres de usuario con el siguiente comando ausearch -i --uid UID. gid=1000 El campo gid registra el ID del grupo del usuario que inició el proceso analizado. euid=1000 El campo euid registra el ID de usuario efectivo del usuario que inició el proceso analizado. suid=1000 En el campo suid se registra el ID del usuario que inició el proceso analizado. fsuid=1000 El campo fsuid registra el ID de usuario del sistema de archivos del usuario que inició el proceso analizado. egid=1000 El campo egid registra el ID de grupo efectivo del usuario que inició el proceso analizado. sgid=1000 En el campo sgid se registra el ID del grupo del usuario que inició el proceso analizado. fsgid=1000 El campo fsgid registra el ID del grupo del sistema de archivos del usuario que inició el proceso analizado. tty=pts0 El campo tty registra el terminal desde el que se invocó el proceso analizado. ses=1 El campo ses registra el ID de la sesión desde la que se invocó el proceso analizado. comm="cat" El campo comm registra el nombre de la línea de comandos que se utilizó para invocar el proceso analizado. En este caso, se utilizó el comando cat para activar este evento de Auditoría. exe="/bin/cat" El campo exe registra la ruta del ejecutable que se utilizó para invocar el proceso analizado.

subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 El campo subj registra el contexto SELinux con el que el proceso analizado fue etiquetado en el momento de la ejecución. key="sshd_config" El campo key registra la cadena definida por el administrador asociada a la regla que generó este evento en el registro de auditoría.

Segundo disco

type=CWD

En el segundo registro, el valor del campo type es CWD

El propósito de este registro es registrar la ubicación del proceso actual en caso de que una ruta relativa termine siendo capturada en el registro PATH asociado. De esta manera se puede reconstruir la ruta absoluta.

msg=audit(1364481363.243:24287) El campo msg contiene la misma marca de tiempo y valor de identificación que el valor del primer registro. El sello de tiempo utiliza el formato de tiempo Unix - segundos desde las 00:00:00 UTC del 1 de enero de 1970. cwd="/home/user_name" El campo cwd contiene la ruta del directorio en el que se invocó la llamada al sistema.

Tercer disco

type=PATH En el tercer registro, el valor del campo type es PATH. Un evento de Auditoría contiene un registro de tipo PATH para cada ruta que se pasa a la llamada del sistema como un argumento. En este evento de auditoría, sólo se utilizó una ruta (/etc/ssh/sshd_config) como argumento. msg=audit(1364481363.243:24287): El campo msg contiene el mismo sello de tiempo y valor de identificación que el valor del primer y segundo registro. item=0 El campo item indica de qué artículo, del total de artículos referenciados en el registro de tipo SYSCALL, se trata el registro actual. Este número está basado en cero; un valor de 0 significa que es el primer elemento. name="/etc/ssh/sshd_config" El campo name registra la ruta del archivo o directorio que se pasó a la llamada del sistema como argumento. En este caso, fue el archivo /etc/ssh/sshd_config. inode=409248

El campo inode contiene el número de inodo asociado al archivo o directorio registrado en este evento. El siguiente comando muestra el archivo o directorio que está asociado con el número de inodo 409248:

# find / -inum 409248 -print /etc/ssh/sshd_config dev=fd:00 El campo dev especifica el ID menor y mayor del dispositivo que contiene el archivo o directorio registrado en este evento. En este caso, el valor representa el dispositivo /dev/fd/0. mode=0100600 El campo mode registra los permisos de los archivos o directorios, codificados en notación numérica tal y como los devuelve el comando stat en el campo st_mode. Consulte la página de manual stat(2) para obtener más información. En este caso, 0100600 puede interpretarse como -rw-------, lo que significa que sólo el usuario root tiene permisos de lectura y escritura en el archivo /etc/ssh/sshd_config. ouid=0 El campo ouid registra el ID de usuario del propietario del objeto. ogid=0 El campo ogid registra el ID del grupo del propietario del objeto. rdev=00:00 El campo rdev contiene un identificador de dispositivo grabado sólo para archivos especiales. En este caso, no se utiliza ya que el archivo grabado es un archivo normal. obj=system_u:object_r:etc_t:s0 El campo obj registra el contexto SELinux con el que el archivo o directorio registrado fue etiquetado en el momento de la ejecución. nametype=NORMAL El campo nametype registra la intención de la operación de cada registro de ruta en el contexto de una determinada syscall. cap_fp=none El campo cap_fp registra datos relacionados con la configuración de una capacidad permitida basada en el sistema de archivos del objeto de archivo o directorio. cap_fi=none El campo cap_fi registra datos relacionados con la configuración de una capacidad heredada basada en el sistema de archivos del objeto de archivo o directorio. cap_fe=0 El campo cap_fe registra la configuración del bit efectivo de la capacidad basada en el sistema de archivos del objeto de archivo o directorio. cap_fver=0 El campo cap_fver registra la versión de la capacidad basada en el sistema de archivos del objeto de archivo o directorio.

Cuarto disco

type=PROCTITLE El campo type contiene el tipo de registro. En este ejemplo, el valor PROCTITLE especifica que este registro da la línea de comandos completa que desencadenó este evento de Auditoría, desencadenado por una llamada del sistema al kernel. proctitle=636174002F6574632F7373682F737368645F636F6E666967 El campo proctitle registra la línea de comandos completa del comando que se utilizó para invocar el proceso analizado. El campo está codificado en notación hexadecimal para no permitir que el usuario influya en el analizador del registro de Auditoría. El texto se decodifica al comando que desencadenó este evento de Auditoría. Al buscar registros de Auditoría con el comando ausearch, utilice la opción -i o --interpret para convertir automáticamente los valores hexadecimales en sus equivalentes legibles para el ser humano. El valor 636174002F6574632F7373682F737368645F636F6E666967 se interpreta como cat /etc/ssh/sshd_config.

Uso de augenrules para definir reglas persistentes

El script augenrules lee las reglas ubicadas en el directorio /etc/audit/rules.d/ y las compila en un archivo audit.rules. Este script procesa todos los archivos que terminan en .rules en un orden específico basado en su orden natural de clasificación. Los archivos de este directorio están organizados en grupos con los siguientes significados:

10 - Configuración del kernel y auditctl
20 - Reglas que podrían coincidir con las reglas generales pero que usted quiere que coincidan de otra manera
30 - Normas principales
40 - Normas opcionales
50 - Reglas específicas del servidor
70 - Normas locales del sistema
90 - Finalizar (inmutable)

Las normas no están pensadas para ser utilizadas todas a la vez. Son piezas de una política que deben ser pensadas y copiadas individualmente en /etc/audit/rules.d/. Por ejemplo, para establecer un sistema en la configuración STIG, copie las reglas 10-base-config, 30-stig, 31-privileged, y 99-finalize.

Una vez que tenga las reglas en el directorio /etc/audit/rules.d/, cárguelas ejecutando el script augenrules con la directiva --load:

# augenrules --load /sbin/augenrules: No change No rules enabled 1 failure 1 pid 742 rate_limit 0 ...

Recursos adicionales

Para más información sobre las reglas de auditoría y el script augenrules, consulte las páginas de manual audit.rules(8) y augenrules(8).

Los audit logs son registros de auditoría que contienen información detallada sobre eventos importantes que ocurren en un sistema o aplicación. Estos registros pueden incluir información sobre quién realizó una acción, qué acción se llevó a cabo, cuándo ocurrió y desde dónde se realizó la acción. Veamos ahora algunos de esos audit logs que debes conocer.

Audit logs

Los audit logs los pueden generar automáticamente los sistemas y aplicaciones y se pueden almacenar en un archivo de registro o en una base de datos de registro. Los datos de registro del audit logging también se pueden exportar y analizar mediante herramientas de análisis de registro especializadas para obtener información útil y detectar patrones de actividad sospechosos relacionados con el log management.

utmpdump /var /log /wtmp

Dentro del /var /log vamos a encontrar archivos como el wtmp:

Este no es un fichero como tal, sino una salida de log, y para ello tenemos que usar el comando utmpdump /var /log /wtmp. Con este comando podremos interpretar y lograr que este «fichero» sea legible para el ser humano. Veamos:

Este fichero nos da información sobre los login y los logout que hay en el sistema. En la imagen podemos ver, por ejemplo, que ha habido un login a las 15.

Si estamos trabajando en un sistema en vivo, es importante que saquemos un date para saber qué hora exacta es en la máquina. Por ejemplo en esta máquina se tiene el formato UTC de 24 horas y, en comparación con otra máquina, puede haber retrasos, por tanto, es importante determinar este tipo de cosas con nuestros audit logs.

El comando utmpdump
Es un comando de los audit logs en Linux que se utiliza para leer y mostrar información del archivo /var/log/wtmp y otros archivos.

El archivo wtmp se actualiza cada vez que un usuario inicia o cierra sesión en el sistema. La información en el archivo incluye el nombre de usuario, la hora de inicio de sesión, la duración de la sesión y otros detalles relacionados con el inicio y cierre de sesión de usuarios.

Al ejecutar el comando utmpdump /var/log/wtmp, se puede ver la información almacenada en el archivo wtmp en un formato legible para las personas. Este comando puede ser útil para el análisis y la solución de problemas relacionados con el uso del sistema y las actividades de los usuarios.

utmpdump /var /log /btmp

Este comando de audit logs nos dice qué consola se ha hincado para cada usuario y puede ser útil para identificar posibles intentos de piratería o actividades maliciosas en el sistema.

A diferencia de wtmp, el archivo btmp contiene información sobre los intentos fallidos de inicio de sesión en el sistema.

Cada vez que un usuario o un programa intenta iniciar sesión en el sistema utilizando credenciales inválidas, se registra una entrada en el archivo btmp. La información en el archivo incluye, como en el caso anterior, la fecha y la hora del intento de inicio de sesión, el nombre de usuario o el nombre del programa que intentó iniciar sesión y la dirección IP desde la que se originó el intento.

utmpdump /var /run /utmp

Este archivo de los audit logs contiene información sobre los usuarios que están actualmente conectados al sistema.

El archivo utmp lo actualizan continuamente el kernel del sistema operativo y los programas que administran el inicio y cierre de sesión de los usuarios. La información en el archivo incluye el nombre de usuario, la terminal en la que están conectados, la hora en la que se inició la sesión y el estado actual de la sesión. Este comando puede ser útil para verificar la cantidad de usuarios conectados al sistema en tiempo real y para obtener información sobre sus sesiones actuales.