Manual de integridad de archivos Linux II

El presente manual es de adecuaciones al desarrollo de integridad de archivos de Linux, utilizando la versión 1.2.2 del plugin.

1 Características principales
2 ¿Cómo funciona?
3 Configuración en el servidor donde se implementará
4 Configuración en el servidor que se va a monitorear
5 Configuración de Operador Virtual
6 Configuración de ejecución automática
7 Interpretación en opConfig y opEvents

Características principales

Verificación de existencia de archivos: El plugin verifica si ciertos archivos específicos existen en los sistemas Linux de destino.
Recolección de metadatos de archivos: Para cada archivo que existe, recopila metadatos importantes:
- Fecha y hora de la última modificación.
- Tamaño del archivo.
- Propietario (usuario y grupo).
- Permisos del archivo.
Configuración de auditd: El plugin configura automáticamente el sistema de auditoría de Linux (auditd) para monitorear cambios en estos archivos mediante:
- Creación de reglas de auditoría personalizadas para cada archivo monitoreado.
- Especificación de operaciones a monitorear.
- Configuración de alertamiento.
- Reinicio del servicio auditd para aplicar los cambios.

¿Cómo funciona?

El plugin se conecta al sistema Linux de destino mediante SSH.
Verifica la existencia de cada ruta de archivo configurada.
Para los archivos existentes, recopila metadatos detallados.
Configura reglas de auditoría para monitorear cambios en estos archivos.
Organiza los resultados en tablas estructuradas para su visualización en opConfig.
Genera alertas para cualquier archivo que no se haya podido encontrar.

Configuración en el servidor donde se implementará

Importante: asegúrese de guardar backups de los archivos que ya existan en el servidor.
Importante: el panel de opEvents funciona únicamente en versión 4.5.1 y superiores. Asegúrese de que su versión está actualizada al menos a la versión 4.5.1.
Es indispensable tener instalado Net::OpenSSH en el servidor. Se puede comprobar ejecutando lo siguiente (deberás ver el texto “Está instalado”):

perl -MNet::OpenSSH -e 'print "Está instalado\n"'

Si se muestra una salida diferente, deberá de realizarse la instalación correspondiente.

Acceder a la ruta:

/etc/ssh/ssh_config.d/

Comentar la siguiente línea del archivo 04-ipa.conf y guardarlo. El nombre del archivo podría variar dependiendo del sistema operativo, pero esa instrucción deberá ser comentada donde corresponda.

# Match exec true

Reiniciar el demonio sshd, ejecutando:

service sshd restart

El plugin que se va a utilizar es la versión 1.3.4; si se tiene una versión previa, realizar el backup correspondiente.
Colocar el archivo de la versión 1.3.4 ( ) en la ruta:

/usr/local/omk/conf/config_plugins/

Información integral sobre este script

Su función es verificar la existencia y los metadatos de una lista predefinida de archivos (incluyendo creación, modificación, tamaño, permisos y propietario), así como la opcional configuración de reglas de monitoreo en auditd para observar accesos o cambios futuros sobre dichos archivos.

Acciones Realizadas

Conexión remota vía SSH:

Autenticación con usuario/contraseña o clave privada.
Validación de conexión previa.

Verificación de archivos definidos: Para cada archivo, se evalúan los siguientes metadatos mediante el comando stat, el cual se usa de forma segura, sin alterar los archivos ni su contenido.

Fecha de creación.
Fecha de última modificación.
Tamaño en bytes.
Propietario y grupo.
Permisos en formato octal.

Todas estas operaciones se realizan con sudo únicamente si el usuario tiene los privilegios requeridos.

Seguridad y restricciones:

Lectura exclusivamente: el script no modifica, crea ni elimina los archivos auditados.
No ejecuta comandos como echo, touch, chmod, rm, cp, mv, ni escribe sobre los archivos que está auditando.
Saneamiento de entradas: se remueven caracteres peligrosos en las rutas de archivo ($, \, ", ).
Ejecución controlada: solo se ejecutan comandos estáticos (stat, echo, mv, augenrules) en condiciones controladas.
Uso de sudo limitado y explícito, con validación de permisos antes de ejecutar acciones privilegiadas.
No hay acceso a contenido de archivos, solo metadatos del sistema de archivos.

Acciones NO realizadas por el script

No edita contenido de ningún archivo.
No ejecuta comandos destructivos o de escritura sobre los archivos auditados.
No modifica permisos, propietarios ni nombres de los archivos monitoreados.
No realiza acciones sin una configuración explícita.

El script linuxFileCheckCommands es una herramienta no intrusiva, segura y orientada a la inspección pasiva del estado de archivos. Su ejecución respeta el principio de mínima modificación, permitiendo asegurar la integridad de archivos clave en los nodos supervisados sin comprometer el entorno operativo.

Acceder a la ruta:

/usr/local/omk/conf/config_plugins/

Una vez dentro, ejecutar los siguientes 2 comandos:

chmod 664 linuxFileCheckCommands.pm
chown root:root linuxFileCheckCommands.pm

Acceder a la ruta:

/usr/local/omk/conf/command_sets.d/

Generar o adecuar el set de comandos con extensión .json, se recomienda nombrarlo como nombre-del-set.json. Deberá contener lo siguiente:

{
   "nombre-del-set": {
      "parameters": [],
      "purging_policy": {
         "keep_last": 0,
         "autoprotect_first_revision": null,
         "purge_older_than": null
      },
      "active": "true",
      "os_info": {
         "os": "/(Linux|CentOS|Ubuntu)/"
      },
      "scheduling_info": {
         "attempt_timeout_recovery": 0,
         "parameters_required": null,
         "run_local": null,
         "run_commands_on_separate_connection": null
      },
      "commands": [
         {
            "compare_to_previous_revision": null,
            "configure_auditd": 1,
            "language": "es",
            "report_level_min_changes": null,
            "use_collection_plugin": "linuxFileCheckCommands",
            "use_processing_plugins": [
               "linuxFileCheckCommands"
            ],
            "command": "echo test",
            "tags": [
               "nombre-del-nodo",
               "report-change",
               "detect-change"
            ],
            "file_integrity_paths": [
               {
                  "path": "/root/ejemplo1.txt",
                  "audit_execute": false,
                  "audit_attribute": true,
                  "audit_read": false,
                  "audit_write": true,
                  "audit_path": true,
                  "audit_alert": "fatal",
                  "requires_sudo": true
               },
               {
                  "path": "/usr/local/nmis9/conf/Config.nmis",
                  "audit_execute": false,
                  "audit_attribute": true,
                  "audit_read": false,
                  "audit_write": true,
                  "audit_path": true,
                  "audit_alert": "fatal",
                  "requires_sudo": true
               },
               {
                  "path": "/usr/local/ejemplo2.txt",
                  "audit_execute": false,
                  "audit_attribute": true,
                  "audit_read": false,
                  "audit_write": true,
                  "audit_path": true,
                  "audit_alert": "fatal"
               },
               {
                  "path": "/home/operador/ejemplo3.txt",
                  "audit_execute": false,
                  "audit_attribute": true,
                  "audit_read": false,
                  "audit_write": true,
                  "audit_path": true,
                  "audit_alert": "fatal"
               }
            ]
         }
      ]
   }
}

Nota: este set de comandos tiene diferencias a la configuración del primer manual, se recomienda realizar las validaciones correspondientes.
Comprobar sintaxis ejecutando el siguiente comando (deberá devolver todo el contenido del archivo .json; en caso de ver algún error, revisar en qué línea es):

jq . nombre-del-set.json

Los parámetros que deben ser adecuados para cada set de comandos son:

"nombre-del-set" -> se recomienda algo como NOMBREDELNODO_fim-linux; en este caso, el nombre del archivo tendrá que ser NOMBREDELNODO_fim-linux.json.
"plugin_interaction_timeout": 120, → este parámetro es por defecto por si el tiempo de conexión hacia los servidores que se van a monitorear es tardado; se recomienda dejar así.
"tags": ["nombre-del-nodo"], → se recomienda poner como tag el nombre del nodo; por ejemplo, si un nodo se llama SERVIDOR1, colocarlo tal cual dentro de las comillas.
"path": "/primera/ruta/archivo", → colocar la ruta exacta y tantas como se requieran; por ejemplo, si el archivo a monitorear es /var/log/logs.log, colocarlo tal cual.
"requires_sudo": true → esta opción únicamente se activa si el archivo a monitorear requiere permiso de root para poderse leer; por ejemplo, si antes de acceder a la carpeta se debe ejecutar un "sudo -i". Esto es debido a que algunos usuarios no tienen acceso de manera directa a estos paths, lo cual imposibilita verificar la existencia de los archivos que se colocan en este .json.

Posterior a la generación del archivo nombre-del-set.json, ejecutar:

chmod 664 nombre-del-set.json
chown root:root nombre-del-set.json

Acceder a la siguiente ruta:

/etc/rsyslog.d/

Generar el archivo 10-receive-omk-auditd-log.conf para recibir los logs. Contendrá lo siguiente:

# Enable UDP listener
module(load="imudp")
input(type="imudp" port="514")
# Enable TCP listener (optional)
module(load="imtcp")
input(type="imtcp" port="514")
# Template for storing remote logs
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
# Only process logs with programname/tag "auditplugin"
if $programname == 'auditplugin' then {
    ?RemoteLogs
    stop
}
*.* ?RemoteLogs

Posterior a la generación del archivo, ejecutar lo siguiente:

chmod 640 10-receive-omk-auditd-log.conf
chown root:root 10-receive-omk-auditd-log.conf
service rsyslog restart

Será necesario comenzar a ingerir los logs de auditd. Acceder a la ruta:

/usr/local/omk/conf

Editar el archivo opCommon.json e identificar la sección "opevents_logs". Ahí, deberá de realizarse la siguiente modificación:

de:

"nmis_eventlog" : [
  "<nmis9_logs>/event.log"
 ],

a

 "nmis_eventlog_alt" : [
    "/usr/local/nmis9/logs/event.log"
 ],

El código agregado quedará algo así (nótese que contiene la sección "auditd_log", que ya fue agregada en el primer manual; debe dejarse tal cual está si esta configuración no es para un nodo nuevo; en caso contrario, agregar el nodo nuevo a la sección como corresponde):

Guardar el archivo. Comprobar sintaxis ejecutando el siguiente comando (deberá devolver todo el contenido del archivo .json; en caso de ver algún error, revisar en qué línea es):

jq . opCommon.json

Posterior a la edición de este archivo, es necesario ejecutar lo siguiente:

service omkd restart

Acceder a la ruta:

/usr/local/omk/conf/

Editar el archivo EventParserRules.json e identificar la sección "nmis_eventlog_alt". Ahí, deberá de agregarse lo siguiente:

            "80": {
               "DESCRIPTION": "Parse file audit events - extract action and file path",
               "IF": "user_modified=([^|]*)\\|action=([^|]*)\\|file_existence=([^|]*)\\|last_modified=([^|]*)\\|details=(.+)$",
               "THEN": [
                  "capture(user_modified,action,file_existence,last_modified,details)"
               ]
            },
            "81": {
               "DESCRIPTION": "Capture the file path for the element",
               "IF": ",Archivo \\s*[^:]+:\\s*([^,]+)",
               "THEN": [
                  "capture(element)"
               ]
            }

Se recomienda agregarlo después de la sección 71 (considerar que debe agregarse una coma después de la llave de cierre de la sección mencionada). El archivo deberá de quedar así:

Nota: para este archivo lo que ya se ha agregado previamente en el primer manual, debe de dejarse tal cual está.
Guardar el archivo y comprobar sintaxis ejecutando el siguiente comando (deberá devolver todo el contenido del archivo .json; en caso de ver algún error, revisar en qué línea es):

jq . EventParserRules.json

Acceder a la ruta:

/usr/local/nmis9/conf/

Editar el archivo Events.nmis y agregar lo siguiente:

'File Integrity Alert' => {
    'Event' => 'File Integrity Alert',
    'Notify' => 'true',
    'Status' => 'true',
    'Log' => 'true',
    'Stateful' => 'true',
    'CancelingEvent' => 'File Integrity Alert Closed',
    'Description' => 'File Integrity Alert from opConfig',
  },
  'Alerta de Integridad de Archivos' => {
    'Event' => 'Alerta de Integridad de Archivos',
    'Notify' => 'true',
    'Status' => 'true',
    'Log' => 'true',
    'Stateful' => 'true',
    'CancelingEvent' => 'Alerta de Integridad de Archivos Cerrada',
    'Description' => 'File Integrity Alert from opConfig',
  },

Se recomienda agregar ambas partes a la mitad del archivo, el cual deberá de verse así:

Comprobar sintaxis ejecutando el siguiente comando. En caso de ver algún error, revisar en qué línea es):

perl -c Events.nmis

Para generar el panel de opEvents, acceder a la ruta:

/usr/local/omk/conf/

Generar el archivo EventsPanels.json y agregar lo siguiente:

{
    "panel-integridadlinux": {
        "title": "Eventos Integridad de Archivos Linux",
        "description": "Alerta de Integridad de Archivos",
        "model": "events",
        "table_schema": "panel-integridadlinux",
        "filter": {
            "event": "iregex: (integridad|archivos)"
        }
    }
}

Guardar el archivo y comprobar sintaxis ejecutando el siguiente comando (deberá devolver todo el contenido del archivo .json; en caso de ver algún error, revisar en qué línea es):

jq . EventsPanels.json

Ejecutar lo siguiente:

chmod 664 EventsPanels.json

Acceder a la ruta:

/usr/local/omk/conf/table_schemas

Crear el archivo opEvents_panel-integridadlinux.json, el cual debe contener lo siguiente (pueden ajustarse los valores de "label", que es donde se colocaron los encabezados proporcionados):

[
    {
        "name": "",
        "cell": "select-row",
        "headerCell": "select-all"
    },
    {
        "name": "id",
        "label": "ID evento",
        "cell": "LookupUrl",
        "replace_name": "id",
        "base_url_stash_key": "event_url",
        "editable": false
    },
    {
        "name": "date",
        "label": "Fecha",
        "cell": "LookupUrl",
        "replace_name": "id",
        "base_url_stash_key": "event_url",
        "editable": false
    },
    {
        "name": "node",
        "label": "Nodo",
        "search": "iregex",
        "cell": "LookupUrl",
        "replace_name": "node_uuid",
        "base_url_stash_key": "node_url",
        "editable": false
    },
    {
        "name": "event",
        "label": "Evento",
        "search": "iregex",
        "cell": "LookupUrl",
        "replace_name": "id",
        "base_url_stash_key": "event_url",
        "editable": false
    },
    {
        "name": "priority",
        "label": "Prioridad",
        "search": true,
        "cell": "ServicePriority",
        "direction": "descending",
        "editable": false
    },
    {
        "name": "friendly_element",
        "label": "Archivo",
        "search": "iregex",
        "cell": "String",
        "editable": false
    },
    {
        "name": "user_modified",
        "label": "Proceso o usuario que hizo el cambio",
        "search": "iregex",
        "cell": "String",
        "editable": false
    },
    {
        "name": "action",
        "label": "Accion realizada por el proceso o usuario",
        "search": "iregex",
        "cell": "String",
        "editable": false
    },
    {
        "name": "file_existence",
        "label": "Estado del archivo monitoreado",
        "search": "iregex",
        "cell": "String",
        "editable": false
    },
    {
        "name": "last_modified",
        "label": "Ultima modificacion",
        "search": "iregex",
        "cell": "String",
        "editable": false
    },
    {
        "name": "details",
        "label": "Detalles",
        "search": "iregex",
        "cell": "String",
        "editable": false
    }
]

Guardar el archivo y comprobar sintaxis ejecutando el siguiente comando (deberá devolver todo el contenido del archivo .json; en caso de ver algún error, revisar en qué línea es):

jq . opEvents_panel-integridadlinux.json

Posterior a todos los pasos anteriores, es necesario ejecutar lo siguiente:

service opeventsd restart
service opconfigd restart
service omkd restart
service nmis9d restart

En opConfig, deberán agregarse las credenciales correspondientes con el proceso ya conocido (mediante System > Edit Credential Sets > Add Credential Set) y agregarlas a los nodos que se van a monitorear, mediante el módulo Administrator > Seleccionar Nodo > Connection:

Y posteriormente asegurarse que en OS-Info aparezca la palabra Linux; puede agregarse manualmente.

Configuración en el servidor que se va a monitorear

Se requiere tener acceso SSH de solo lectura al servidor que se va a monitorear para:

Verificar la existencia de archivos en los sistemas objetivo
Recopilar metadatos de archivos (tiempos de modificación, tamaños, propiedad, permisos)
Leer el estado actual de las reglas de auditoría (audit rules)

Se requiere tener acceso privilegiado (mediante sudo) para:

Escribir reglas de auditoría en /etc/audit/rules.d/file-integrity.rules.
Reiniciar el servicio auditd para aplicar las nuevas reglas de monitoreo.

El servidor de destino necesitará tener auditd y rsyslog instalado para la supervisión en tiempo real de archivos. El conjunto de comandos ajustará la configuración de auditd en la primera ejecución. Para comprobar esto, ejecutar según sea el caso para comprobar la instalación (o instalar los paquetes si hacen falta):

Validar:

which auditd
which rsyslogd

systemctl status auditd
systemctl status rsyslog

Asegurarse de tener instalados o instalar los siguientes componentes:

# ejecutar para saber si audit está instalado:
rpm -qa | grep audit
# ejemplo de salida esperada (si no aparece nada, no está instalado)
audit-3.1.2-1.el8_10.1.x86_64
audit-libs-3.1.2-1.el8_10.1.x86_64

# ejecutar para saber si audispd-plugins está instalado:
rpm -qa | grep audispd-plugins
# ejemplo de salida esperada (si no aparece nada, no está instalado)
audispd-plugins-3.1.2-1.el9.x86_64

# ejecutar para saber si rsyslog está instalado:
rpm -qa | grep rsyslog
# ejemplo de salida esperada (si no aparece nada, no está instalado)
pcp-pmda-rsyslog-5.3.7-22.el8_10.x86_64
rsyslog-gssapi-8.2102.0-15.el8_10.1.x86_64
rsyslog-gnutls-8.2102.0-15.el8_10.1.x86_64
rsyslog-relp-8.2102.0-15.el8_10.1.x86_64
rsyslog-8.2102.0-15.el8_10.1.x86_64

# si algún paquete no está instalado, ejecutar según el sistema operativo:
apt-get install auditd audispd-plugins rsyslog
dnf install auditd audispd-plugins rsyslog

Una vez instalados los plugins necesarios, colocar el archivo en la ruta:

/usr/bin/

Acceder a la ruta:

/usr/bin/

Una vez dentro, ejecutar los siguientes 2 comandos:

chmod +x omkaudit.pl
chown root:root omkaudit.pl

Acceder a la ruta:

/etc/ssh/ssh_config.d/

Comentar la siguiente línea del archivo 04-ipa.conf y guardarlo. Notas: el nombre del archivo podría variar dependiendo del sistema operativo, pero esa instrucción deberá ser comentada donde corresponda. Si el archivo no existe, omitir este paso.

# Match exec true

Reiniciar el demonio sshd, ejecutando:

service sshd restart

Acceder a la ruta:

/etc/audisp/plugins.d/

Una vez dentro de la carpeta, generar el archivo omkaudit.conf. Deberá contener lo siguiente:

active = yes
direction = out
path = /usr/bin/omkaudit.pl
type = always
format = string

Posterior a la generación del archivo, ejecutar lo siguiente:

service auditd restart

Confirmar que el complemento se ha cargado ejecutando alguno de los siguientes dos comandos:

service auditd status

systemctl auditd status

Deberá mostrarse algo similar a esto:

auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-05-12 16:46:43 NZST; 22h ago
       Docs: man:auditd(8)
             https://github.com/linux-audit/audit-documentation 
    Process: 13195 ExecStart=/sbin/auditd (code=exited, status=0/SUCCESS)
    Process: 13215 ExecStartPost=/sbin/augenrules --load (code=exited, status=0/SUCCESS)
   Main PID: 13208 (auditd)
      Tasks: 4 (limit: 19145)
     Memory: 1.9M
        CPU: 1.225s
     CGroup: /system.slice/auditd.service
             ├─13208 /sbin/auditd
             └─13211 /usr/bin/perl /usr/bin/omkaudit.pl

Revisar el archivo:

/var/log/omkaudit.log

En el cual deberá mostrarse algo similar a esto (registro indicando que el complemento se ha iniciado):

timestamp=1747025203 Plugin started

Para finalizar, acceder a la ruta:

/etc/rsyslog.d/

Una vez dentro de la carpeta, generar el archivo 10-send-omk-auditd-log.conf. Deberá contener lo siguiente:

module(load="imfile" PollingInterval="10")
input(type="imfile"
      File="/var/log/omkaudit.log"
      Tag="auditplugin:"
      Severity="info"
      Facility="local6"
      PersistStateInterval="10"       
      reopenOnTruncate="on"
)
# Forward this log to the remote server
local6.* @@omk.example.com:514   # Use @@ for TCP

Nota: se deberá de modificar omk.example.com por la dirección del servidor opEvents, donde se recibirán los registros de auditoría que serán procesados, por ejemplo:

local6.* @@192.168.1.1:514 # Use @@ for TCP

Posterior a la generación del archivo, ejecutar lo siguiente:

service rsyslog restart

Configuración de Operador Virtual

Puede generarse un Operador Virtual para la ejecución manual de la integridad de archivos. A continuación los pasos para realizarlo:

Acceder a la carpeta:

/usr/local/omk/conf/table_schemas/

Generar un backup del archivo opConfig_action-elements.json. Editar el archivo original y agregar lo siguiente (ajustar donde corresponda, debe generarse uno por cada nodo que se agregue):

  {
    "name": "Integridad Linux NOMBREDELNODO",
    "description": "Integridad Linux NOMBREDELNODO",
    "command_sets": ["NOMBREDELNODO_fim-linux"],
    "nodes": ["NOMBREDELNODO"],
    "tags": ["NOMBREDELNODO"],
    "buttonLabel": "Integridad Linux NOMBREDELNODO",
    "buttonClass": "btn-primary"
  },

El archivo debe verse así:

Guardar el archivo y ejecutar:

service opconfigd restart

En la UI de opConfig, se deberá de ver algo así, listo para ejecutarse:

Y se verá de esta forma. Ejemplo creado correctamente:

Configuración de ejecución automática

La integridad de archivos se puede configurar para que se ejecute de forma automática vía el cron de opConfig.

Acceder a la carpeta:

/etc/cron.d/

Editar el archivo opconfig y agregar lo siguiente, acorde al operador virtual creado arriba (se recomienda generar un backup, copiando el archivo a otra carpeta, nunca duplicar el archivo en cron.d porque puede provocarse un mal funcionamiento de las tareas automatizadas; de igual forma, ajustar el tiempo como mejor convenga, en este ejemplo, se ejecutará cada minuto 15; sugerimos usar Crontab.guru - The cron schedule expression generator para validar los tiempos de ejecución):

*/15 *  *  *  * root    export PERL5LIB=/usr/share/perl5:/usr/local/lib64/perl5:/usr/lib64/perl5 PAR_GLOBAL_TMPDIR=/usr/local/omk/var/lib/common/||:;   /usr/local/omk/bin/opconfig-cli.pl quiet=1 act=run_command_sets tags="NOMBREDELNODO" names="NOMBREDELNODO-B_fim-linux" nodes="NOMBREDELNODO"

Nota: debe de haber un tabulador en la separación de algunos elementos, se indica a continuación:
*****[tabulador]root[tabulador]export PERL5LIB=/usr/share/perl5:/usr/local/lib64/perl5:/usr/lib64/perl5 PAR_GLOBAL_TMPDIR=/usr/local/omk/var/lib/common/||:;[tabulador]/usr/local...
Guardar el archivo y ejecutar:

service crond restart

Interpretación en opConfig y opEvents

Una vez que todo esté configurado y se ejecute el comando, se mostrarán los resultados en tablas:

Tabla "Alerts": muestra el tipo de alerta, el nombre del nodo, el elemento (ruta), el estado y los detalles.

Tabla "Conditions": muestra un icono del estado de cada ruta.

Tabla "Derived Information: File Integrity Status": muestra más información sobre las rutas declaradas, como la fecha de creación, fecha de última modificación, el tamaño del archivo y los permisos de cada uno.

Tabla "Derived Information: File Count": muestra el total de archivos encontrados, el total de archivos no encontrados y el total de archivos configurados.

El acceso al panel de eventos se encontrará en opEvents > Panels > Nombre del panel:

El cual mostrará únicamente los eventos generados para integridad de archivos Linux en los nodos que estén configurados para este propósito y las siguientes columnas:
- ID evento
- Fecha
- Nodo
- Evento: Alerta de Integridad de Archivos / Alerta de Integridad de Archivos Cerrada
- Prioridad
- Archivo
- Proceso o usuario que hizo el cambio
- Acción realizada por el proceso o usuario: MODIFICADO, ELIMINADO, CREADO
- Estado del archivo monitoreado: EXISTE, NO_EXISTE
- Última modificación
- Detalles

En la columna Detalles, se mostrará información sobre las acciones realizadas. A continuación, se desglosan los mensajes:

MODIFICADO (ejemplo de edición: utilizando nano con el usuario root): El archivo fue modificado en omk-vm9-debian11. Archivo modificado de 2025-07-29 11:47:24 a 2025-07-29 11:57:08. Operaciones de archivo detectadas: - root leido archivo hora: 07/29/2025 11:57:08 (usando /usr/bin/nano) sesion: 223
- "El archivo fue modificado en omk-vm9-debian11": el host (nodo) donde ocurrió el evento. Auditd reportó actividad en ese servidor.
- "Archivo modificado de 2025-07-29 11:47:24 a 2025-07-29 11:57:08": opConfig detectó que la marca de modificación (mtime) cambió entre esas dos fechas:
  - Antes de la edición: última modificación a las 11:47:24.
  - Después de guardar con nano: nueva modificación a las 11:57:08.
- "Operaciones de archivo detectadas": auditd registró operaciones sobre el archivo.
  - "- root leido archivo": el usuario root abrió el archivo para lectura (cuando nano abre un archivo, lo primero que hace es leerlo antes de editarlo).
  - "hora: 07/29/2025 11:57:08": el timestamp exacto del evento capturado por auditd.
  - "(usando /usr/bin/nano)": el binario responsable de la acción fue /usr/bin/nano.
  - "sesion: 223": ID de la sesión de auditoría (audit session ID). Permite correlacionar todas las acciones que hizo root en ese mismo contexto de login/ejecución.

En resumen, el evento generado es la traducción en opEvents de los registros de auditd:

Indica qué archivo fue modificado.
Cuándo fue modificado (antes y después).
Quién lo modificó (root).
Con qué herramienta (nano).
Dentro de qué sesión (223).

ELIMINADO (ejemplo de eliminación: utilizando rm con el usuario root): El archivo /root/fileintegrity/grian.txt fue eliminado en omk-vm9-debian11. El archivo fue eliminado desde la ultima auditoria (ultima modificacion: 2025-07-29 11:57:08). Operaciones de archivo detectadas: - root eliminado archivo hora: 07/29/2025 12:02:24 (usando /usr/bin/rm) sesion: 223
- "El archivo /root/fileintegrity/grian.txt fue eliminado en omk-vm9-debian11": el host (omk-vm9-debian11) notificó a opEvents que el archivo grian.txt ya no existe. Esto se disparó porque auditd registró un evento de unlink sobre ese path.
- "El archivo fue eliminado desde la última auditoría (última modificación: 2025-07-29 11:57:08)": el script había registrado previamente que el archivo existía y que su última modificación fue a las 11:57:08. En la nueva ejecución/auditoría ya no aparece, por lo que opEvents interpreta que fue eliminado después de esa hora.
- "Operaciones de archivo detectadas": detalle de lo que auditd capturó:
  - "- root eliminado archivo": usuario responsable: root. Acción: eliminación (unlink).
  - "hora: 07/29/2025 12:02:24": marca de tiempo exacta cuando auditd registró el borrado.
  - "(usando /usr/bin/rm)": el binario ejecutado que hizo la eliminación fue /usr/bin/rm.
  - "sesion: 223": ID de la sesión de auditoría, la misma que cuando se editó con nano. Esto permite correlacionar que fue el mismo contexto de usuario root.

El evento refleja de forma precisa el ciclo de vida del archivo bajo monitoreo:

a) Antes: auditado y existente, última modificación a las 11:57:08.

b) Después: auditd reporta que el archivo fue eliminado con rm a las 12:02:24.

opEvents consolida esa información y la presenta como un evento estructurado que indica:

Qué archivo desapareció.
Cuándo fue la última vez que se sabía que existía.
Quién y con qué comando lo borró.
En qué sesión ocurrió.

CREADO (ejemplo de creación: utilizando nano con el usuario root): El archivo /root/fileintegrity/grian.txt fue creado en omk-vm9-debian11. El archivo fue creado desde la ultima auditoria. Operaciones de archivo detectadas: - root leido archivo hora: 07/29/2025 12:07:12 (usando /usr/bin/nano) sesion: 223
- "El archivo /root/fileintegrity/grian.txt fue creado en omk-vm9-debian11": opEvents detecta que el archivo antes no existía (última auditoría) y ahora sí existe en el nodo omk-vm9-debian11.
- "El archivo fue creado desde la última auditoría": confirma que la diferencia respecto al ciclo anterior es la aparición del archivo nuevo.
- "Operaciones de archivo detectadas:" son las acciones registradas por auditd al momento de la creación.
  - "- root leido archivo": aunque lo que se realizó fue crearlo, nano lo abre en modo lectura/escritura inmediatamente, por eso se ve como "leído": auditd marcó que hubo un "read" al archivo recién creado.
  - "hora: 07/29/2025 12:07:12": la marca de tiempo exacta en la que auditd registró el acceso inicial.
  - "(usando /usr/bin/nano)": el proceso que realizó la operación fue /usr/bin/nano.
  - "sesion: 223": mismo ID de sesión de auditoría que los casos anteriores (la sesión activa de root en ese shell).

Lo que se muestra es la trazabilidad completa del nacimiento del archivo:

En la auditoría previa, el archivo no existía.
nano lo crea (operación create) y lo abre en modo lectura/escritura.
auditd registra la creación y el acceso.
opEvents lo interpreta y te lo presenta como:

a) Archivo creado.

b) Primera acción detectada: lectura por parte de root usando nano.

c) Hora exacta y sesión en que ocurrió.